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

Francesco Marchioni marchioni.francesco at gmail.com
Wed Jul 13 07:12:10 EDT 2011


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>

> 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>
>
>> 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>>
>> >
>> >     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>>>
>> >     >
>> >     >     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>>
>> >     > > 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
>> > 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/20110713/46e3d84c/attachment.html 


More information about the jboss-as7-dev mailing list