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 <[email protected]>: > 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 <[email protected]> > 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" <[email protected]> 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); >> > } >> > } >> > >>
