Andreas,
Figured out the "issue" with the include/exclude feature. I use issue
in quotes as it works fine, I simply forgot some of the nuances with
it. Definitely need to add them to the documentation.
Long story short, in 3.0 through 3.1.x the include/exclude properties
will filter out modules that have descriptors if you set this flag:
openejb.deployments.classpath.filter.descriptors=true
Note that the default include/exclude setting does not allow anything
through, so you will want to open it up a bit. The current code
filters the classpath using the exclude setting then the filters the
resulting list using the includes. So it's exclude then include --
therefore include cannot include anything that has been excluded via
the exclude setting.
Working on two features here:
1. Should be possible to specify the order you want include and
exclude applied.
2. Really "app client" jars that just have Main-Class specified and
have no META-INF/application-client.xml should be treated as
"annotated" jars and should be ignored with the default settings.
-David
On Aug 4, 2009, at 10:48 PM, David Blevins wrote:
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.
