Ok, I have a little something for you to try if you can. I've
tightened up the code so it isn't so strict on "app clients" that
don't have META-INF/application-client.xml files. If there are issues
with the jar and it qualifies as an application client because it has
a Main-Class entry, but doesn't explicitly have an META-INF/
application-client.xml file, then we just log it as a warning and
continue with the deployment.
I've published new 3.1.2-SNAPSHOT binaries. If you could give them a
try and let us know if your deployment works, that'd be great.
Still some work to do to see if there's some way to get the include/
exclude settings to allow for the module to be ignored altogether.
Seems the warning might get annoying and it'd be nice to have a way to
ignore the module rather than simply ignore the issues with the module.
-David
On Jul 26, 2009, at 7:59 PM, David Blevins wrote:
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.
