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.
Related
I need to store a few configuration parameters on the client side of my GWT app--I'm only using the client side of the framework. I just want to store things like an API access URL base.
Ideally, it would be nice if this were dynamically read, but I can live with having the values statically baked in on every compilation.
When scouring the web for answers, I kept running into all the deferred binding and locale management stuff. I don't care about any of that. I just want to set some property like api.url and read it from the Java code. Failing that, I'd like to set it in an external JavaScript file and read it in from the main generated JS code somehow. However, keeping it simple is an important goal; I don't want to go down the path of some Rube Goldberg-esque JSNI monstrosity.
Is there any means of accomplishing that with some sort of properties files, or a simple JSNI import mechanism? Or am I pretty much stuck with using a Constants-based configuration class (which still requires a recompile to bake in)?
This is what you're looking for: http://www.gwtproject.org/articles/dynamic_host_page.html
In order to escape from the compilations each time when configuration changed i would like to suggest the RPC call of configuration parameters in onmodule load.
In onsuccess you can assign those parameters to your Gwt static variables,those available throughout the Gwt code.
This may reduce the pain,you can change the parameters on serverside and deploy again,No Need To Compile each time for a single line change.
You can define a property on the module xml. Like this:
<define-property values="desenv, production" name="environment"/>
<set-property name="environment" value="production"/>
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 started using Freemarker for assembling simple HTML pages, using FMPP Maven plugin. So far so good.
But one thing I need to do is to include value of a system property (one of system properties Maven provides) on a page. Is there a way to access system properties from Freemarker templates?
(if not, I may just have to hack plugin to allow passing values from Maven)
cf https://community.jivesoftware.com/thread/14820
You can access it like this :
${statics['java.lang.System'].getProperty("my.property")}
cf documentation here :
http://freemarker.sourceforge.net/docs/pgui_misc_beanwrapper.html
FMPP has a setting called data that specifies the variables that all templates will see, so that's where you should put the system properties. To put values into there, unless the value can be specified as a simple literal, you need a so called data-loader. So in this case you need a data-loader that returns the system properties as a java.util.Properties object. While there's no data-loader specifically for that, you can use the eval data-loader like this (in your config.fmpp):
data: {
...
sysProps: eval('System.getProperties()')
...
}
Now in your templates you can access the system properties like sysProps["os.name"].
Alternatively, you could write a custom FMPP data-loader. See http://fmpp.sourceforge.net/dataloader.html#sect19.
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
My WicketApplication.properties file has grown very large, and now to keep it more readable I want to categorize properties in different files. Is there a way to accomplish that and still access the properties like if they were all in the WicketApplication.properties?
See org.apache.wicket.settings.IResourceSettings.addStringResourceLoader(IStringResourceLoader).
You can implement your own IStringResourceLoader which may load from wherever your want.
You can use property files dedicated per page or even component:
AddressPicker.properties - properties specific to an AddressPicker.java componen
ProfilePage.properties - properties used only on a given page (ProfilePage.java)
WicketApplication.properties - for aplication-wide properties (WicketApplication.java)
Wicket, when looking for properties for a given component, will look for the property files in the same order as above. AFAIR Struts2 uses exactly the same technic.
Please look at Wicket documentation: https://cwiki.apache.org/WICKET/i18n-and-resource-bundles.html.
As a last resort, you could write multiple files, but merge them into a single WicketApplication.properties as part of your build process. Unix has a tool precisely for doing this.