Stephen has provided another good and frequently-used way to make this work.
I would also suggest thinking about how the system admin will install
the package.
1) How sophisticated are they
2) Are their installation parameters that you might also want to pick up
- PayPal accounts, domains, e-mail addresses, database parameters, etc
3) Is there are difference between a new install and an upgrade
- Do databases have to be seeded or upgraded
4) Do you want to offer a package that includes the container
5) Do you need to support different Operating Systems
6) Do you want a "standard" system administration methodology that hides
the variance between releases
It may be the case that you want to provide an installer that can not
only handle the JNDI or Properties files but also reduces the system
administration involved in a new install or upgrade.
I hope that this helps.
Ron
On 08/02/2011 5:06 AM, Stephen Connolly wrote:
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<nodje...@gmail.com> 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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
