My velocity macros are being cached and I don't want them to be... not during development at least.
I've set the following properties in my properties file...
velocimacro.library.autoreload=true
file.resource.loader.cache=false
velocity.engine.resource.manager.cache.enabled=false
... but this doesn't seem to have done the trick
Using velocity properties, how can I configure velocity to not cache macros?
(I'm using velocity 1.6.4)
EDIT:
I don't think the line...
velocity.engine.resource.manager.cache.enabled=false
...is relevant to velocity
I have been having the same issue with NVelocity (C# port of velocity). Digging through their souce I found that the re-loading of the macros in the global name space are controlled by the following property.
properties.SetProperty(RuntimeConstants.VM_PERM_ALLOW_INLINE_REPLACE_GLOBAL, true);
I havn't tested this with velocity but looking at their documentation the property exists and seem to do exactly what you need.
Looks like you cant do what you want. The only way I could get macro definitions to reload is to put them in their own library file and set the velocimacro.library.autoreload = true.
From http://velocity.apache.org/engine/devel/developer-guide.html
velocimacro.library = VM_global_library.vm
Multi-valued key. Will accept CSV for value. Filename(s) of Velocimacro library to be loaded when the Velocity Runtime engine starts. These Velocimacros are accessable to all templates. The file is assumed to be relative to the root of the file loader resource path.
velocimacro.library.autoreload = false
Controls Velocimacro library autoloading. When set to true the source Velocimacro library for an invoked Velocimacro will be checked for changes, and reloaded if necessary. This allows you to change and test Velocimacro libraries without having to restart your application or servlet container, just like you can with regular templates. This mode only works when caching is off in the resource loaders (e.g. file.resource.loader.cache = false ). This feature is intended for development, not for production.
I'm not sure this is possible if the macros are not in a velocity library and just in some template file.
However, in this case, if you just want to make development easier, you can just rename the macro (by doing a find/replace all and just adding a number to the end or something). Then you should be able to see the change straight away. You just have to remember to rename it back to what it's supposed to be when your finished!
You might need to set
file.resource.loader.modificationCheckInterval
This tells velocity how often to check if the file has changed. I can't tell from the docs what the default is, but we have ours set to 2 in our dev env. It might just be that the default value for this prop is a high number or less than 0 which is essentially off, meaning it will never check for changes in your macro file.
You may want to use the #define directive instead of #macro. Theses references can change.
With it you can also name a block of VTL code and call it how many times you need it.
Define the macro arguments as variables in the same context and use them within the named block as if it were a macro.
Both can solve common situations; but they are not equivalent.
https://velocity.apache.org/engine/1.7/user-guide.html#define
Related
I'm looking for a java argument (or perhaps some different method) to allow me to specify a file to be used by the JVM as the java.security file, rather than using the one found in the JDK (in the JRE lib).
To give you a little more context, I am working with a WebLogic server that was set up by someone else and is running two (or more) different JVMs off the same JDK. We have run into an issue now where the work I'm doing on one JVM requires a different java.security file than the one that is currently being used by the other JVM. I am hoping there will be a way for me to just point my JVM at a new java.security file without having to point it at an entirely new JDK (due to space constraints, we would like to avoid uploading a JDK specific to each JVM).
I realize that the server's set up is not ideal, but completely rearranging the existing set up is not viable and not something I am in a position to do. So, I am hoping someone might have a creative solution that would allow for multiple JVMs running off the same JDK but with different security configurations.
I have been trying to find solutions out there, but it seems my Google-Foo is not as strong as I had hoped. Here's to hoping one of you has the answer!
Many thanks.
EDIT
Sorry maybe my original post was not clear, but I am interested in specifying the java.security file, also often referred to as the Java master security properties file, not the java.policy file which is found in the same directory.
My Solution
I will post my solution here just for reference of others who might fall into a similar situation.
As I can't seem to find an argument to specify at start up, I have decided that I will have to forgo the java.security properties file. It is possible to set properties and providers (typically configured in the file) within code using the Security class (java.security.Security). So, at least in the interim, I plan to write a class that will go through setting up my JVM specific security configurations after startup (essentially overwriting the default configurations provided by the file for the other JVM). While the obvious downside of this solution is that is does not externalize security configurations of this JVM, the solution does provide me a way to set JVM specific properties and providers without affecting the configuration of other JVMs running off the same JDK.
I appreciate the time and consideration given by others. Thanks =)
Looking at the OpenJDK source, you cannot change the loading of the java.security file. However, that file has a property called security.overridePropertiesFile which, if set to true (as it is in my current, vanilla install), allows you to load an additional security properties file specified through the system property named java.security.properties. Note also, that the command line syntax follows a similar pattern to the policy file where = specifies additional configuration and == specifies a complete replacement configuration.
Maybe the accepted answer on this thread would help you out; basically it says that you need to specify your own policy file and the final invocation should look like:
java -Djava.security.manager -Djava.security.policy=/some/path/my.policy
You can just set the system property -Djava.security.properties=***** to specify the security property you want to load, but you must set the property security.overridePropertiesFile=true prior to use this approach.
I recently started working on a POORLY designed and developed web application.. I am finding that it uses about 300 properties files, and all the properties files are being read somewhat like this:
Properties prop= new Properties();
FileInputStream fisSubsSysten = new FileInputStream("whatever.properties");
prop.load(fisSubsSysten);
That is, it is reading the properties files from current working directory.. Another problem is the developers have chosen to use the above lines multiple times within the same java file. For example if there are 10 methods, each method will have the above code instead of having one method and calling it wherever necessary..
This means, we can NEVER change the location of the properties files, currently they are directly under the websphere profiles directory, isn't this ugly? If I move them somewhere else, and set that location in classpath, it does not work.
I tried changing the above lines like this using Spring IO utils library:
Resource resource = new ClassPathResource("whatever.properties");
Properties prop = PropertiesLoaderUtils.loadProperties(resource);
But this application has over 1000 files, and I am finding it impossible to change each file.. How would you go about refactoring this mess? Is there any easy way around?
Thanks!
In these cases of "refactoring" i use a simple find and replace approach. Notepad++ has a " find in files" feature but there are plenty of similar programs.
Create a class which does the properties loading with a method probably with a name parameter for the property file.
This can be a java singleton or a spring bean.
Search and replace all "new Properties()" lines with an empty line.
Replace all "load..." lines with a reference to your new class/ method. Notepad++ supports regex replacement, so you can use the filename as a parameter.
Once this is done go to eclipse and launch a "cleanup" or "organize imports" and fix some compile errors manually if needed.
This approach is quite straight forward and takes no more than 10min if you are lucky or 1 hour if you are unlucky, f.e. the code formatting is way of and each file looks different.
You can make your replace simpler if you format the project once before with a line length of 300 or more so each java statement is on one line. This makes find and replace a bit easier as you dont have newlines to consider.
I can only agree that I find your project a bit daunting, from your reference.
However, the choice of how to maintain or improve of it is a risk that merely needs to be assessed and prioritised.
Consider building a highrise and subsequently realising the bolts that holds the infrastructure have a design flaw. The prospect of replacing them all is indeed daunting as well, so considerations into how to change them and if they really, really needs to be replaced, few, many or all.
I assume it must be a core system for the company, which somebody built and they have probably left the project (?), and you have consideration about improvement or maintaining them. But again, you must assess whether it really is important to move your property files, or if you can just for instance use symbolic links in your file system. Alternatively, do you really need to move them all or is there just a few that would really benefit from being moved. Can you just mark all places in the code with a marker to-be-fixed-later. I sometimes mark bad classes with deprecation, and promise to fix affected classes but postpone until I have other changes in those classes until finally the deprecated class can be safely removed.
Anyway you should assess your options, leave files, replace all or partials, and provide some estimation of cost and consequences, and ask your manager which course to take.
Just note that always overestimate the solution you don't want to do, as you would be twice as likely to stop for coffee breaks, and a billboard of told-you-so's is a great leverage for decision making :)
On the technology side of your question, regex search and replace is probably the only option. I would normally put configuration files in a place accessible by classpath.
You can try using eclipse search feature. For example if you right click on load() method of the properties class and select References -> Project it will give you all location in your project where that method is used.
Also from there maybe you can attempt a global regex search and replace.
It is possible using -Dproperty=value arguments to set arbitrary system properties (not some fixed set of system properties actually used by the JVM) and a program can get these properties later using System.getProperty("property"). Is it correct to do this?
I haven't found an authoritative answer on this, so that's why I'm asking here. It seems to me that program parameters should be set through command line arguments to the program, not to the JVM. However, perhaps this is an accepted practice that just isn't documented anywhere I've looked so far. I'd like to be sure. Thanks.
I think Java system properties are used to pass values from command line to libraries or plugins inside the execution. It is, that insider component has no direct way to receive the parameter from the main program that's executing it. So it reads it from a "context" that Java system properties are.
If we look at it as layers, command line arguments would be parameters for the inmediate lower layer, and system java properties are context for all the lower layers.
command line: arguments + properties
main program: uses arguments
some library/plugin: uses properties from context
If it's not this way the main program should have to carry all the parameters that user could set to the lower layers and it can be very cumbersome.
I don't like to depend on contextual properties so if I design a program I'd try to pass over all the properties in some non-global way. But it can be very handy some times (and using namespacing it's not probable they collide).
In my opinion this is not "incorrect" and there are programs and libraries that do use their own system properties for configuration.
However, it is probably more practical to put configuration parameters for your software in a configuration file (in whatever format you think is suitable - a .properties file, an XML file, or something else). It is cumbersome, especially if you have many configuration parameters, to have to put all those parameters on the command line with -Dname=value options.
You can use this method to set some of your application settings. I think of settings as a contrast to program arguments. For example. Let's think abount some file converter. It converts file A to B. So files A and B should be command line params. If you converter needs some temporary folder you can make id settable by -Dmy.package.tempfolder=\my\tmp\folder. But there should be a default setting for that and the program should work without this setting.
Think about it as an alternative to .properties file. .properties file will be more convinient of course.
You just have to know what you're doing. If your application is a standalone application, system properties provide an easy to use way to pass named arguments, in any order, to the program, and I don't see anything intrinsically bad in using them.
If your app is a webapp that must be deployed in a app server shared by multiple webapps, then it might not be a good idea, especially if you aren't allowed to change how the server is started, or if you have to deploy multiple versions of the same application.
From http://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html:
For example, the following invocation of getProperty looks up the
System property called subliminal.message. This is not a valid system
property, so instead of returning null, this method returns the
default value provided as a second argument: "Buy StayPuft
Marshmallows!"
System.getProperty("subliminal.message",
"Buy StayPuft Marshmallows!");
This implies that properties other than those used by the JVM are "invalid". However, later in the same document, it gives the example of loading a properties file containing the same property setting.
subliminal.message=Buy StayPuft Marshmallows!
It only advises "In general, be careful not to overwrite system properties."
So it seems that this is a supported use of System Properties. It looks like a case of misleading naming. When I hear "System Properties" I think "properties of the JVM" where the JVM is the system. While the properties are used for this, they can also be used for application settings. I think I'll make a mental note to think of this as "System and Application Properties".
Does anyone disagree with this?
I'm looking for a java argument (or perhaps some different method) to allow me to specify a file to be used by the JVM as the java.security file, rather than using the one found in the JDK (in the JRE lib).
To give you a little more context, I am working with a WebLogic server that was set up by someone else and is running two (or more) different JVMs off the same JDK. We have run into an issue now where the work I'm doing on one JVM requires a different java.security file than the one that is currently being used by the other JVM. I am hoping there will be a way for me to just point my JVM at a new java.security file without having to point it at an entirely new JDK (due to space constraints, we would like to avoid uploading a JDK specific to each JVM).
I realize that the server's set up is not ideal, but completely rearranging the existing set up is not viable and not something I am in a position to do. So, I am hoping someone might have a creative solution that would allow for multiple JVMs running off the same JDK but with different security configurations.
I have been trying to find solutions out there, but it seems my Google-Foo is not as strong as I had hoped. Here's to hoping one of you has the answer!
Many thanks.
EDIT
Sorry maybe my original post was not clear, but I am interested in specifying the java.security file, also often referred to as the Java master security properties file, not the java.policy file which is found in the same directory.
My Solution
I will post my solution here just for reference of others who might fall into a similar situation.
As I can't seem to find an argument to specify at start up, I have decided that I will have to forgo the java.security properties file. It is possible to set properties and providers (typically configured in the file) within code using the Security class (java.security.Security). So, at least in the interim, I plan to write a class that will go through setting up my JVM specific security configurations after startup (essentially overwriting the default configurations provided by the file for the other JVM). While the obvious downside of this solution is that is does not externalize security configurations of this JVM, the solution does provide me a way to set JVM specific properties and providers without affecting the configuration of other JVMs running off the same JDK.
I appreciate the time and consideration given by others. Thanks =)
Looking at the OpenJDK source, you cannot change the loading of the java.security file. However, that file has a property called security.overridePropertiesFile which, if set to true (as it is in my current, vanilla install), allows you to load an additional security properties file specified through the system property named java.security.properties. Note also, that the command line syntax follows a similar pattern to the policy file where = specifies additional configuration and == specifies a complete replacement configuration.
Maybe the accepted answer on this thread would help you out; basically it says that you need to specify your own policy file and the final invocation should look like:
java -Djava.security.manager -Djava.security.policy=/some/path/my.policy
You can just set the system property -Djava.security.properties=***** to specify the security property you want to load, but you must set the property security.overridePropertiesFile=true prior to use this approach.
Is there a system property or a program argument that I can use to pass the name of a properties file to GWT, to tell GWT to load these into the system properties?
I'm trying to change something like this:
com.google.gwt.dev.GWTShell -Dsysprop1=value1 -Dsysprop2=value2 ...
to something like this:
com.google.gwt.dev.GWTShell -Dgwt.system.properties=/my/properties/file ...
The motivation is to be able to change easily between sets of properties according the runtime environment, for example so that I can have dev.properties and prod.properties property without having to set the properties individually on the startup command.
Aside: there are two other options that will work, but which I'd like to avoid for now:
adding a layer of indirection through which to pick up all of the system properties (because this will be a pain to retrofit)
adding a bootstrapper to load the property set before delegating everything GWT (because I'm lazy, though this might be a reasonable longer term option if GWT doesn't support this out of the box).
There's a great example of how to do this using GWT Generators here.