Currently the SysOps team has to repackage the war file that we release with instance specific configuration. They are requesting us to externalize the configuration files (log4j.properties, environment.properties, jrf.properties, quartz.properties) out size the war file. That will make the deployment easier.
We are using Tomcat 7 and VirtualWebappLoader in Tomcat 7 looks like a very cool feature to externalize the configuration outside the war file. Tomcat 6 documentation explicitly states that "This is not meant to be used for production. Its meant to ease development with IDE's without the need for fully republishing jars in WEB-INF/lib"? Tomcat 7 documentation does not say so.
Any idea if VirtualWebappLoader feature can be used in production environment?
I've been doing externally-injected configuration since long before Tomcat 7. Since Tomcat 5, at least. I have a strict policy that the exact same byte-for-byte-identical WAR gets deployed whether it's on the desktop, the Beta machine or full production. That allows me to be certain that any behaviors are not due to program logic differences as well as unfortunate incidents where the wrong WAR gets deployed so that for example, we don't discover that for the last week, the production webapp has been working off the test database.
Since the VirtualWebappLoader is new to Tomcat 7, obviously I've been doing it a different way. Just for the record, however, I don't think that the VirtualWebappLoader is really appropriate for this sort of use.
What I do instead is define the variable constituents (config file locations, run option settings and so forth) as Context properties. The webapp then retrieves them using JNDI.
When it comes to destroying a civilization, gas chambers cannot hold a candle to echo chambers.
posted 7 years ago
So I guess I could configure the locations using either of the options below
and either use servletcontext (getInitParameter) OR Context envCtx = (Context) initCtx.lookup("java:comp/env"); to load those values..
If I do that, I will have to modify all the existing code where ever we are using ResourceBundle to load the resources from the class path. And there is a third party software jrf, which loads jrf.properties using ResourceBundle. And I cannot modify this code.
That is why I was hoping to use an option like below to load the configuration files from additional external class path C:/externalresources/