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); > > } > > } > > >
