Re: [maven-failsafe-plugin] Running integration test with its own profile
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
Re: [maven-failsafe-plugin] Running integration test with its own profile
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
Re: [maven-failsafe-plugin] Running integration test with its own profile
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, nodjenodje...@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
RE: [maven-failsafe-plugin] Running integration test with its own profile
-Original Message-
From: nodje [mailto:nodje...@gmail.com]
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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven-failsafe-plugin] Running integration test with its own profile
Hi! Am Donnerstag 03 Februar 2011, 03:28:54 schrieb nodje: Invaluable piece of information Ron, thanks a lot. I've been searching the archives without success, with 'profile plugin' 'failsafe profile', all woudn't yield much relevant results. But I'd still be happy if you could point me to some efficient keywords to search for. Try Ron Wheeler profiles ;-) I don't remember JNDI as that complex actually, I just gave up on it since Spring adoption as it didn't seem necessary. JNDI is just one option for holding your configuration. You could also use properties-files or whatever you like. hth, - martin signature.asc Description: This is a digitally signed message part.
[maven-failsafe-plugin] Running integration test with its own profile
Hi, I'm facing a problem in the release process when running Integration Tests. We have different profiles for the different environments the release is made for, namely DEV, TEST, PROD. Each profile has its own values for DB access. Now the IT are made to work on the development environment, i-e with the values of the DEV profile. When it comes to do a release for the TEST or PROD env, Failsafe will run with the given profile and ITs will fail due to invalid DB access values. Ideally, I'd like to be able to specify a different profile, DEV here, for the maven-failsafe-plugin execution. I don't think this is possible yet. So I don't understand how IT can be part of a systematic release process. How do you perform your releases for a production environment with IT validation? Is there a trick to be able to use different profile in a single maven execution? Is it possible to specify one profile per plugin: -Pprod for war plugin -Pdev for failsafe plugin That's be awesome. cheers -- View this message in context: http://maven.40175.n5.nabble.com/maven-failsafe-plugin-Running-integration-test-with-its-own-profile-tp3367473p3367473.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
Re: [maven-failsafe-plugin] Running integration test with its own profile
This is a frequent issue. There has been lost of discussion about this. The Best Practice is to move the deployment info out of your projects into JNDI or some other mechanism that ties the variable information to the thing causing the variability. Profiles is not the right way to do this. Look through the archives for lots of threads about this. There are a lot of reasons given for why this is a bad idea. http://blog.artifact-software.com/tech/?p=58 might help introduce JNDI. Read the official docs as well. They seem to try to make JNDI look more complicated than it actually is but are the definitive docs. Ron On 02/02/2011 3:14 AM, nodje wrote: Hi, I'm facing a problem in the release process when running Integration Tests. We have different profiles for the different environments the release is made for, namely DEV, TEST, PROD. Each profile has its own values for DB access. Now the IT are made to work on the development environment, i-e with the values of the DEV profile. When it comes to do a release for the TEST or PROD env, Failsafe will run with the given profile and ITs will fail due to invalid DB access values. Ideally, I'd like to be able to specify a different profile, DEV here, for the maven-failsafe-plugin execution. I don't think this is possible yet. So I don't understand how IT can be part of a systematic release process. How do you perform your releases for a production environment with IT validation? Is there a trick to be able to use different profile in a single maven execution? Is it possible to specify one profile per plugin: -Pprod for war plugin -Pdev for failsafe plugin That's be awesome. cheers - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven-failsafe-plugin] Running integration test with its own profile
Invaluable piece of information Ron, thanks a lot. I've been searching the archives without success, with 'profile plugin' 'failsafe profile', all woudn't yield much relevant results. But I'd still be happy if you could point me to some efficient keywords to search for. I don't remember JNDI as that complex actually, I just gave up on it since Spring adoption as it didn't seem necessary. And ah, well, that's a piece you configure in the webapp server, so it makes our app not portable anymore. That's a minor trade off, but still, it's so valuable to be able to put a war archive in any container without prior config. Cheers -- View this message in context: http://maven.40175.n5.nabble.com/maven-failsafe-plugin-Running-integration-test-with-its-own-profile-tp3367473p3368765.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
