Going to have to take a look at the app client deployment code again
and see exactly what is different. Any jar in the classpath that is
using the "Main-Class" attribute in the MANIFEST.MF is potentially a
java ee app client that uses annotations instead (or in addition to) a
META-INF/application-client.xml. I can't think of a situation where
we would have skipped one and not checked the main class for
annotations, but it may be we were more forgiving with bogus main
classes (or less aggressive about reporting them) than we are now.
Filed a "Task" here:
https://issues.apache.org/jira/browse/OPENEJB-1054
I have a hunch it might simply be that we ignored app client jars (aka
Client Modules) in the classpath for embedded testing up until
recently. We turned them on now so people can use the @LocalClient
support (see testcase-injection in the examples).
Definitely if that commons-jxpath is not valid if it lists a Main-
Class that isn't actually in the jar itself -- not legal to list a
class in another jar. There's nothing we use that pulls in that jar,
I don't even have it in my local repo, guessing it comes from
Hibernate or something in that camp.
I can imagine a situation where you still might need a jar despite the
fact that it's invalid in the java ee sense and don't want us to fail
your deployment as a result of said jar. We can definitely add some
way for that to be communicated. The
'openejb.deployments.classpath.exclude' property might do the trick.
I'll give that possibility angle a look tomorrow as well. Feel free
to give it a whirl on your end.
Thanks for the report!
-David
On Jul 23, 2009, at 4:18 AM, Andreas Karalus wrote:
some strange behaviour while trying to switch to openejb 3.1.1
The Container tries to automatically load org.apache.tools.ant.Main
which is
not in classpath but is a transitive dependency in maven.
This was not the case with openejb 3.0.
org.apache.openejb.OpenEJBException: Unable to load Client main-class:
org.apache.tools.ant.Main: org.apache.tools.ant.Main
at
org.apache.openejb.config.AnnotationDeployer
$ProcessAnnotatedBeans.deploy(AnnotationDeployer.java:668)
at
org.apache.openejb.config.AnnotationDeployer
$ProcessAnnotatedBeans.deploy(AnnotationDeployer.java:624)
at
org
.apache
.openejb.config.AnnotationDeployer.deploy(AnnotationDeployer.java:186)
at
org.apache.openejb.config.ConfigurationFactory
$Chain.deploy(ConfigurationFactory.java:247)
at
org
.apache
.openejb
.config
.ConfigurationFactory.configureApplication(ConfigurationFactory.java:
601)
at
org
.apache
.openejb
.config
.ConfigurationFactory.configureApplication(ConfigurationFactory.java:
551)
at
org
.apache
.openejb
.config
.ConfigurationFactory
.getOpenEjbConfiguration(ConfigurationFactory.java:380)
at
org
.apache
.openejb
.assembler.classic.Assembler.getOpenEjbConfiguration(Assembler.java:
292)
at
org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:
271)
at org.apache.openejb.OpenEJB$Instance.<init>(OpenEJB.java:137)
at org.apache.openejb.OpenEJB.init(OpenEJB.java:286)
Ant seems to be a transitive dependency of commons-jxpath.
Running mvn dependency:tree gives a
[INFO] +- dom4j:dom4j:jar:1.6.1:provided
[INFO] | \- xml-apis:xml-apis:jar:1.0.b2:provided
[INFO] +- commons-collections:commons-collections:jar:3.1:provided
[INFO] +- jboss.jboss-as:hsqldb:jar:4.3.0.GA-CP01-EAP:test
[INFO] +- jboss.jboss-as:mail:jar:4.3.0.GA-CP01-EAP:provided
[INFO] +- commons-jxpath:commons-jxpath:jar:1.2:provided
[INFO] | +- ant:ant-optional:jar:1.5.1:provided
[INFO] | \- jdom:jdom:jar:1.0:provided (version managed from b9)
[INFO] \- antlr:stringtemplate:jar:3.0:provided
[INFO] \- antlr:antlr:jar:2.7.7:provided
-> We coud exclude the ant transitive dependency from commons-jxpath
in our
pom.xml ("<excludes>") as a workaround, but I think this should be
rather
get fixed in openejb? why does it try to start the ant Main class?
regards,
andreas
--
View this message in context:
http://www.nabble.com/openejb-tries-to-start-org.apache.tools.ant.Main-tp24623745p24623745.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
