[jboss-as7-dev] Packaging utility classes in an .ear
Carlo de Wolf
cdewolf at redhat.com
Mon Jul 18 14:16:40 EDT 2011
From the book of Java EE 6 Final Release EE.8.4.1 3e extra note:
Note that the presence of component-declaring annotations in shared
artifacts, such as libraries in the library directory and libraries
referenced by more than one module through Class-Path references, can
have unintended and undesirable consequences and is not recommended.
Carlo
On 07/18/2011 04:23 PM, Francesco Marchioni wrote:
> >iIRC we treat it like ear/lib
> Absolutely clear. On the other hand, I've observed that moving the EJB
> 3 library within the ear/lib folder trigger an unsatisfied dependency.
> Not sure if it's as per JEE specs, however I've got some customers
> using GlassFish V3 that reported the same issue. The official reply
> was that because of annotations components in the shared lib are
> created twide and hence the deployment failure.
> Thanks
> Francesco
>
>
> 2011/7/16 Jason Greene <jgreene at redhat.com <mailto:jgreene at redhat.com>>
>
> iIRC we treat it like ear/lib
>
> Sent from my iPad
>
> On Jul 13, 2011, at 7:51 AM, Carlo de Wolf <cdewolf at redhat.com
> <mailto:cdewolf at redhat.com>> wrote:
>
>> A Class-Path element in the META-INF/MANIFEST.MF of an ear is
>> invalid.
>> You need to put it in the war.
>>
>> Carlo
>>
>> On 07/13/2011 01:12 PM, Francesco Marchioni wrote:
>>> Did some more tests today.
>>> I've turned the utility.jar JAVA module into an EJB module and
>>> packed it
>>>
>>> enterprise.ear
>>> |
>>> | utility.jar (EJB Module)
>>> | webapp.war
>>> |
>>> | META-INF/MANIFEST.MF
>>> | META-INF/jboss-deployment-stucture.xml
>>>
>>> I've forced class isolation so that classes cannot be seen
>>> without a a Class-Path entry
>>> <ear-subdeployments-isolated>true</ear-subdeployments-isolated>
>>>
>>> Now the EJB classes from utility.jar are successfully loaded by
>>> webapp.war --JUST-- Class-Path needs to be placed into the
>>> subdeployment module ( into webapp.war). When Class-Path is
>>> placed in the EAR/ META-INF/MANIFEST.MF the EJB classes fail to
>>> be loaded.
>>>
>>> Reproducing this test case is quite simple - I wonder if this
>>> can be classified as a bug.
>>> Thanks
>>> Francesco
>>>
>>> 2011/7/12 Francesco Marchioni <marchioni.francesco at gmail.com
>>> <mailto:marchioni.francesco at gmail.com>>
>>>
>>> Sure.
>>>
>>> The sample.Test servlet (WebApp1.war) attempts to use the
>>> sample.Utility class (Utility.jar) packaged
>>>
>>>
>>> 16:23:58,576 ERROR
>>> [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/WebApp1].[sample.Test]]
>>> (http--127.0.0.1-8080-1) Servlet.service() for servlet
>>> sample.Test threw exception:
>>> java.lang.ClassNotFoundException: sample.Utility from
>>> [Module "deployment.EnterpriseApp.ear.WebApp1.war:main" from
>>> Service Module Loader]
>>> at
>>> org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
>>> at
>>> org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
>>> at
>>> org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
>>> at
>>> org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
>>> at
>>> org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
>>> at sample.Test.doGet(Test.java:36) [classes:]
>>> at
>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
>>> [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
>>> at
>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>>> [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
>>> [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
>>> at
>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
>>> [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
>>> at
>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
>>> [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
>>> at
>>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
>>> [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
>>> at
>>> org.jboss.as.web.NamingValve.invoke(NamingValve.java:57)
>>> [jboss-as-web-7.0.0.CR1.jar:7.0.0.CR1]
>>> at
>>> org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49)
>>> [jboss-as-jpa-7.0.0.CR1.jar:7.0.0.CR1]
>>> at
>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
>>> [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
>>> at
>>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>>> [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
>>> at
>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>>> [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
>>> at
>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
>>> [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
>>> at
>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
>>> [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
>>> at
>>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667)
>>> [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
>>> at
>>> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)
>>> [jbossweb-7.0.0.CR4.jar:7.0.0.CR1]
>>> at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
>>>
>>>
>>> META-INF/MANIFEST.MF is
>>>
>>> Manifest-Version: 1.0
>>> Class-Path: Utility.jar
>>>
>>> (I've checked also without Manifest-Version: 1.0 declaration)
>>> I guess tomorrow with some skull bash, will get it to work
>>> :-) )
>>>
>>>
>>>
>>>
>>> 2011/7/12 Jaikiran Pai <jpai at redhat.com
>>> <mailto:jpai at redhat.com>>
>>>
>>> Okay. Can you please post the entire exception
>>> stacktrace? That'll give
>>> us an hint on what might be wrong. Also please post the
>>> exact contents
>>> of the .ear/META-INF/MANIFEST.MF file.
>>>
>>> -Jaikiran
>>> On Tuesday 12 July 2011 06:51 PM, Francesco Marchioni wrote:
>>> > >Just to be clear, did that newline fix the issue?
>>> > Hi Jaikiran. No that didn't fix it. On the other hand,
>>> the library is
>>> > correctly picked up in the EAR/lib folder, just not at
>>> the root of the
>>> > archive.
>>> >
>>> > 2011/7/12 Jaikiran Pai <jpai at redhat.com
>>> <mailto:jpai at redhat.com> <mailto:jpai at redhat.com
>>> <mailto:jpai at redhat.com>>>
>>> >
>>> > On Tuesday 12 July 2011 05:22 PM, Francesco
>>> Marchioni wrote:
>>> > > yes, thanks I've added the newline at the end of the
>>> Class-Path.
>>> > Just to be clear, did that newline fix the issue?
>>> >
>>> > -Jaikiran
>>> >
>>> > >
>>> > > What I find odd, is that adding to to
>>> jboss-deployment-structure.xml
>>> > > the resources element, deployment fails because the
>>> Utility
>>> > module has
>>> > > been already loaded.....
>>> > >
>>> > > <jboss-deployment-structure>
>>> > >
>>> > > <deployment>
>>> > >
>>> > > <resources>
>>> > > <resource-root path="Utility.jar" />
>>> > > </resources>
>>> > > </deployment>
>>> > >
>>> > > </jboss-deployment-structure>
>>> > >
>>> > >
>>> > > Caused by:
>>> org.jboss.msc.service.DuplicateServiceException: Service
>>> > >
>>> >
>>> jboss.module.information.service."deployment.EnterpriseApp.ear.Utility.jar".main
>>> > > is already registered
>>> > >
>>> > > ......walking in the dark........
>>> > >
>>> > >
>>> > > 2011/7/12 Stuart Douglas <stuart.w.douglas at gmail.com
>>> <mailto:stuart.w.douglas at gmail.com>
>>> > <mailto:stuart.w.douglas at gmail.com
>>> <mailto:stuart.w.douglas at gmail.com>>
>>> > > <mailto:stuart.w.douglas at gmail.com
>>> <mailto:stuart.w.douglas at gmail.com>
>>> > <mailto:stuart.w.douglas at gmail.com
>>> <mailto:stuart.w.douglas at gmail.com>>>>
>>> > >
>>> > > This should work, and there are tests for this
>>> in the test
>>> > suite.
>>> > > Are you missing a newline at the end of the
>>> Class-Path: line in
>>> > > the manifest by any chance?
>>> > >
>>> > > For some really annoying reason the JDK manifest
>>> processing
>>> > stuff
>>> > > does not work unless there is newline at the end
>>> of the file.
>>> > >
>>> > > Stuart
>>> > >
>>> > >
>>> > > On 12/07/2011, at 7:06 PM, Francesco Marchioni
>>> wrote:
>>> > >
>>> > > > Dear devs,
>>> > > > I'm testing .ear classloading with utility classes
>>> packaged in
>>> > > the Enterprise Archive.
>>> > > > The following case test fails, so I'm wondering if
>>> it's my
>>> > > misundertanding or a bug:
>>> > > >
>>> > > > application.ear
>>> > > > |
>>> > > > | Webapplication.war
>>> > > > | Utility.jar
>>> > > > |
>>> > > > | META-INF/MANIFEST.MF
>>> > > >
>>> > > > Manifest file contains the Java EE compliant
>>> dependency to the
>>> > > class Utility.jar
>>> > > > Class-Path: Utility.jar
>>> > > >
>>> > > > However, the Webapplication fails to load the
>>> classes from
>>> > > Utility.jar, which are instead correctly
>>> pickedup if I move them
>>> > > into the ear's lib folder.
>>> > > >
>>> > > > As side note - I've tried also stating isolated
>>> deployments to
>>> > > false, in jboss-deployment-structure.xml (which
>>> should default)
>>> > > without success:
>>> > > > <jboss-deployment-structure>
>>> > > >
>>> <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
>>> > > > </jboss-deployment-structure>
>>> > > >
>>> > > > Any suggestion?
>>> > > > Thanks a lot
>>> > > > Francesco
>>> > > > _______________________________________________
>>> > > > jboss-as7-dev mailing list
>>> > > > jboss-as7-dev at lists.jboss.org
>>> <mailto:jboss-as7-dev at lists.jboss.org>
>>> > <mailto:jboss-as7-dev at lists.jboss.org
>>> <mailto:jboss-as7-dev at lists.jboss.org>>
>>> > <mailto:jboss-as7-dev at lists.jboss.org
>>> <mailto:jboss-as7-dev at lists.jboss.org>
>>> > <mailto:jboss-as7-dev at lists.jboss.org
>>> <mailto:jboss-as7-dev at lists.jboss.org>>>
>>> > > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > _______________________________________________
>>> > > jboss-as7-dev mailing list
>>> > > jboss-as7-dev at lists.jboss.org
>>> <mailto:jboss-as7-dev at lists.jboss.org>
>>> <mailto:jboss-as7-dev at lists.jboss.org
>>> <mailto:jboss-as7-dev at lists.jboss.org>>
>>> > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> >
>>> > _______________________________________________
>>> > jboss-as7-dev mailing list
>>> > jboss-as7-dev at lists.jboss.org
>>> <mailto:jboss-as7-dev at lists.jboss.org>
>>> <mailto:jboss-as7-dev at lists.jboss.org
>>> <mailto:jboss-as7-dev at lists.jboss.org>>
>>> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > jboss-as7-dev mailing list
>>> > jboss-as7-dev at lists.jboss.org
>>> <mailto:jboss-as7-dev at lists.jboss.org>
>>> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> <mailto:jboss-as7-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org <mailto:jboss-as7-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org <mailto:jboss-as7-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20110718/5cf8d39b/attachment-0001.html
More information about the jboss-as7-dev
mailing list