You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by jkastner <jk...@karchedon.de> on 2012/08/26 12:46:52 UTC
Deployment of CDI beans does not work for WARs wrapped in an EAR
Hi,
I've found an issue with deployment of WARs wrapped inside an EAR:
CDI beans located under [WEB-MODULE]/WEB-INF/classes inside the WAR are not
deployed;
It seems that the CDIScanner in this case seems to use the ClassLoader of
the AppModule,
but the path to the WAR beans is only registered to the ClassLoader of the
WebModule. Hence,
the CDI classes are ignored by the CDIScanner (see
org.apache.openejb.cdi.CDIScanner, line 174 in rev1377287)
Best regards,
Johannes
--
View this message in context: http://openejb.979440.n4.nabble.com/Deployment-of-CDI-beans-does-not-work-for-WARs-wrapped-in-an-EAR-tp4657110.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Deployment of CDI beans does not work for WARs wrapped in an EAR
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hmm, issame should be true
- Romain
Le 1 sept. 2012 12:07, "jkastner" <jk...@karchedon.de> a écrit :
> Hi,
>
> > Can you say us the exact failing condition (which part of the or)
>
> all parts eval to false (classes.add(clazz) is not called):
>
> if (!filterByClassLoader || comparator.isSame(cl) || (cl.equals(scl) &&
> startupObject.getWebContext() == null)) {
> classes.add(clazz);
> }
>
> > (sorry no computer here for some days)
> Thanks for your effort, anyway!
>
> -- Johannes
>
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Deployment-of-CDI-beans-does-not-work-for-WARs-wrapped-in-an-EAR-tp4657110p4657208.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>
Re: Deployment of CDI beans does not work for WARs wrapped in an
EAR
Posted by jkastner <jk...@karchedon.de>.
Hi,
> Can you say us the exact failing condition (which part of the or)
all parts eval to false (classes.add(clazz) is not called):
if (!filterByClassLoader || comparator.isSame(cl) || (cl.equals(scl) &&
startupObject.getWebContext() == null)) {
classes.add(clazz);
}
> (sorry no computer here for some days)
Thanks for your effort, anyway!
-- Johannes
--
View this message in context: http://openejb.979440.n4.nabble.com/Deployment-of-CDI-beans-does-not-work-for-WARs-wrapped-in-an-EAR-tp4657110p4657208.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Deployment of CDI beans does not work for WARs wrapped in an EAR
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Can you say us the exact failing condition (which part of the or)
(sorry no computer here for some days)
Le 31 août 2012 20:22, "jkastner" <jk...@karchedon.de> a écrit :
> Hi Romain,
>
> > I cant dig into it for 2 weeks but you should go twice in the scanner and
> > the second time with the webapp classloader. If the class cant be loaded
> > you have another issue.
>
> yes, you're right, CDIScanner.init() is called a second time, and in this
> call the class loading succeeeds.
> However, the bean class is still not added to the list of classes since the
> condition in the final if() evals to false:
>
> // 1. this classloader is the good one
> // 2. the classloader is the appclassloader one and we are
> in the ear parent
> if (!filterByClassLoader
> || comparator.isSame(cl) || (cl.equals(scl) &&
> startupObject.getWebContext() == null)) {
> classes.add(clazz);
> }
>
> Now, when I force classes.add(clazz), the bean seems to be set-up correctly
> by BeansDeployer.defineManagedBean(),
> but it still is not injected into the Facelet, so I'm quite puzzled...
>
> -- Johannes
>
>
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Deployment-of-CDI-beans-does-not-work-for-WARs-wrapped-in-an-EAR-tp4657110p4657196.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
>
Re: Deployment of CDI beans does not work for WARs wrapped in an
EAR
Posted by jkastner <jk...@karchedon.de>.
Hi Romain,
> I cant dig into it for 2 weeks but you should go twice in the scanner and
> the second time with the webapp classloader. If the class cant be loaded
> you have another issue.
yes, you're right, CDIScanner.init() is called a second time, and in this
call the class loading succeeeds.
However, the bean class is still not added to the list of classes since the
condition in the final if() evals to false:
// 1. this classloader is the good one
// 2. the classloader is the appclassloader one and we are
in the ear parent
if (!filterByClassLoader
|| comparator.isSame(cl) || (cl.equals(scl) &&
startupObject.getWebContext() == null)) {
classes.add(clazz);
}
Now, when I force classes.add(clazz), the bean seems to be set-up correctly
by BeansDeployer.defineManagedBean(),
but it still is not injected into the Facelet, so I'm quite puzzled...
-- Johannes
--
View this message in context: http://openejb.979440.n4.nabble.com/Deployment-of-CDI-beans-does-not-work-for-WARs-wrapped-in-an-EAR-tp4657110p4657196.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Deployment of CDI beans does not work for WARs wrapped in an EAR
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I cant dig into it for 2 weeks but you should go twice in the scanner and
the second time with the webapp classloader. If the class cant be loaded
you have another issue.
Can you system.out the classloaders (is it the webapp one the second time)
+ the class name please (we have some exclusions so maybe you have no luck)
- Romain
Le 27 août 2012 20:25, "jkastner" <jk...@karchedon.de> a écrit :
> Hi,
>
> yes, I'm using the most recent version from the trunk. I also assembled two
> simple test packages:
>
> http://openejb.979440.n4.nabble.com/file/n4657131/war_test.warwar_test.war
> contains a single bean annotated with @Named, and an index.xhtml using this
> bean; if the CDI scan was successful, the message "OK, CDI scan was
> successful" appears at /war_test.
>
> http://openejb.979440.n4.nabble.com/file/n4657131/ear_test.earear_test.ear
> just wraps this this WAR in an app module (web context /ear_test)
>
>
> Now, the war_test works in TomEE 1.1.0, but the ear_test fails.
> I did some debugging, and the most obvious difference to me is at the end
> of
> CDIScanner.init():
>
> // here for ears we need to skip classes in the parent
> classloader
> final ClassLoader scl = ClassLoader.getSystemClassLoader();
> final boolean filterByClassLoader =
>
> "true".equals(SystemInstance.get().getProperty(OPENEJB_CDI_FILTER_CLASSLOADER,
> "true"));
> for (String className : beans.managedClasses) {
> if (ejbClasses.contains(className)) continue;
> final Class clazz = load(className, classLoader);
> if (clazz == null) { <== **TRUE FOR EAR_TEST**
> continue;
> }
>
> final ClassLoader cl = clazz.getClassLoader();
> // 1. this classloader is the good one
> // 2. the classloader is the appclassloader one and we are
> in the ear parent
> if (!filterByClassLoader
> || comparator.isSame(cl) || (cl.equals(scl) &&
> startupObject.getWebContext() == null)) {
> classes.add(clazz);
> }
> }
>
> In both cases, the bean is listed in beans.managedClasses. But for the EAR,
> the bean cannot be loaded by the provided ClassLoader, and hence is never
> added to classes.
>
>
> -- Johannes
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Deployment-of-CDI-beans-does-not-work-for-WARs-wrapped-in-an-EAR-tp4657110p4657131.html
> Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Deployment of CDI beans does not work for WARs wrapped in an
EAR
Posted by jkastner <jk...@karchedon.de>.
Hi,
yes, I'm using the most recent version from the trunk. I also assembled two
simple test packages:
http://openejb.979440.n4.nabble.com/file/n4657131/war_test.war war_test.war
contains a single bean annotated with @Named, and an index.xhtml using this
bean; if the CDI scan was successful, the message "OK, CDI scan was
successful" appears at /war_test.
http://openejb.979440.n4.nabble.com/file/n4657131/ear_test.ear ear_test.ear
just wraps this this WAR in an app module (web context /ear_test)
Now, the war_test works in TomEE 1.1.0, but the ear_test fails.
I did some debugging, and the most obvious difference to me is at the end of
CDIScanner.init():
// here for ears we need to skip classes in the parent
classloader
final ClassLoader scl = ClassLoader.getSystemClassLoader();
final boolean filterByClassLoader =
"true".equals(SystemInstance.get().getProperty(OPENEJB_CDI_FILTER_CLASSLOADER,
"true"));
for (String className : beans.managedClasses) {
if (ejbClasses.contains(className)) continue;
final Class clazz = load(className, classLoader);
if (clazz == null) { <== **TRUE FOR EAR_TEST**
continue;
}
final ClassLoader cl = clazz.getClassLoader();
// 1. this classloader is the good one
// 2. the classloader is the appclassloader one and we are
in the ear parent
if (!filterByClassLoader
|| comparator.isSame(cl) || (cl.equals(scl) &&
startupObject.getWebContext() == null)) {
classes.add(clazz);
}
}
In both cases, the bean is listed in beans.managedClasses. But for the EAR,
the bean cannot be loaded by the provided ClassLoader, and hence is never
added to classes.
-- Johannes
--
View this message in context: http://openejb.979440.n4.nabble.com/Deployment-of-CDI-beans-does-not-work-for-WARs-wrapped-in-an-EAR-tp4657110p4657131.html
Sent from the OpenEJB Dev mailing list archive at Nabble.com.
Re: Deployment of CDI beans does not work for WARs wrapped in an EAR
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
some work was done (https://issues.apache.org/jira/browse/TOMEE-189)
not sure it was before/after the rev you mentionned (can't check now),
the cdibuilder is called another time for war in ear in tomcatwebappbuilder
and the beanmanager is a hierarchic one in the war normally.
can you valid against a fresh snapshot please if the rev1377287 is not?
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*