You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by David Blevins <da...@visi.com> on 2009/08/05 07:48:39 UTC
Re: openejb tries to start org.apache.tools.ant.Main
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>.
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.
>>>
>>>
>>
>>
>
>