Is it in hammock? Did you force the webapp container to use the appclassloader in case of a secontainer?
Le 7 mars 2018 03:27, "John D. Ament" <johndam...@apache.org> a écrit : > That pretty much sums up the issue. > > When the app starts, the current thread is main. > When the webapp launches, it doesn't seem to load it properly. The good > news is if I override to the main class's thread, it still doesn't work. > So there's some inherent flaws. This was by overriding SingletonService to > use the same OWB container. > > I was able to replicate the issue using pain container start up using an > older pattern as well > > lifecycle = > WebBeansContext.currentInstance().getService(ContainerLifecycle.class); > lifecycle.startApplication(null); > > I'm going to test to see if I see this fixed on 1.x and broken on 2.x. > > John > > On Mon, Mar 5, 2018 at 8:04 AM Mark Struberg <strub...@yahoo.de.invalid> > wrote: > > > Hmm, that should not be necessary at all. > > > > The containers should resolve to the same BeanManager, UNLESS you have a > > different ClassLoader! > > But in that case almost everything will be broken anyways. > > > > LieGrue, > > strub > > > > > Am 05.03.2018 um 12:31 schrieb John D. Ament <johndam...@apache.org>: > > > > > > Yes, so that's basically what I'm seeing at issue. The TCCL's are > > different, different hierarchies, and as a result it cannot find the > > BeanManagerImpl. > > > > > > So here's the tricky part. I want to go from the SeContainer to the > > WebBeansContext. Do I just use WebBeansContext.getCurrentInstance() and > > then override the SingletonService? > > > > > > On 2018/03/05 07:40:05, Mark Struberg <strub...@yahoo.de.INVALID> > wrote: > > >> +1 > > >> > > >> The 'core' object in OWB is the WebBeansContext. This contains the 1 > > BeanManager for the 'application'. > > >> > > >> The lookup is done through the Finder. By default it's basically a > > Map<ClassLoader, WebBeansContext>. > > >> But you can change this to a custom one. > > >> > > >> Btw CDI.current() will always give you an InjectableBeanManager which > > is basically a thin wrapper which is Serializable. > > >> > > >> LieGrue, > > >> strub > > >> > > >> > > >> > > >>> Am 05.03.2018 um 06:44 schrieb Romain Manni-Bucau < > > rmannibu...@gmail.com>: > > >>> > > >>> Hi John > > >>> > > >>> The lookup is done depending your finder impl. By default it is by > > >>> classloader which means, if you dont end up using the same > > beanmanagerimpl, > > >>> you dont have the right tccl in different places - which has impacts > as > > >>> well. > > >>> > > >>> The wrapper instance is not that important here, only the delegate > one > > >>> > > >>> > > >>> Le 5 mars 2018 02:19, "John D. Ament" <johndam...@apache.org> a > > écrit : > > >>> > > >>>> Hi > > >>>> > > >>>> So I'm noticing when CDI.current().getBeanManager() is called, it > > returns a > > >>>> new InjectableBeanManager instance. I have a custom OWBListener ( > > >>>> https://github.com/hammock-project/hammock/blob/master/ > > >>>> bootstrap-owb2/src/main/java/ws/ament/hammock/bootstrap/ > > >>>> owb/OWBListener.java) > > >>>> which handles the lifecycle references in the servlet container. I > > don't > > >>>> want to start the application, because its already been started by > > the SE > > >>>> container so my custom version doesn't do that. > > >>>> > > >>>> However, I've noticed that the underlying BeanManager is not the > same > > as > > >>>> the one used by the SE initialization. Is this on purpose? Is > there > > >>>> something special that has to be done so that the underlying > > >>>> BeanManagerImpl on WebBeansContext.getInstance(). > getBeanManagerImpl() > > >>>> returns the one created via SE? > > >>>> > > >>>> John > > > > >
