Packaging utility classes in an .ear

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Packaging utility classes in an .ear

Francesco Marchioni
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Packaging utility classes in an .ear

Stuart Douglas
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Packaging utility classes in an .ear

Francesco Marchioni
yes, thanks I've added the newline at the end of the Class-Path.

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 <[hidden email]>
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev



_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Packaging utility classes in an .ear

Jaikiran Pai
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 <[hidden email]
> <mailto:[hidden email]>>
>
>     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
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Packaging utility classes in an .ear

Francesco Marchioni
>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 <[hidden email]>
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 <[hidden email]
> <mailto:[hidden email]>>
>
>     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
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Packaging utility classes in an .ear

Jaikiran Pai
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 <[hidden email] <mailto:[hidden email]>>
>
>     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 <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email]
>     <mailto:[hidden email]>>>
>     >
>     >     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
>     > > [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > jboss-as7-dev mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>     _______________________________________________
>     jboss-as7-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Packaging utility classes in an .ear

Francesco Marchioni
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 <[hidden email]>
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 <[hidden email] <mailto:[hidden email]>>
>
>     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 <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email]
>     <mailto:[hidden email]>>>
>     >
>     >     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
>     > > [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > jboss-as7-dev mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>     _______________________________________________
>     jboss-as7-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Packaging utility classes in an .ear

Francesco Marchioni
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 <[hidden email]>
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 <[hidden email]>
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 <[hidden email] <mailto:[hidden email]>>
>
>     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 <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email]
>     <mailto:[hidden email]>>>
>     >
>     >     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
>     > > [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > jboss-as7-dev mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>     _______________________________________________
>     jboss-as7-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev



_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Packaging utility classes in an .ear

Carlo de Wolf
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 <[hidden email]>
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 <[hidden email]>
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 <[hidden email] <mailto:[hidden email]>>
>
>     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 <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email]
>     <mailto:[hidden email]>>>
>     >
>     >     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
>     > > [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > jboss-as7-dev mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>     _______________________________________________
>     jboss-as7-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________ jboss-as7-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Packaging utility classes in an .ear

Francesco Marchioni
That's true - I apologize for the mess ! I could successfully complete the test also on the JAVA module.

2011/7/13 Carlo de Wolf <[hidden email]>
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 <[hidden email]>
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 <[hidden email]>
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 <[hidden email] <mailto:[hidden email]>>
>
>     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 <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email]
>     <mailto:[hidden email]>>>
>     >
>     >     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
>     > > [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > jboss-as7-dev mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>     _______________________________________________
>     jboss-as7-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________ jboss-as7-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/jboss-as7-dev



_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Packaging utility classes in an .ear

Jason T. Greene
In reply to this post by Carlo de Wolf
iIRC we treat it like ear/lib

Sent from my iPad

On Jul 13, 2011, at 7:51 AM, Carlo de Wolf <[hidden email]> 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 <[hidden email]>
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 <[hidden email]>
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 <[hidden email] <mailto:[hidden email]>>
>
>     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 <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email]
>     <mailto:[hidden email]>>>
>     >
>     >     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
>     > > [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > jboss-as7-dev mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>     _______________________________________________
>     jboss-as7-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________ jboss-as7-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Packaging utility classes in an .ear

Francesco Marchioni
>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 <[hidden email]>
iIRC we treat it like ear/lib

Sent from my iPad

On Jul 13, 2011, at 7:51 AM, Carlo de Wolf <[hidden email]> 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 <[hidden email][hidden email]>
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 <[hidden email][hidden email]>
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 <[hidden email][hidden email] <mailto:[hidden email][hidden email]>>
>
>     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 <[hidden email][hidden email]
>     <mailto:[hidden email][hidden email]>
>     > <mailto:[hidden email][hidden email]
>     <mailto:[hidden email][hidden email]>>>
>     >
>     >     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
>     > > [hidden email][hidden email]
>     <mailto:[hidden email][hidden email]>
>     <mailto:[hidden email][hidden email]
>     <mailto:[hidden email][hidden email]>>
>     > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > jboss-as7-dev mailing list
>     > [hidden email][hidden email] <mailto:[hidden email][hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>     _______________________________________________
>     jboss-as7-dev mailing list
>     [hidden email][hidden email] <mailto:[hidden email][hidden email]>
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email][hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email][hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________ jboss-as7-dev mailing list [hidden email][hidden email] https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Packaging utility classes in an .ear

Carlo de Wolf
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 <[hidden email]>
iIRC we treat it like ear/lib

Sent from my iPad

On Jul 13, 2011, at 7:51 AM, Carlo de Wolf <[hidden email]> 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 <[hidden email]>
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 <[hidden email]>
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 <[hidden email] <mailto:[hidden email]>>
>
>     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 <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email]
>     <mailto:[hidden email]>>>
>     >
>     >     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
>     > > [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > jboss-as7-dev mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>     _______________________________________________
>     jboss-as7-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________ jboss-as7-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev



_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: Packaging utility classes in an .ear

Francesco Marchioni
Good point, probably unknown to many users......

2011/7/18 Carlo de Wolf <[hidden email]>
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 <[hidden email]>
iIRC we treat it like ear/lib

Sent from my iPad

On Jul 13, 2011, at 7:51 AM, Carlo de Wolf <[hidden email]> 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 <[hidden email]>
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 <[hidden email]>
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 <[hidden email] <mailto:[hidden email]>>
>
>     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 <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email]
>     <mailto:[hidden email]>>>
>     >
>     >     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
>     > > [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > jboss-as7-dev mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>     _______________________________________________
>     jboss-as7-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________ jboss-as7-dev mailing list [hidden email] https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev