You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Andreas Karalus <an...@googlemail.com> on 2009/07/23 13:18:58 UTC
openejb tries to start org.apache.tools.ant.Main
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.
Re: openejb tries to start org.apache.tools.ant.Main
Posted by David Blevins <da...@visi.com>.
On Aug 24, 2009, at 8:26 AM, Andreas Karalus wrote:
>
> Dear David,
>
> I finally found a configuration that worked for our environment with
> the
> released version (3.1.1). Basically we allow only deployments of
> *easycredit* artefacts and the current target directory. Third party
> artefacts like ant, jexcel, jaxb-jxc are not scanned anymore.
>
> openejb.deployments.classpath.include=.*(easycredit|target).*
> openejb.deployments.classpath.filter.descriptors=true
>
> I would like to test the current fixes on 3.1.2-SNAPSHOT, could you
> give me
> a hint where to download the binaries (maven repo). Then I could
> give you
> feedback on it.
Published new maven snapshots for you at http://repository.apache.org/snapshots/
Thanks for volunteering to try them out!
-David
> David Blevins wrote:
>>
>> 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
>>
>
> --
> View this message in context: http://www.nabble.com/openejb-tries-to-start-org.apache.tools.ant.Main-tp24623745p25118025.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
>
Re: openejb tries to start org.apache.tools.ant.Main
Posted by Andreas Karalus <an...@googlemail.com>.
Dear David,
I finally found a configuration that worked for our environment with the
released version (3.1.1). Basically we allow only deployments of
*easycredit* artefacts and the current target directory. Third party
artefacts like ant, jexcel, jaxb-jxc are not scanned anymore.
openejb.deployments.classpath.include=.*(easycredit|target).*
openejb.deployments.classpath.filter.descriptors=true
I would like to test the current fixes on 3.1.2-SNAPSHOT, could you give me
a hint where to download the binaries (maven repo). Then I could give you
feedback on it.
regards,
andreas
David Blevins wrote:
>
> 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
>
--
View this message in context: http://www.nabble.com/openejb-tries-to-start-org.apache.tools.ant.Main-tp24623745p25118025.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: openejb tries to start org.apache.tools.ant.Main
Posted by David Blevins <da...@visi.com>.
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.
>>>
>>>
>>
>>
>
>
Re: openejb tries to start org.apache.tools.ant.Main
Posted by David Blevins <da...@visi.com>.
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.
>>
>>
>
>
Re: openejb tries to start org.apache.tools.ant.Main
Posted by David Blevins <da...@visi.com>.
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.
>
>