[jboss-as7-dev] Packaging utility classes in an .ear

Francesco Marchioni marchioni.francesco at gmail.com
Mon Jul 18 10:23:42 EDT 2011 

>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>

> 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> 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>
> 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>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>jpai at redhat.com <mailto:<jpai at redhat.com>
>>> 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>
>>> stuart.w.douglas at gmail.com
>>> >     <mailto: <stuart.w.douglas at gmail.com>stuart.w.douglas at gmail.com>
>>> >     > <mailto: <stuart.w.douglas at gmail.com>stuart.w.douglas at gmail.com
>>> >     <mailto: <stuart.w.douglas at gmail.com>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>jboss-as7-dev at lists.jboss.org
>>> >     <mailto: <jboss-as7-dev at lists.jboss.org>
>>> jboss-as7-dev at lists.jboss.org>
>>> >     <mailto: <jboss-as7-dev at lists.jboss.org>
>>> jboss-as7-dev at lists.jboss.org
>>> >     <mailto: <jboss-as7-dev at lists.jboss.org>
>>> jboss-as7-dev at lists.jboss.org>>
>>> >     > > <https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> >     >
>>> >     >
>>> >     >
>>> >     >
>>> >     > _______________________________________________
>>> >     > jboss-as7-dev mailing list
>>> >     > <jboss-as7-dev at lists.jboss.org>jboss-as7-dev at lists.jboss.org<mailto:<jboss-as7-dev at lists.jboss.org>
>>> jboss-as7-dev at lists.jboss.org>
>>> >     > <https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> >
>>> >     _______________________________________________
>>> >     jboss-as7-dev mailing list
>>> >     <jboss-as7-dev at lists.jboss.org>jboss-as7-dev at lists.jboss.org<mailto:<jboss-as7-dev at lists.jboss.org>
>>> jboss-as7-dev at lists.jboss.org>
>>> >     <https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > jboss-as7-dev mailing list
>>> > <jboss-as7-dev at lists.jboss.org>jboss-as7-dev at lists.jboss.org
>>> > <https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>>  <jboss-as7-dev at lists.jboss.org>jboss-as7-dev at lists.jboss.org
>>>  <https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>
>>
>
> _______________________________________________
> jboss-as7-dev mailing list <jboss-as7-dev at lists.jboss.org>jboss-as7-dev at lists.jboss.org <https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> 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/53cb1662/attachment-0001.html

More information about the jboss-as7-dev mailing list