Re: Test classpath problem in multi module project
Hi Petr, I have a default.persistence.properties in the artifact with the EJB3 abstract test case. There I can specify whatever I like. Also, in the jboss in deploy/ejb3.deployer/META-INF there is another persistence.properties where I specify the production properties. Stefan Petr Nejedly wrote: Thanks Stefan, Very helpful. Just a question: You said you're using only one persistence.xml for both, testing and live deployment. How do you specify different Hibernate properties for those, eg dialect (Oracle vs HSQLDB), auto create schema (on vs off), etc? Cheers, Petr The information contained in this email and its attachments is confidential and may be the subject of legal, professional or other privileged information. It is intended only for the named addressees and may not be disclosed to anyone else without consent from On Demand. If you are not the named addressee you must not use, disclose, distribute, copy, print or rely on the contents of this email and should destroy it immediately. Whilst On Demand takes care to protect its systems from electronic virus attack or other harmful event, the firm gives no warranty that this email message (including any attachments to it) is free of any virus or other harmful matter and accepts no responsibility for any loss or damage resulting from the recipient receiving, opening or using it. If you need any further information, please contact the originator of this message on +44 (0)20 7131 6700. Website: www.ondemand.co.uk. Registered Office: 1 Stephen Street, London, W1T 1AL. Registered in the UK No.4094951. This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test classpath problem in multi module project
Thanks Stefan, Very helpful. Just a question: You said you're using only one persistence.xml for both, testing and live deployment. How do you specify different Hibernate properties for those, eg dialect (Oracle vs HSQLDB), auto create schema (on vs off), etc? Cheers, Petr The information contained in this email and its attachments is confidential and may be the subject of legal, professional or other privileged information. It is intended only for the named addressees and may not be disclosed to anyone else without consent from On Demand. If you are not the named addressee you must not use, disclose, distribute, copy, print or rely on the contents of this email and should destroy it immediately. Whilst On Demand takes care to protect its systems from electronic virus attack or other harmful event, the firm gives no warranty that this email message (including any attachments to it) is free of any virus or other harmful matter and accepts no responsibility for any loss or damage resulting from the recipient receiving, opening or using it. If you need any further information, please contact the originator of this message on +44 (0)20 7131 6700. Website: www.ondemand.co.uk. Registered Office: 1 Stephen Street, London, W1T 1AL. Registered in the UK No.4094951. This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com
Re: Test classpath problem in multi module project
Hi Petr,
is seems to me that you're trying to work around maven mechanisms, which
is usually not a good idea. In this case, although I haven't completely
understood what you are trying to do, I can share some experience about
EJB3 and Testing.
I have one artifact P where the JBoss embedded container xml files are
in P/src/test/resources:
-- default.persistence.properties
-- ejb3-interceptors-aop.xml
-- embedded-jboss-beans.xml
Of P I build a test-jar. P has dependencies to
-- jboss-ejb3-all
-- thirdparty-all
-- hibernate-all
JARs as system.
The artifacts A...O contain EJB3 beans, with only a persistence.xml in
A/src/main/resources/META-INF
which is the production persistence.xml and usually only contains the
jta-data-source. The artifacts also contain a test-scope dependency to
the test-jar of P.
There is no other persistence.xml in the projects.
Then I changed embedded-jboss-beans.xml so that our own datasources are
being created as HSQLDB instances.
For testing EJB3 within their own build cycle, a trick is needed: in
I declare that the normal tests should not be run in
the "test" phase, but rather in the "integration-test" phase:
maven-surefire-plugin
true
integration-test
test
${maven.test.skip.exec}
This has two advantages: Firstly, the built jar is available during the
tests, secondly, the other dependencies are available as JAR files, not
as directories.
Then, I have created an Abstract Test Case in P/src/test/java/...:
--- SNIP
import java.io.File;
import java.net.URISyntaxException;
import junit.framework.TestCase;
import org.jboss.ejb3.embedded.EJB3StandaloneBootstrap;
public abstract class AbstractEJB3TestCase extends TestCase {
public AbstractEJB3TestCase() {
super();
}
public AbstractEJB3TestCase(String _name) {
super(_name);
}
public void addEJB3BeanJar(Class _class) {
appendPathToClasspath(_class.getResource(
"/" + _class.getCanonicalName().replace(".", "/") +
".class").toString().replaceAll(
"-client.jar!", ".jar!").replaceFirst("jar:file:([^!]+).*",
"$1"));
}
@Override
protected void setUp() throws Exception {
System.setProperty("java.naming.factory.initial",
"org.jnp.interfaces.LocalOnlyContextFactory");
System.setProperty("java.naming.factory.url.pkgs",
"org.jboss.naming:org.jnp.interfaces");
addBuildJarToClasspath();
EJB3StandaloneBootstrap.boot(null);
EJB3StandaloneBootstrap.scanClasspath();
}
protected void addBuildJarToClasspath() throws URISyntaxException {
final File targetDir = new
File(this.getClass().getResource("/").toURI()).getParentFile();
File myJar = null;
for (File f : targetDir.listFiles()) {
final String name = f.getName();
if (name.endsWith(".jar") && !name.contains("-test") &&
!name.contains("-client")) {
myJar = f;
break;
}
}
if (myJar != null) {
appendPathToClasspath(myJar.getAbsolutePath());
} else {
System.err.println("WARNING: JAR could not be found in the
classpath.");
System.err.println("Make sure that surefire runs in phase "
+ "\u00bbintegration-test\u00ab, not in the default
phase \u00bbtest\u00ab.");
}
}
protected void appendPathToClasspath(final String _ap) {
final String oldCP = System.getProperty("java.class.path");
if (oldCP.contains(_ap) || !_ap.endsWith(".jar")) {
return;
}
System.setProperty("java.class.path", oldCP +
File.pathSeparatorChar + _ap);
}
@Override
protected void tearDown() throws Exception {
EJB3StandaloneBootstrap.shutdown();
}
}
--- SNIP
This will do several things: Firstly, it searches for the jar that has
just been built by accessing "/" through the classloader, secondly, it
will modify java.class.path in order that the JBoss embedded deployer
will find the JARs and deploy them, thirdly, it allows you to specify
any EJB3 bean class in addEJB3BeanJar and will search for the
appropriate JAR file in the classpath and will add it to java.class.path.
The in the EJB3 modules, your test cases just need to extend the
abstract test case, and your EJB3 beans will be deployed just like in
production environment, but to a local in-memory HSQLDB. You can insert
test data after the deploy using dbUnit. You can test your beans without
any mock objects and just as if you had a JBoss running.
Hope that this was not too long,
Stefan
Petr Nejedly wrote:
Hi guys,
I'm trying to solve this issue for a few days and haven't been able to
crack it so far.
Test classpath problem in multi module project
Hi guys, I'm trying to solve this issue for a few days and haven't been able to crack it so far. The scenario is following: I have a parent project that includes sub-modules, each having their own pom.xml. Each of these modules produces an ejb3 package. I want to be able to run unit/integration tests using the JBoss embedded container on those modules from the parent project (so that it builds all modules). The resources are different for the test phase from the ones to be deployed (obviously). Normally it could all be achieved using src/main/resources and src/test/tesources but in this case SureFire can see all the resource files on its classpath and tries to use them (eg persistence.xml -> tries to deploy test AND live persistence units which fails the tests). I kind of hacked it so that I'm able to run tests in one module and package it. I end up with the following structure: A --target classes --META-INF (incl resources for tests, dependent modules can use these, when deploying this module's EJBs in the embedded JBoss for example) test-classes --A.jar (includes META-INF with resources for deployment) When I run the build from the parent project though, it builds the first one properly (eg A.jar) and when testing project B (which depends on A) it can see on its classpath A/target/classes + A/target/test-classes (this includes the proper resources for passing the tests) AND the built A.jar (deployment - ready, including resources that fail the tests). Dependency in B pom.xml is: foo A ejb provided Is there a way how to exclude built A.jar from classpath when two modules are dependent? Hope this makes sense, Petr The information contained in this email and its attachments is confidential and may be the subject of legal, professional or other privileged information. It is intended only for the named addressees and may not be disclosed to anyone else without consent from On Demand. If you are not the named addressee you must not use, disclose, distribute, copy, print or rely on the contents of this email and should destroy it immediately. Whilst On Demand takes care to protect its systems from electronic virus attack or other harmful event, the firm gives no warranty that this email message (including any attachments to it) is free of any virus or other harmful matter and accepts no responsibility for any loss or damage resulting from the recipient receiving, opening or using it. If you need any further information, please contact the originator of this message on +44 (0)20 7131 6700. Website: www.ondemand.co.uk. Registered Office: 1 Stephen Street, London, W1T 1AL. Registered in the UK No.4094951. This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com
