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
