>-----Original Message-----
>From: nodje [mailto:[email protected]]
>
>I've been reading quite some of your posts in the forum, and it actually
>changed my mind about deployment configuration. Enlightening indeed.
>
>I would now try to favor a single artifact deployment that could be
>configured externally - say JNDi, this really makes sense.
>
>That said, I don't want to compromise on the ease of deployment. Up to now
>our customer just had to drop the war in it's app server, and that was it.
>Plus, we were app server agnostic, we could deploy on whichever server
>WITHOUT ANY configuration.
>
>Trying to figure a way to combine both requirement, here is what I'm
>imagining, and I'd like to hear your opinion on this, whether it makes
>sense
>and if it's possible with JNDI.
>
>1) If we use JNDI to configure the WAR on runtime, and if we want to have a
>'dropping war only' deployment, the only option is to include all the
>needed
>JNDI configuration IN the war.
I don't know about jboss, but in plain Tomcat you can include in your war a
META-INF/context.xml file which will get copied over to
$CATALINA_BASE/conf/Catalina/localhost/<nameofwebapp>.xml the first time the
webapp is deployed. After that, any customization that might be made to that
file will persist. This has the added benefit that you don't need to include
things like your customer's passwords in your artifact.
>2) there need to be a way to select the adapted JNDI configuration: I'm
>thinking environment variable here, it'd certainly be the simplest
>configuration on top of installing the app server.
The way I've done this has a few different pieces:
1) I use Spring to configure things. Spring is useful, but if you're not
already using it a custom coded solution like Stephen suggested might be easier.
2) Spring has a PropertyPlaceholderConfigurer that lets you refer to java
properties within an xml config file.
3) You can use a property reference within an import line to select whatever
custom settings you need, e.g.:
<import resource="classpath:config/foo-${MYVAR}.xml"/>
4) We include a setenv.sh script [*1] that adds on -DMYVAR=${MYVAR} to
CATALINA_OPTS to get the environment variable setting turned into a java
property.
If you don't want any extra setup like this, the other option is to build a
feature into your webapp where the first access to it asks you which
configuration to use, and you write some code to load the right one. That can
be made to have a nice slick interface, but of course then you need to figure
out how to persist that choice.
eric
[*1] Actually, two scripts: a setenv.sh script that looks for anything named
${CATALINA_BASE}/setenv.sh, and setenv.sh.foo scripts that do the per-webapp
specific setup. Tomcat automatically sources in the setenv.sh script.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
