JNDI is not the only way.
Another good way is the .properties file on the classpath
This can work even better if you have default properties in your war,
so you do something like
public static final class Configuration {
private static final class ResourceHolder {
private static final Configuration INSTANCE = newConfiguration();
}
private final Properties config;
private Configuration() {
Properties defaultConfig = new Properties();
InputStream is = null;
try {
is = Configuration.class.getResource(Configuration.class.getSimpleName()
+ ".properties"); // load the defaults from the war
if (is != null) {
defaultConfig.load(is);
}
} catch (IOException e) {
// unable to load defaults, no big crime
} finally {
if (is != null) {
try {
is.close();
} catch (IOException e) {
// ignore
}
is = null;
}
}
config = new Properties(defaultConfig);
InputStream is = null;
try {
is = Configuration.class.getResource("/" +
Configuration.class.getSimpleName() + ".properties"); // load the
customer config from the classpath
if (is != null) {
config.load(is);
}
} catch (IOException e) {
// unable to customer config, no big crime
} finally {
if (is != null) {
try {
is.close();
} catch (IOException e) {
// ignore
}
is = null;
}
}
}
public static Configuration getInstance() {
return ResourceHolder.INSTANCE;
}
...
}
Obviously there's more you can do.
you put the default configuration resource in the same package as the
Configuration class.
the customer just puts the Configuration.properties in the root
package, so in JBOSS they just put their config in
$JBOSS_HOME/server/____/conf
in Tomcat 5.x it's $CATALINA/shared/classes I'd have to dig out the
location for 6.x and 7.x
etc.
If you go the properties route (and you could use an XML file or a
YAML file or whatever you want the config file to be in) I'd consider
implementing periodic scanning for changes or else tell customers they
need to restart the webapp to pick up the config changes.
-Stephen
On 8 February 2011 09:29, nodje <[email protected]> wrote:
>
> Hi Ron,
>
> 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.
>
> Is this at all possible?
>
> 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.
>
> What do you think?
>
> cheers
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/maven-failsafe-plugin-Running-integration-test-with-its-own-profile-tp3367473p3375605.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
