4:06 a.m.
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
4:57 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
6:52 a.m.
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 <stuart.w.douglas(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
7:02 a.m.
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(a)gmail.com
<mailto:stuart.w.douglas@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(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
8:21 a.m.
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(a)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(a)gmail.com
> <mailto:stuart.w.douglas@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(a)lists.jboss.org <mailto:
jboss-as7-dev(a)lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
8:23 a.m.
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(a)redhat.com <mailto:jpai@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(a)gmail.com
<mailto:stuart.w.douglas@gmail.com>
> <mailto:stuart.w.douglas@gmail.com
<mailto:stuart.w.douglas@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(a)lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>
<mailto:jboss-as7-dev@lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>>
> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
10:32 a.m.
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(a)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(a)redhat.com <mailto:jpai@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(a)gmail.com
> <mailto:stuart.w.douglas@gmail.com>
> > <mailto:stuart.w.douglas@gmail.com
> <mailto:stuart.w.douglas@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(a)lists.jboss.org
> <mailto:jboss-as7-dev@lists.jboss.org>
> <mailto:jboss-as7-dev@lists.jboss.org
> <mailto:jboss-as7-dev@lists.jboss.org>>
> > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> >
> >
> >
> >
> > _______________________________________________
> > jboss-as7-dev mailing list
> > jboss-as7-dev(a)lists.jboss.org <mailto:
jboss-as7-dev(a)lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
6:12 a.m.
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(a)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(a)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(a)redhat.com <mailto:jpai@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(a)gmail.com
> > <mailto:stuart.w.douglas@gmail.com>
> > > <mailto:stuart.w.douglas@gmail.com
> > <mailto:stuart.w.douglas@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(a)lists.jboss.org
> > <mailto:jboss-as7-dev@lists.jboss.org>
> > <mailto:jboss-as7-dev@lists.jboss.org
> > <mailto:jboss-as7-dev@lists.jboss.org>>
> > > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > jboss-as7-dev mailing list
> > > jboss-as7-dev(a)lists.jboss.org <mailto:
> jboss-as7-dev(a)lists.jboss.org>
> > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> >
> > _______________________________________________
> > jboss-as7-dev mailing list
> > jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org
> >
> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> >
> >
> >
> >
> > _______________________________________________
> > jboss-as7-dev mailing list
> > jboss-as7-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
7:51 a.m.
A Class-Path element in the META-INF/MANIFEST.MF of an ear is invalid.
You need to put it in the war.
Carlo
On 07/13/2011 01:12 PM, Francesco Marchioni wrote:
Did some more tests today.
I've turned the utility.jar JAVA module into an EJB module and packed it
enterprise.ear
|
| utility.jar (EJB Module)
| webapp.war
|
| META-INF/MANIFEST.MF
| META-INF/jboss-deployment-stucture.xml
I've forced class isolation so that classes cannot be seen without a a
Class-Path entry
<ear-subdeployments-isolated>true</ear-subdeployments-isolated>
Now the EJB classes from utility.jar are successfully loaded by
webapp.war --JUST-- Class-Path needs to be placed into the
subdeployment module ( into webapp.war). When Class-Path is placed in
the EAR/ META-INF/MANIFEST.MF the EJB classes fail to be loaded.
Reproducing this test case is quite simple - I wonder if this can be
classified as a bug.
Thanks
Francesco
2011/7/12 Francesco Marchioni <marchioni.francesco(a)gmail.com
<mailto:marchioni.francesco@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(a)redhat.com <mailto:jpai@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(a)redhat.com
<mailto:jpai@redhat.com> <mailto:jpai@redhat.com
<mailto:jpai@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(a)gmail.com
<mailto:stuart.w.douglas@gmail.com>
> <mailto:stuart.w.douglas@gmail.com
<mailto:stuart.w.douglas@gmail.com>>
> > <mailto:stuart.w.douglas@gmail.com
<mailto:stuart.w.douglas@gmail.com>
> <mailto:stuart.w.douglas@gmail.com
<mailto:stuart.w.douglas@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(a)lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>
> <mailto:jboss-as7-dev@lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>>
> <mailto:jboss-as7-dev@lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>
> <mailto:jboss-as7-dev@lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>>>
> > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> >
> >
> >
> >
> > _______________________________________________
> > jboss-as7-dev mailing list
> > jboss-as7-dev(a)lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>
<mailto:jboss-as7-dev@lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>>
> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>
<mailto:jboss-as7-dev@lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>>
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
1:53 a.m.
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 <cdewolf(a)redhat.com>
**
A Class-Path element in the META-INF/MANIFEST.MF of an ear is invalid.
You need to put it in the war.
Carlo
On 07/13/2011 01:12 PM, Francesco Marchioni wrote:
Did some more tests today.
I've turned the utility.jar JAVA module into an EJB module and packed it
enterprise.ear
|
| utility.jar (EJB Module)
| webapp.war
|
| META-INF/MANIFEST.MF
| META-INF/jboss-deployment-stucture.xml
I've forced class isolation so that classes cannot be seen without a a
Class-Path entry
<ear-subdeployments-isolated>true</ear-subdeployments-isolated>
Now the EJB classes from utility.jar are successfully loaded by webapp.war
--JUST-- Class-Path needs to be placed into the subdeployment module ( into
webapp.war). When Class-Path is placed in the EAR/ META-INF/MANIFEST.MF the
EJB classes fail to be loaded.
Reproducing this test case is quite simple - I wonder if this can be
classified as a bug.
Thanks
Francesco
2011/7/12 Francesco Marchioni <marchioni.francesco(a)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(a)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(a)redhat.com
<mailto:jpai@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(a)gmail.com
>> > <mailto:stuart.w.douglas@gmail.com>
>> > > <mailto:stuart.w.douglas@gmail.com
>> > <mailto:stuart.w.douglas@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(a)lists.jboss.org
>> > <mailto:jboss-as7-dev@lists.jboss.org>
>> > <mailto:jboss-as7-dev@lists.jboss.org
>> > <mailto:jboss-as7-dev@lists.jboss.org>>
>> > > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> > >
>> > >
>> > >
>> > >
>> > > _______________________________________________
>> > > jboss-as7-dev mailing list
>> > > jboss-as7-dev(a)lists.jboss.org <mailto:
>> jboss-as7-dev(a)lists.jboss.org>
>> > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> >
>> > _______________________________________________
>> > jboss-as7-dev mailing list
>> > jboss-as7-dev(a)lists.jboss.org <mailto:
>> jboss-as7-dev(a)lists.jboss.org>
>> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > jboss-as7-dev mailing list
>> > jboss-as7-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>
>
_______________________________________________
jboss-as7-dev mailing
listjboss-as7-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/jboss-as7-dev
10:57 p.m.
iIRC we treat it like ear/lib
Sent from my iPad
On Jul 13, 2011, at 7:51 AM, Carlo de Wolf <cdewolf(a)redhat.com> wrote:
A Class-Path element in the META-INF/MANIFEST.MF of an ear is
invalid.
You need to put it in the war.
Carlo
On 07/13/2011 01:12 PM, Francesco Marchioni wrote:
>
> Did some more tests today.
> I've turned the utility.jar JAVA module into an EJB module and packed it
>
> enterprise.ear
> |
> | utility.jar (EJB Module)
> | webapp.war
> |
> | META-INF/MANIFEST.MF
> | META-INF/jboss-deployment-stucture.xml
>
> I've forced class isolation so that classes cannot be seen without a a Class-Path
entry
> <ear-subdeployments-isolated>true</ear-subdeployments-isolated>
>
> Now the EJB classes from utility.jar are successfully loaded by webapp.war --JUST--
Class-Path needs to be placed into the subdeployment module ( into webapp.war). When
Class-Path is placed in the EAR/ META-INF/MANIFEST.MF the EJB classes fail to be loaded.
>
> Reproducing this test case is quite simple - I wonder if this can be classified as a
bug.
> Thanks
> Francesco
>
> 2011/7/12 Francesco Marchioni <marchioni.francesco(a)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(a)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(a)redhat.com <mailto:jpai@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(a)gmail.com
> > <mailto:stuart.w.douglas@gmail.com>
> > > <mailto:stuart.w.douglas@gmail.com
> > <mailto:stuart.w.douglas@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(a)lists.jboss.org
> > <mailto:jboss-as7-dev@lists.jboss.org>
> > <mailto:jboss-as7-dev@lists.jboss.org
> > <mailto:jboss-as7-dev@lists.jboss.org>>
> > > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > jboss-as7-dev mailing list
> > > jboss-as7-dev(a)lists.jboss.org
<mailto:jboss-as7-dev@lists.jboss.org>
> > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> >
> > _______________________________________________
> > jboss-as7-dev mailing list
> > jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> >
> >
> >
> >
> > _______________________________________________
> > jboss-as7-dev mailing list
> > jboss-as7-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
9:23 a.m.
iIRC we treat it like ear/lib
Absolutely clear. On the other
hand, I've observed that moving the EJB 3
library within the ear/lib folder trigger an unsatisfied dependency. Not
sure if it's as per JEE specs, however I've got some customers using
GlassFish V3 that reported the same issue. The official reply was that
because of annotations components in the shared lib are created twide and
hence the deployment failure.
Thanks
Francesco
2011/7/16 Jason Greene <jgreene(a)redhat.com>
iIRC we treat it like ear/lib
Sent from my iPad
On Jul 13, 2011, at 7:51 AM, Carlo de Wolf <cdewolf(a)redhat.com> wrote:
A Class-Path element in the META-INF/MANIFEST.MF of an ear is invalid.
You need to put it in the war.
Carlo
On 07/13/2011 01:12 PM, Francesco Marchioni wrote:
Did some more tests today.
I've turned the utility.jar JAVA module into an EJB module and packed it
enterprise.ear
|
| utility.jar (EJB Module)
| webapp.war
|
| META-INF/MANIFEST.MF
| META-INF/jboss-deployment-stucture.xml
I've forced class isolation so that classes cannot be seen without a a
Class-Path entry
<ear-subdeployments-isolated>true</ear-subdeployments-isolated>
Now the EJB classes from utility.jar are successfully loaded by webapp.war
--JUST-- Class-Path needs to be placed into the subdeployment module ( into
webapp.war). When Class-Path is placed in the EAR/ META-INF/MANIFEST.MF the
EJB classes fail to be loaded.
Reproducing this test case is quite simple - I wonder if this can be
classified as a bug.
Thanks
Francesco
2011/7/12 Francesco Marchioni < <marchioni.francesco(a)gmail.com>
marchioni.francesco(a)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@redhat.com>jpai(a)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@redhat.com>jpai(a)redhat.com
<mailto:<jpai@redhat.com>
>> jpai(a)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(a)gmail.com>
>> stuart.w.douglas(a)gmail.com
>> > <mailto:
<stuart.w.douglas@gmail.com>stuart.w.douglas(a)gmail.com>
>> > > <mailto:
<stuart.w.douglas@gmail.com>stuart.w.douglas(a)gmail.com
>> > <mailto:
<stuart.w.douglas@gmail.com>stuart.w.douglas(a)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@lists.jboss.org>jboss-as7-dev(a)lists.jboss.org
>> > <mailto: <jboss-as7-dev(a)lists.jboss.org>
>> jboss-as7-dev(a)lists.jboss.org>
>> > <mailto: <jboss-as7-dev(a)lists.jboss.org>
>> jboss-as7-dev(a)lists.jboss.org
>> > <mailto: <jboss-as7-dev(a)lists.jboss.org>
>> jboss-as7-dev(a)lists.jboss.org>>
>> > > >
<https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> > >
>> > >
>> > >
>> > >
>> > > _______________________________________________
>> > > jboss-as7-dev mailing list
>> > >
<jboss-as7-dev@lists.jboss.org>jboss-as7-dev@lists.jboss.org<mailto:<jboss-as7-dev@lists.jboss.org>
>> jboss-as7-dev(a)lists.jboss.org>
>> > > <https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> >
>> > _______________________________________________
>> > jboss-as7-dev mailing list
>> >
<jboss-as7-dev@lists.jboss.org>jboss-as7-dev@lists.jboss.org<mailto:<jboss-as7-dev@lists.jboss.org>
>> jboss-as7-dev(a)lists.jboss.org>
>> > <https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > jboss-as7-dev mailing list
>> > <jboss-as7-dev@lists.jboss.org>jboss-as7-dev(a)lists.jboss.org
>> > <https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> <jboss-as7-dev@lists.jboss.org>jboss-as7-dev(a)lists.jboss.org
>> <https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>
>
_______________________________________________
jboss-as7-dev mailing list
<jboss-as7-dev@lists.jboss.org>jboss-as7-dev(a)lists.jboss.org
<https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>https://lists.j...
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
1:16 p.m.
From the book of Java EE 6 Final Release EE.8.4.1 3e extra note:
Note that the presence of component-declaring annotations in shared
artifacts, such as libraries in the library directory and libraries
referenced by more than one module through Class-Path references, can
have unintended and undesirable consequences and is not recommended.
Carlo
On 07/18/2011 04:23 PM, Francesco Marchioni wrote:
>iIRC we treat it like ear/lib
Absolutely clear. On the other hand, I've observed that moving the EJB
3 library within the ear/lib folder trigger an unsatisfied dependency.
Not sure if it's as per JEE specs, however I've got some customers
using GlassFish V3 that reported the same issue. The official reply
was that because of annotations components in the shared lib are
created twide and hence the deployment failure.
Thanks
Francesco
2011/7/16 Jason Greene <jgreene(a)redhat.com <mailto:jgreene@redhat.com>>
iIRC we treat it like ear/lib
Sent from my iPad
On Jul 13, 2011, at 7:51 AM, Carlo de Wolf <cdewolf(a)redhat.com
<mailto:cdewolf@redhat.com>> wrote:
> A Class-Path element in the META-INF/MANIFEST.MF of an ear is
> invalid.
> You need to put it in the war.
>
> Carlo
>
> On 07/13/2011 01:12 PM, Francesco Marchioni wrote:
>> Did some more tests today.
>> I've turned the utility.jar JAVA module into an EJB module and
>> packed it
>>
>> enterprise.ear
>> |
>> | utility.jar (EJB Module)
>> | webapp.war
>> |
>> | META-INF/MANIFEST.MF
>> | META-INF/jboss-deployment-stucture.xml
>>
>> I've forced class isolation so that classes cannot be seen
>> without a a Class-Path entry
>> <ear-subdeployments-isolated>true</ear-subdeployments-isolated>
>>
>> Now the EJB classes from utility.jar are successfully loaded by
>> webapp.war --JUST-- Class-Path needs to be placed into the
>> subdeployment module ( into webapp.war). When Class-Path is
>> placed in the EAR/ META-INF/MANIFEST.MF the EJB classes fail to
>> be loaded.
>>
>> Reproducing this test case is quite simple - I wonder if this
>> can be classified as a bug.
>> Thanks
>> Francesco
>>
>> 2011/7/12 Francesco Marchioni <marchioni.francesco(a)gmail.com
>> <mailto:marchioni.francesco@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(a)redhat.com
>> <mailto:jpai@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(a)redhat.com
>> <mailto:jpai@redhat.com> <mailto:jpai@redhat.com
>> <mailto:jpai@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(a)gmail.com
>> <mailto:stuart.w.douglas@gmail.com>
>> > <mailto:stuart.w.douglas@gmail.com
>> <mailto:stuart.w.douglas@gmail.com>>
>> > > <mailto:stuart.w.douglas@gmail.com
>> <mailto:stuart.w.douglas@gmail.com>
>> > <mailto:stuart.w.douglas@gmail.com
>> <mailto:stuart.w.douglas@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(a)lists.jboss.org
>> <mailto:jboss-as7-dev@lists.jboss.org>
>> > <mailto:jboss-as7-dev@lists.jboss.org
>> <mailto:jboss-as7-dev@lists.jboss.org>>
>> > <mailto:jboss-as7-dev@lists.jboss.org
>> <mailto:jboss-as7-dev@lists.jboss.org>
>> > <mailto:jboss-as7-dev@lists.jboss.org
>> <mailto:jboss-as7-dev@lists.jboss.org>>>
>> > > >
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> > >
>> > >
>> > >
>> > >
>> > > _______________________________________________
>> > > jboss-as7-dev mailing list
>> > > jboss-as7-dev(a)lists.jboss.org
>> <mailto:jboss-as7-dev@lists.jboss.org>
>> <mailto:jboss-as7-dev@lists.jboss.org
>> <mailto:jboss-as7-dev@lists.jboss.org>>
>> > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> >
>> > _______________________________________________
>> > jboss-as7-dev mailing list
>> > jboss-as7-dev(a)lists.jboss.org
>> <mailto:jboss-as7-dev@lists.jboss.org>
>> <mailto:jboss-as7-dev@lists.jboss.org
>> <mailto:jboss-as7-dev@lists.jboss.org>>
>> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > jboss-as7-dev mailing list
>> > jboss-as7-dev(a)lists.jboss.org
>> <mailto:jboss-as7-dev@lists.jboss.org>
>> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> <mailto:jboss-as7-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
2:49 a.m.
Good point, probably unknown to many users......
2011/7/18 Carlo de Wolf <cdewolf(a)redhat.com>
**
From the book of Java EE 6 Final Release EE.8.4.1 3e extra note:
Note that the presence of component-declaring annotations in shared
artifacts, such as libraries in the library directory and libraries
referenced by more than one module through Class-Path references, can have
unintended and undesirable consequences and is not recommended.
Carlo
On 07/18/2011 04:23 PM, Francesco Marchioni wrote:
>iIRC we treat it like ear/lib
Absolutely clear. On the other hand, I've observed that moving the EJB 3
library within the ear/lib folder trigger an unsatisfied dependency. Not
sure if it's as per JEE specs, however I've got some customers using
GlassFish V3 that reported the same issue. The official reply was that
because of annotations components in the shared lib are created twide and
hence the deployment failure.
Thanks
Francesco
2011/7/16 Jason Greene <jgreene(a)redhat.com>
> iIRC we treat it like ear/lib
>
> Sent from my iPad
>
> On Jul 13, 2011, at 7:51 AM, Carlo de Wolf <cdewolf(a)redhat.com> wrote:
>
> A Class-Path element in the META-INF/MANIFEST.MF of an ear is invalid.
> You need to put it in the war.
>
> Carlo
>
> On 07/13/2011 01:12 PM, Francesco Marchioni wrote:
>
> Did some more tests today.
> I've turned the utility.jar JAVA module into an EJB module and packed it
>
> enterprise.ear
> |
> | utility.jar (EJB Module)
> | webapp.war
> |
> | META-INF/MANIFEST.MF
> | META-INF/jboss-deployment-stucture.xml
>
> I've forced class isolation so that classes cannot be seen without a a
> Class-Path entry
> <ear-subdeployments-isolated>true</ear-subdeployments-isolated>
>
> Now the EJB classes from utility.jar are successfully loaded by webapp.war
> --JUST-- Class-Path needs to be placed into the subdeployment module ( into
> webapp.war). When Class-Path is placed in the EAR/ META-INF/MANIFEST.MF the
> EJB classes fail to be loaded.
>
> Reproducing this test case is quite simple - I wonder if this can be
> classified as a bug.
> Thanks
> Francesco
>
> 2011/7/12 Francesco Marchioni <marchioni.francesco(a)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(a)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(a)redhat.com
<mailto:jpai@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(a)gmail.com
>>> > <mailto:stuart.w.douglas@gmail.com>
>>> > > <mailto:stuart.w.douglas@gmail.com
>>> > <mailto:stuart.w.douglas@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(a)lists.jboss.org
>>> > <mailto:jboss-as7-dev@lists.jboss.org>
>>> > <mailto:jboss-as7-dev@lists.jboss.org
>>> > <mailto:jboss-as7-dev@lists.jboss.org>>
>>> > > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > _______________________________________________
>>> > > jboss-as7-dev mailing list
>>> > > jboss-as7-dev(a)lists.jboss.org <mailto:
>>> jboss-as7-dev(a)lists.jboss.org>
>>> > > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> >
>>> > _______________________________________________
>>> > jboss-as7-dev mailing list
>>> > jboss-as7-dev(a)lists.jboss.org <mailto:
>>> jboss-as7-dev(a)lists.jboss.org>
>>> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > jboss-as7-dev mailing list
>>> > jboss-as7-dev(a)lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>>
>>
>
> _______________________________________________
> jboss-as7-dev mailing
listjboss-as7-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
5267
days inactive
5274
days old
13 comments
5 participants
participants (5)
-
Carlo de Wolf -
Francesco Marchioni -
Jaikiran Pai -
Jason Greene -
Stuart Douglas