You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by "John D. Ament" <jo...@gmail.com> on 2014/09/08 06:27:31 UTC
Gap with BeanManagerProvider
Hi all
I noticed that there's a potential gap with BeanManagerProvider. I was
able to generate the following output when running a ShrinkWrap test with
the BeanManagerProvider:
Retrieved bmi null with classloader
org.jboss.shrinkwrap.api.classloader.ShrinkWrapClassLoader@2ab4bc72
Putting a new bmi
org.apache.deltaspike.core.api.provider.BeanManagerProvider$BeanManagerInfo@3d829787
Sep 08, 2014 12:19:22 AM
org.apache.deltaspike.core.impl.config.EnvironmentPropertyConfigSourceProvider
<init>
INFO: Custom config found by DeltaSpike. Name: 'se-example.properties',
URL:
'file:/Users/johnament/src/restful-and-beyond-tut2184/code/target/test-classes/se-example.properties'
{org.jboss.shrinkwrap.api.classloader.ShrinkWrapClassLoader@2ab4bc72
=org.apache.deltaspike.core.api.provider.BeanManagerProvider$BeanManagerInfo@3d829787
}
Retrieved bmi null with classloader
sun.misc.Launcher$AppClassLoader@6e0be858
Putting a new bmi
org.apache.deltaspike.core.api.provider.BeanManagerProvider$BeanManagerInfo@7278640c
Getting parent classloader based bean manager
Retrieved bmi null with classloader sun.misc.Launcher$ExtClassLoader@9f7fc43
Putting a new bmi
Sep 08, 2014 12:19:23 AM
org.apache.deltaspike.core.api.provider.BeanManagerProvider getBeanManager
This line here is especially weird, it's happening as the first line of my
test, yet it looks like afterwards I'm getting more BeanManagerInfo's
loaded.
I was able to work around this issue by adding the following check when
loading the bean manager:
synchronized (this)
{
bmi = bmpSingleton.bmInfos.get(cl);
if (bmi == null && bmpSingleton.bmInfos.isEmpty())
{
bmi = new BeanManagerInfo();
bmpSingleton.bmInfos.put(cl, bmi);
}
else
{
ClassLoader classLoader =
bmpSingleton.bmInfos.keySet().iterator().next();
bmi = bmpSingleton.bmInfos.get(classLoader);
}
}
Re: Gap with BeanManagerProvider
Posted by Romain Manni-Bucau <rm...@gmail.com>.
issue is parent classloaders can get a different BM (ears for instance
but OSGi where classloading is "weird")
something like http://svn.apache.org/repos/asf/tomee/tomee/trunk/arquillian/arquillian-common/src/main/java/org/apache/openejb/arquillian/common/TestObserver.java
solves it - it uses openejb internals but hopefully the idea is more
explicit
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-09-08 13:09 GMT+02:00 John D. Ament <jo...@gmail.com>:
> Hmm so it seems like when I look at the underlying classloader structure,
> shrinkwrap is the lowest, then app cl, then ext cl. Inside the test,
> there's never a case where it's invoked via shrinkwrap. I'm wondering if
> it makes sense to also bind parent classloaders in the hashmap. They
> should end up overwritten if a new one is created.
>
> It does look like we have an ear test, so I can verify if this introduces
> any issues or not.
>
> On Mon, Sep 8, 2014 at 12:52 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> Hi
>>
>> It means you'll not get the right bm sometimes (multithreaded arquillian
>> tests for instance I think).
>>
>> BMP relies on classloader so if test is not executed in archive loader
>> (shrinkwrapclassloader) then DS - but not only - is broken.
>>
>> I'd fix the arquillian adapter here.
>> Le 8 sept. 2014 05:27, "John D. Ament" <jo...@gmail.com> a écrit :
>>
>> > Hi all
>> >
>> > I noticed that there's a potential gap with BeanManagerProvider. I was
>> > able to generate the following output when running a ShrinkWrap test with
>> > the BeanManagerProvider:
>> >
>> > Retrieved bmi null with classloader
>> > org.jboss.shrinkwrap.api.classloader.ShrinkWrapClassLoader@2ab4bc72
>> >
>> > Putting a new bmi
>> >
>> >
>> >
>> org.apache.deltaspike.core.api.provider.BeanManagerProvider$BeanManagerInfo@3d829787
>> >
>> > Sep 08, 2014 12:19:22 AM
>> >
>> >
>> org.apache.deltaspike.core.impl.config.EnvironmentPropertyConfigSourceProvider
>> > <init>
>> >
>> > INFO: Custom config found by DeltaSpike. Name: 'se-example.properties',
>> > URL:
>> >
>> >
>> 'file:/Users/johnament/src/restful-and-beyond-tut2184/code/target/test-classes/se-example.properties'
>> >
>> > {org.jboss.shrinkwrap.api.classloader.ShrinkWrapClassLoader@2ab4bc72
>> >
>> >
>> =org.apache.deltaspike.core.api.provider.BeanManagerProvider$BeanManagerInfo@3d829787
>> > }
>> >
>> > Retrieved bmi null with classloader
>> > sun.misc.Launcher$AppClassLoader@6e0be858
>> >
>> > Putting a new bmi
>> >
>> >
>> >
>> org.apache.deltaspike.core.api.provider.BeanManagerProvider$BeanManagerInfo@7278640c
>> >
>> > Getting parent classloader based bean manager
>> >
>> > Retrieved bmi null with classloader
>> > sun.misc.Launcher$ExtClassLoader@9f7fc43
>> >
>> > Putting a new bmi
>> >
>> > Sep 08, 2014 12:19:23 AM
>> > org.apache.deltaspike.core.api.provider.BeanManagerProvider
>> getBeanManager
>> >
>> >
>> > This line here is especially weird, it's happening as the first line of
>> my
>> > test, yet it looks like afterwards I'm getting more BeanManagerInfo's
>> > loaded.
>> >
>> >
>> > I was able to work around this issue by adding the following check when
>> > loading the bean manager:
>> >
>> >
>> > synchronized (this)
>> > {
>> > bmi = bmpSingleton.bmInfos.get(cl);
>> > if (bmi == null && bmpSingleton.bmInfos.isEmpty())
>> > {
>> > bmi = new BeanManagerInfo();
>> > bmpSingleton.bmInfos.put(cl, bmi);
>> > }
>> > else
>> > {
>> > ClassLoader classLoader =
>> > bmpSingleton.bmInfos.keySet().iterator().next();
>> > bmi = bmpSingleton.bmInfos.get(classLoader);
>> > }
>> > }
>> >
>>
Re: Gap with BeanManagerProvider
Posted by "John D. Ament" <jo...@gmail.com>.
Hmm so it seems like when I look at the underlying classloader structure,
shrinkwrap is the lowest, then app cl, then ext cl. Inside the test,
there's never a case where it's invoked via shrinkwrap. I'm wondering if
it makes sense to also bind parent classloaders in the hashmap. They
should end up overwritten if a new one is created.
It does look like we have an ear test, so I can verify if this introduces
any issues or not.
On Mon, Sep 8, 2014 at 12:52 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hi
>
> It means you'll not get the right bm sometimes (multithreaded arquillian
> tests for instance I think).
>
> BMP relies on classloader so if test is not executed in archive loader
> (shrinkwrapclassloader) then DS - but not only - is broken.
>
> I'd fix the arquillian adapter here.
> Le 8 sept. 2014 05:27, "John D. Ament" <jo...@gmail.com> a écrit :
>
> > Hi all
> >
> > I noticed that there's a potential gap with BeanManagerProvider. I was
> > able to generate the following output when running a ShrinkWrap test with
> > the BeanManagerProvider:
> >
> > Retrieved bmi null with classloader
> > org.jboss.shrinkwrap.api.classloader.ShrinkWrapClassLoader@2ab4bc72
> >
> > Putting a new bmi
> >
> >
> >
> org.apache.deltaspike.core.api.provider.BeanManagerProvider$BeanManagerInfo@3d829787
> >
> > Sep 08, 2014 12:19:22 AM
> >
> >
> org.apache.deltaspike.core.impl.config.EnvironmentPropertyConfigSourceProvider
> > <init>
> >
> > INFO: Custom config found by DeltaSpike. Name: 'se-example.properties',
> > URL:
> >
> >
> 'file:/Users/johnament/src/restful-and-beyond-tut2184/code/target/test-classes/se-example.properties'
> >
> > {org.jboss.shrinkwrap.api.classloader.ShrinkWrapClassLoader@2ab4bc72
> >
> >
> =org.apache.deltaspike.core.api.provider.BeanManagerProvider$BeanManagerInfo@3d829787
> > }
> >
> > Retrieved bmi null with classloader
> > sun.misc.Launcher$AppClassLoader@6e0be858
> >
> > Putting a new bmi
> >
> >
> >
> org.apache.deltaspike.core.api.provider.BeanManagerProvider$BeanManagerInfo@7278640c
> >
> > Getting parent classloader based bean manager
> >
> > Retrieved bmi null with classloader
> > sun.misc.Launcher$ExtClassLoader@9f7fc43
> >
> > Putting a new bmi
> >
> > Sep 08, 2014 12:19:23 AM
> > org.apache.deltaspike.core.api.provider.BeanManagerProvider
> getBeanManager
> >
> >
> > This line here is especially weird, it's happening as the first line of
> my
> > test, yet it looks like afterwards I'm getting more BeanManagerInfo's
> > loaded.
> >
> >
> > I was able to work around this issue by adding the following check when
> > loading the bean manager:
> >
> >
> > synchronized (this)
> > {
> > bmi = bmpSingleton.bmInfos.get(cl);
> > if (bmi == null && bmpSingleton.bmInfos.isEmpty())
> > {
> > bmi = new BeanManagerInfo();
> > bmpSingleton.bmInfos.put(cl, bmi);
> > }
> > else
> > {
> > ClassLoader classLoader =
> > bmpSingleton.bmInfos.keySet().iterator().next();
> > bmi = bmpSingleton.bmInfos.get(classLoader);
> > }
> > }
> >
>
Re: Gap with BeanManagerProvider
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
It means you'll not get the right bm sometimes (multithreaded arquillian
tests for instance I think).
BMP relies on classloader so if test is not executed in archive loader
(shrinkwrapclassloader) then DS - but not only - is broken.
I'd fix the arquillian adapter here.
Le 8 sept. 2014 05:27, "John D. Ament" <jo...@gmail.com> a écrit :
> Hi all
>
> I noticed that there's a potential gap with BeanManagerProvider. I was
> able to generate the following output when running a ShrinkWrap test with
> the BeanManagerProvider:
>
> Retrieved bmi null with classloader
> org.jboss.shrinkwrap.api.classloader.ShrinkWrapClassLoader@2ab4bc72
>
> Putting a new bmi
>
>
> org.apache.deltaspike.core.api.provider.BeanManagerProvider$BeanManagerInfo@3d829787
>
> Sep 08, 2014 12:19:22 AM
>
> org.apache.deltaspike.core.impl.config.EnvironmentPropertyConfigSourceProvider
> <init>
>
> INFO: Custom config found by DeltaSpike. Name: 'se-example.properties',
> URL:
>
> 'file:/Users/johnament/src/restful-and-beyond-tut2184/code/target/test-classes/se-example.properties'
>
> {org.jboss.shrinkwrap.api.classloader.ShrinkWrapClassLoader@2ab4bc72
>
> =org.apache.deltaspike.core.api.provider.BeanManagerProvider$BeanManagerInfo@3d829787
> }
>
> Retrieved bmi null with classloader
> sun.misc.Launcher$AppClassLoader@6e0be858
>
> Putting a new bmi
>
>
> org.apache.deltaspike.core.api.provider.BeanManagerProvider$BeanManagerInfo@7278640c
>
> Getting parent classloader based bean manager
>
> Retrieved bmi null with classloader
> sun.misc.Launcher$ExtClassLoader@9f7fc43
>
> Putting a new bmi
>
> Sep 08, 2014 12:19:23 AM
> org.apache.deltaspike.core.api.provider.BeanManagerProvider getBeanManager
>
>
> This line here is especially weird, it's happening as the first line of my
> test, yet it looks like afterwards I'm getting more BeanManagerInfo's
> loaded.
>
>
> I was able to work around this issue by adding the following check when
> loading the bean manager:
>
>
> synchronized (this)
> {
> bmi = bmpSingleton.bmInfos.get(cl);
> if (bmi == null && bmpSingleton.bmInfos.isEmpty())
> {
> bmi = new BeanManagerInfo();
> bmpSingleton.bmInfos.put(cl, bmi);
> }
> else
> {
> ClassLoader classLoader =
> bmpSingleton.bmInfos.keySet().iterator().next();
> bmi = bmpSingleton.bmInfos.get(classLoader);
> }
> }
>