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 <scope>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
<build><plugins> I declare that the normal tests should not be run in
the "test" phase, but rather in the "integration-test" phase:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<skipExec>true</skipExec>
</configuration>
<executions>
<execution>
<phase>integration-test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<skipExec>${maven.test.skip.exec}</skipExec>
</configuration>
</execution>
</executions>
</plugin>
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. 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:
<dependency>
<groupId>foo</groupId>
<artifactId>A</artifactId>
<type>ejb</type>
<scope>provided</scope>
</dependency>
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
--
best regards,
Stefan Seidel
software developer
________________________
VUB Printmedia GmbH
Chopinstraße 4
D-04103 Leipzig
Germany
tel. +49 (341) 9 60 50 07
fax. +49 (341) 9 60 50 92
mail. [EMAIL PROTECTED]
web. www.vub.de
HRB Köln 24015
UStID DE 122 649 251
GF Dr. Achim Preuss Neudorf,
Dr. Christian Preuss Neudorf
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
