On Wed, Nov 26, 2008 at 3:07 PM, Ikai L. firstname.lastname@example.org wrote:
So my question is this: what are your best practices for changing configurations on a server by server basis when doing WAR file deployment? In the traditional Mongrel stack deployment we can follow with a Capistrano task to symlink files. We can definitely do that too after the WAR file is expanded, but that feels hacky to me. I was looking at the global $servlet_context and considering using getAttribute, but I don’t believe there’s any place inside the application server that allows me to set attributes at runtime or on a container by container basis. Another idea is to have a config file somewhere on each server outside of the WAR deploy directory that the Rails application simply reads from.
The ideal situation would be that I can preserve a single WAR file for a given release, and deployment is as simple as copying the file to an autodeploy directory without having to fire off any post-deploy hooks, yet configuration can be centralized. On the Sun Application Server, this would mean being able to change settings from the GUI or standard XML files.
I’m not clear that there are any best practices here either.
Apparently it’s possible to create appserver-specific configuration
inside the server using JNDI (or maybe some other approaches?) but
I’ve never seen an app that is deployed that way.
Other than that, I see a couple of possibilities:
Keep environment-specific config files in a well-known location on
each machine. I know, java webapps shouldn’t access /etc or other
files outside of the deployment environment. Whatever. Deal.
Run a pre-deployment script on your bare war file to “cook”
additional configuration into it. I ran across a utility called
“editwar” [1,2,3] that I forked and have used with a little success,
but not in any production deployments yet. Let me know if you see any
use for it.
I’m sure there are others out there as well, and I’d be interested to
hear about them.
To unsubscribe from this list, please visit: