Re: Configuration Formats and Locations
Arjan Tijms
Specifically I had some comments regarding http://javaeeconfig.blogspot.com/2014/04/configuration-formats-and-resources.html for the sake of discussion I don't know if it's better to comment here or at the blog, but maybe this is a more central place ;)
Anyway, the comments;
> classpath*:cfg/${STAGE}/*.xml
This would work great for those applications that have embedded configuration for known stages!
To make this really useful for EAR and WAR archives, the "cfg" package/folder should IMHO be as close to the root of the archive as possible. For an EAR this would mean "[root]/cfg/" or "[root]/META-INF/cfg/" while for a WAR it could be "[root]/WEB-INF/cfg/" or perhaps "[root]/META-INF/cfg/".
The problem here is that those locations are not on the classpath.
Especially for an EAR this is troublesome. A WAR archive could get away with having its config in WEB-INF/classes/cfg, but for an EAR there's just no really good substitute. For my private config systems I typically use some hacks to access the EAR's root without using the classpath, but these are just hacks.
One possible solution would be to lobby that these locations are put on the classpath anyway. Such change will have an effect for all Java EE code and may have some unforeseen side-effects.
Another possible solution is to have Java EE expose an API to read said locations. Obviously Java EE containers already have code to read files from there for their own internal usage. This could possibly remain a private API via an SPI that is defined by Java Config and which is required to be implemented by Java EE containers.
This last option would probably require a new resource type, e.g. ear-meta-inf:cfg/${STAGE}/*.xml or war-web-inf:cfg/${STAGE}/*.xml.
>Even worse within an application server running multiple enterprise / web applications several classloaders are active.
This is a good point to take into account. Java EE already has a portable naming scheme in place for the entire server, applications and modules within those applications. See http://en.wikipedia.org/wiki/Enterprise_JavaBeans#Naming_and_directory_services
Although originally intended for JNDI, it might not be a bad idea to look into (partly) reusing this naming scheme. One thing to pay attention to is that it might be needed to specify both a source name (where is the configuration read from in case of the class path) and to which application/module does the configuration apply. E.g.
* [java:module]classpath:[java:module]cfg/test-*.xml
* [java:module]classpath:[java:global/config_app]cfg/test-*.xml
The first says that every module gets to see the configuration it loads from the class path that's visible to that module. The second eon says that every module gets to see the configuration that was loaded from the class path that's visible to the application "config_app".
Obviously the above syntax is just a rough sketch of the idea.
Kind regards,
Arjan Tijms
