You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by "John D. Ament" <jo...@apache.org> on 2018/03/05 01:19:27 UTC
Consistent results for CDI.current().getBeanManager()
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
Re: Consistent results for CDI.current().getBeanManager()
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 11 avr. 2018 01:55, "John D. Ament" <jo...@apache.org> a écrit :
This is what I was able to get working.
https://github.com/hammock-project/hammock/commit/
8f50242634b370b12c1f291a1f3fc83e3d7533c2
However, I'll be honest and say it seems like a big gap that OWB isn't
dealing with this. I haven't done thorough testing, but if I'm using SE
and an executor service, I could likely hit a similar issue right?
For the "gap" just keep in mind it is easy to report bugs against your
setup due to your classloader mix. Your are in the state of tomee embedded
a few years ago and we got several issues cause of that and needed to fix
it forcing a consistent classloader accross the whole chain so tempted to
say the gap is probably not on owb for this one.
Not sure what you mean with the executor service but you will get one per
context if not using the default yes.
On Mon, Apr 9, 2018 at 11:10 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Yes but this will not work for you John since you will end up with 3
> classloaders instead of 1 still and no singleton service unifying it.
>
> What can work if you use the default singleton is to register the
> existing context for other classloaders:
>
> DefaultSingletonService.class.cast(singletonInstance).register(loader,
> context);
>
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
>
>
> 2018-04-09 16:37 GMT+02:00 John D. Ament <jo...@apache.org>:
> > Did you mean ClassLoaderLock in meecrowave? Or something like the Rule
> > defined by MonoMeecrowave?
> >
> > John
> >
> > On Mon, Apr 9, 2018 at 8:27 AM Mark Struberg <st...@yahoo.de.invalid>
> > wrote:
> >
> >> John, another proposal. I've implemented the same for the Meecrowave
> JUnit
> >> integration.
> >> Could you create a 'client' UrlClassLoader with no own URLs?
> >> And then per your 'slice' switch the TCCL accordingly?
> >>
> >> That way you will get perfect isolation.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> > Am 09.04.2018 um 14:10 schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com
> >> >:
> >> >
> >> > 2018-04-09 14:07 GMT+02:00 John D. Ament <jo...@apache.org>:
> >> >
> >> >> On Mon, Apr 9, 2018 at 7:55 AM Romain Manni-Bucau <
> >> rmannibucau@gmail.com>
> >> >> wrote:
> >> >>
> >> >>> 2018-04-09 13:34 GMT+02:00 John D. Ament <jo...@apache.org>:
> >> >>>
> >> >>>> Yeah, I hit that. I was able to get around the listener issue,
but
> >> >> then
> >> >>>> this still occurred (its actually within OwbCDI where it fails
> next).
> >> >>>>
> >> >>>> Basically, TCCLs don't make sense in SE, and its pretty key to how
> OWB
> >> >>>> works.
> >> >>>>
> >> >>>
> >> >>> Hmm why? it is as important than in other cases.
> >> >>>
> >> >>>
> >> >>>>
> >> >>>> Is there a way that CDI.current() could resolve to the
OWBContainer
> >> >> that
> >> >>>> was used to bootstrap? Since SeContainer implements Instance,
> most of
> >> >>> the
> >> >>>> work would be there already for the CDI object.
> >> >>>>
> >> >>>> Or should OWB somehow override the finder in OWBInitializer
> >> (initialize
> >> >>> or
> >> >>>> newContainer methods I had in mind).
> >> >>>>
> >> >>>
> >> >>> Think you really want to impl a finder for your particular case.
> Sounds
> >> >>> like you want a singleton and not a webapp instance but still
> >> deploying a
> >> >>> webapp, no?
> >> >>>
> >> >>>
> >> >> I was thinking its blocked by the spec, but you have
> >> >> your SeContainerSelector so I can replace with my own impl. Not
> ideal,
> >> >> since SE really should just mean single container but I suppose it
> will
> >> >> work.
> >> >>
> >> >
> >> > Not sure, in meecrowave or tomee (to come) we support it for N
> contexts
> >> > potentially.
> >> > Spec allows to manipulate one context but still deploy N (N>1) which
> is
> >> > important for packaged apps (=including N elementary apps).
> >> >
> >> > If you don't respect the TCCL then you are probably broken with most
> >> > mainstream libs - it is sadly common to use the classloader as a key
> of a
> >> > cache - so maybe the first step is to fix that?
> >> > Forcing tomcat or jetty to reuse the launching classloader is quite
> easy
> >> so
> >> > maybe the way to go for your case?
> >> >
> >> >
> >> >>
> >> >>
> >> >>>
> >> >>>>
> >> >>>> John
> >> >>>>
> >> >>>> On Mon, Apr 9, 2018 at 3:21 AM Mark Struberg
> >> <struberg@yahoo.de.invalid
> >> >>>
> >> >>>> wrote:
> >> >>>>
> >> >>>>> This is kind of a circular issue.
> >> >>>>>
> >> >>>>> Look at WebBeansContext#getInstance()
> >> >>>>>
> >> >>>>> public static WebBeansContext getInstance()
> >> >>>>> {
> >> >>>>> WebBeansContext webBeansContext =
> >> >>>>> WebBeansFinder.getSingletonInstance();
> >> >>>>>
> >> >>>>>
> >> >>>>> And WebBeansFinder.getSingletonInstance() in turn again uses the
> >> >> TCCL
> >> >>> to
> >> >>>>> look up the WebBeansContext.
> >> >>>>>
> >> >>>>> So even if you create a WebBeansContext with an explicit
> >> >> FinderService,
> >> >>>> it
> >> >>>>> would not make much difference I fear.
> >> >>>>>
> >> >>>>> LieGrue,
> >> >>>>> strub
> >> >>>>>
> >> >>>>>
> >> >>>>>> Am 09.04.2018 um 08:25 schrieb Romain Manni-Bucau <
> >> >>>> rmannibucau@gmail.com
> >> >>>>>> :
> >> >>>>>>
> >> >>>>>> Le 9 avr. 2018 02:33, "John D. Ament" <jo...@apache.org> a
> >> >>> écrit
> >> >>>> :
> >> >>>>>>
> >> >>>>>> On Wed, Mar 7, 2018 at 1:33 AM Romain Manni-Bucau <
> >> >>>> rmannibucau@gmail.com
> >> >>>>>>
> >> >>>>>> wrote:
> >> >>>>>>
> >> >>>>>>> Is it in hammock? Did you force the webapp container to use the
> >> >>>>>>> appclassloader in case of a secontainer?
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>> How would I do that? You mean inside of Tomcat? I'd much
rather
> >> >> put
> >> >>>>>> together a solution that works independent of a container, and
in
> >> >> SE
> >> >>>>> since
> >> >>>>>> I really want there to be a single context for the JVM.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> Yes. It is actually the cleanest if you dont support multi apps
> >> >>>>> deployment
> >> >>>>>> cause this way you unify all libs look ups (ds, beanutils, mp
> >> >> config,
> >> >>>>> ....)
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> I've narrowed the issue down to the classloader used once the
> >> >> servlet
> >> >>>>>> listener starts up. It is in fact using the webapp classloader
> at
> >> >>> that
> >> >>>>>> point.
> >> >>>>>>
> >> >>>>>> I was thinking a cleaner solution would be to create an
> additional
> >> >>>>>> constructor in WebBeansConfigurationListener that took the
proper
> >> >>>>>> WebBeansContext to look up, instead of relying on the singleton
> >> >>> service
> >> >>>>> to
> >> >>>>>> look one up.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> It is the same, you just have to set the singleton service
> matching
> >> >>>> your
> >> >>>>>> environment.
> >> >>>>>>
> >> >>>>>> You can also delay the cdi startup to be done in the web context
> >> >> with
> >> >>>> the
> >> >>>>>> right tccl.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>>
> >> >>>>>>> Le 7 mars 2018 03:27, "John D. Ament" <jo...@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
> >> >>>> <struberg@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 <
> >> >>>> johndament@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
> >> >> <struberg@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 <
> >> >>>>>>>>> rmannibucau@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" <
> johndament@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
> >>
> >>
>
Re: Consistent results for CDI.current().getBeanManager()
Posted by "John D. Ament" <jo...@apache.org>.
This is what I was able to get working.
https://github.com/hammock-project/hammock/commit/8f50242634b370b12c1f291a1f3fc83e3d7533c2
However, I'll be honest and say it seems like a big gap that OWB isn't
dealing with this. I haven't done thorough testing, but if I'm using SE
and an executor service, I could likely hit a similar issue right?
On Mon, Apr 9, 2018 at 11:10 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Yes but this will not work for you John since you will end up with 3
> classloaders instead of 1 still and no singleton service unifying it.
>
> What can work if you use the default singleton is to register the
> existing context for other classloaders:
>
> DefaultSingletonService.class.cast(singletonInstance).register(loader,
> context);
>
>
> Romain Manni-Bucau
> @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
>
>
> 2018-04-09 16:37 GMT+02:00 John D. Ament <jo...@apache.org>:
> > Did you mean ClassLoaderLock in meecrowave? Or something like the Rule
> > defined by MonoMeecrowave?
> >
> > John
> >
> > On Mon, Apr 9, 2018 at 8:27 AM Mark Struberg <st...@yahoo.de.invalid>
> > wrote:
> >
> >> John, another proposal. I've implemented the same for the Meecrowave
> JUnit
> >> integration.
> >> Could you create a 'client' UrlClassLoader with no own URLs?
> >> And then per your 'slice' switch the TCCL accordingly?
> >>
> >> That way you will get perfect isolation.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> > Am 09.04.2018 um 14:10 schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com
> >> >:
> >> >
> >> > 2018-04-09 14:07 GMT+02:00 John D. Ament <jo...@apache.org>:
> >> >
> >> >> On Mon, Apr 9, 2018 at 7:55 AM Romain Manni-Bucau <
> >> rmannibucau@gmail.com>
> >> >> wrote:
> >> >>
> >> >>> 2018-04-09 13:34 GMT+02:00 John D. Ament <jo...@apache.org>:
> >> >>>
> >> >>>> Yeah, I hit that. I was able to get around the listener issue, but
> >> >> then
> >> >>>> this still occurred (its actually within OwbCDI where it fails
> next).
> >> >>>>
> >> >>>> Basically, TCCLs don't make sense in SE, and its pretty key to how
> OWB
> >> >>>> works.
> >> >>>>
> >> >>>
> >> >>> Hmm why? it is as important than in other cases.
> >> >>>
> >> >>>
> >> >>>>
> >> >>>> Is there a way that CDI.current() could resolve to the OWBContainer
> >> >> that
> >> >>>> was used to bootstrap? Since SeContainer implements Instance,
> most of
> >> >>> the
> >> >>>> work would be there already for the CDI object.
> >> >>>>
> >> >>>> Or should OWB somehow override the finder in OWBInitializer
> >> (initialize
> >> >>> or
> >> >>>> newContainer methods I had in mind).
> >> >>>>
> >> >>>
> >> >>> Think you really want to impl a finder for your particular case.
> Sounds
> >> >>> like you want a singleton and not a webapp instance but still
> >> deploying a
> >> >>> webapp, no?
> >> >>>
> >> >>>
> >> >> I was thinking its blocked by the spec, but you have
> >> >> your SeContainerSelector so I can replace with my own impl. Not
> ideal,
> >> >> since SE really should just mean single container but I suppose it
> will
> >> >> work.
> >> >>
> >> >
> >> > Not sure, in meecrowave or tomee (to come) we support it for N
> contexts
> >> > potentially.
> >> > Spec allows to manipulate one context but still deploy N (N>1) which
> is
> >> > important for packaged apps (=including N elementary apps).
> >> >
> >> > If you don't respect the TCCL then you are probably broken with most
> >> > mainstream libs - it is sadly common to use the classloader as a key
> of a
> >> > cache - so maybe the first step is to fix that?
> >> > Forcing tomcat or jetty to reuse the launching classloader is quite
> easy
> >> so
> >> > maybe the way to go for your case?
> >> >
> >> >
> >> >>
> >> >>
> >> >>>
> >> >>>>
> >> >>>> John
> >> >>>>
> >> >>>> On Mon, Apr 9, 2018 at 3:21 AM Mark Struberg
> >> <struberg@yahoo.de.invalid
> >> >>>
> >> >>>> wrote:
> >> >>>>
> >> >>>>> This is kind of a circular issue.
> >> >>>>>
> >> >>>>> Look at WebBeansContext#getInstance()
> >> >>>>>
> >> >>>>> public static WebBeansContext getInstance()
> >> >>>>> {
> >> >>>>> WebBeansContext webBeansContext =
> >> >>>>> WebBeansFinder.getSingletonInstance();
> >> >>>>>
> >> >>>>>
> >> >>>>> And WebBeansFinder.getSingletonInstance() in turn again uses the
> >> >> TCCL
> >> >>> to
> >> >>>>> look up the WebBeansContext.
> >> >>>>>
> >> >>>>> So even if you create a WebBeansContext with an explicit
> >> >> FinderService,
> >> >>>> it
> >> >>>>> would not make much difference I fear.
> >> >>>>>
> >> >>>>> LieGrue,
> >> >>>>> strub
> >> >>>>>
> >> >>>>>
> >> >>>>>> Am 09.04.2018 um 08:25 schrieb Romain Manni-Bucau <
> >> >>>> rmannibucau@gmail.com
> >> >>>>>> :
> >> >>>>>>
> >> >>>>>> Le 9 avr. 2018 02:33, "John D. Ament" <jo...@apache.org> a
> >> >>> écrit
> >> >>>> :
> >> >>>>>>
> >> >>>>>> On Wed, Mar 7, 2018 at 1:33 AM Romain Manni-Bucau <
> >> >>>> rmannibucau@gmail.com
> >> >>>>>>
> >> >>>>>> wrote:
> >> >>>>>>
> >> >>>>>>> Is it in hammock? Did you force the webapp container to use the
> >> >>>>>>> appclassloader in case of a secontainer?
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>> How would I do that? You mean inside of Tomcat? I'd much rather
> >> >> put
> >> >>>>>> together a solution that works independent of a container, and in
> >> >> SE
> >> >>>>> since
> >> >>>>>> I really want there to be a single context for the JVM.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> Yes. It is actually the cleanest if you dont support multi apps
> >> >>>>> deployment
> >> >>>>>> cause this way you unify all libs look ups (ds, beanutils, mp
> >> >> config,
> >> >>>>> ....)
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> I've narrowed the issue down to the classloader used once the
> >> >> servlet
> >> >>>>>> listener starts up. It is in fact using the webapp classloader
> at
> >> >>> that
> >> >>>>>> point.
> >> >>>>>>
> >> >>>>>> I was thinking a cleaner solution would be to create an
> additional
> >> >>>>>> constructor in WebBeansConfigurationListener that took the proper
> >> >>>>>> WebBeansContext to look up, instead of relying on the singleton
> >> >>> service
> >> >>>>> to
> >> >>>>>> look one up.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> It is the same, you just have to set the singleton service
> matching
> >> >>>> your
> >> >>>>>> environment.
> >> >>>>>>
> >> >>>>>> You can also delay the cdi startup to be done in the web context
> >> >> with
> >> >>>> the
> >> >>>>>> right tccl.
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>>
> >> >>>>>>> Le 7 mars 2018 03:27, "John D. Ament" <jo...@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
> >> >>>> <struberg@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 <
> >> >>>> johndament@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
> >> >> <struberg@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 <
> >> >>>>>>>>> rmannibucau@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" <
> johndament@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
> >>
> >>
>
Re: Consistent results for CDI.current().getBeanManager()
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Yes but this will not work for you John since you will end up with 3
classloaders instead of 1 still and no singleton service unifying it.
What can work if you use the default singleton is to register the
existing context for other classloaders:
DefaultSingletonService.class.cast(singletonInstance).register(loader, context);
Romain Manni-Bucau
@rmannibucau | Blog | Old Blog | Github | LinkedIn | Book
2018-04-09 16:37 GMT+02:00 John D. Ament <jo...@apache.org>:
> Did you mean ClassLoaderLock in meecrowave? Or something like the Rule
> defined by MonoMeecrowave?
>
> John
>
> On Mon, Apr 9, 2018 at 8:27 AM Mark Struberg <st...@yahoo.de.invalid>
> wrote:
>
>> John, another proposal. I've implemented the same for the Meecrowave JUnit
>> integration.
>> Could you create a 'client' UrlClassLoader with no own URLs?
>> And then per your 'slice' switch the TCCL accordingly?
>>
>> That way you will get perfect isolation.
>>
>> LieGrue,
>> strub
>>
>>
>> > Am 09.04.2018 um 14:10 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
>> >:
>> >
>> > 2018-04-09 14:07 GMT+02:00 John D. Ament <jo...@apache.org>:
>> >
>> >> On Mon, Apr 9, 2018 at 7:55 AM Romain Manni-Bucau <
>> rmannibucau@gmail.com>
>> >> wrote:
>> >>
>> >>> 2018-04-09 13:34 GMT+02:00 John D. Ament <jo...@apache.org>:
>> >>>
>> >>>> Yeah, I hit that. I was able to get around the listener issue, but
>> >> then
>> >>>> this still occurred (its actually within OwbCDI where it fails next).
>> >>>>
>> >>>> Basically, TCCLs don't make sense in SE, and its pretty key to how OWB
>> >>>> works.
>> >>>>
>> >>>
>> >>> Hmm why? it is as important than in other cases.
>> >>>
>> >>>
>> >>>>
>> >>>> Is there a way that CDI.current() could resolve to the OWBContainer
>> >> that
>> >>>> was used to bootstrap? Since SeContainer implements Instance, most of
>> >>> the
>> >>>> work would be there already for the CDI object.
>> >>>>
>> >>>> Or should OWB somehow override the finder in OWBInitializer
>> (initialize
>> >>> or
>> >>>> newContainer methods I had in mind).
>> >>>>
>> >>>
>> >>> Think you really want to impl a finder for your particular case. Sounds
>> >>> like you want a singleton and not a webapp instance but still
>> deploying a
>> >>> webapp, no?
>> >>>
>> >>>
>> >> I was thinking its blocked by the spec, but you have
>> >> your SeContainerSelector so I can replace with my own impl. Not ideal,
>> >> since SE really should just mean single container but I suppose it will
>> >> work.
>> >>
>> >
>> > Not sure, in meecrowave or tomee (to come) we support it for N contexts
>> > potentially.
>> > Spec allows to manipulate one context but still deploy N (N>1) which is
>> > important for packaged apps (=including N elementary apps).
>> >
>> > If you don't respect the TCCL then you are probably broken with most
>> > mainstream libs - it is sadly common to use the classloader as a key of a
>> > cache - so maybe the first step is to fix that?
>> > Forcing tomcat or jetty to reuse the launching classloader is quite easy
>> so
>> > maybe the way to go for your case?
>> >
>> >
>> >>
>> >>
>> >>>
>> >>>>
>> >>>> John
>> >>>>
>> >>>> On Mon, Apr 9, 2018 at 3:21 AM Mark Struberg
>> <struberg@yahoo.de.invalid
>> >>>
>> >>>> wrote:
>> >>>>
>> >>>>> This is kind of a circular issue.
>> >>>>>
>> >>>>> Look at WebBeansContext#getInstance()
>> >>>>>
>> >>>>> public static WebBeansContext getInstance()
>> >>>>> {
>> >>>>> WebBeansContext webBeansContext =
>> >>>>> WebBeansFinder.getSingletonInstance();
>> >>>>>
>> >>>>>
>> >>>>> And WebBeansFinder.getSingletonInstance() in turn again uses the
>> >> TCCL
>> >>> to
>> >>>>> look up the WebBeansContext.
>> >>>>>
>> >>>>> So even if you create a WebBeansContext with an explicit
>> >> FinderService,
>> >>>> it
>> >>>>> would not make much difference I fear.
>> >>>>>
>> >>>>> LieGrue,
>> >>>>> strub
>> >>>>>
>> >>>>>
>> >>>>>> Am 09.04.2018 um 08:25 schrieb Romain Manni-Bucau <
>> >>>> rmannibucau@gmail.com
>> >>>>>> :
>> >>>>>>
>> >>>>>> Le 9 avr. 2018 02:33, "John D. Ament" <jo...@apache.org> a
>> >>> écrit
>> >>>> :
>> >>>>>>
>> >>>>>> On Wed, Mar 7, 2018 at 1:33 AM Romain Manni-Bucau <
>> >>>> rmannibucau@gmail.com
>> >>>>>>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>> Is it in hammock? Did you force the webapp container to use the
>> >>>>>>> appclassloader in case of a secontainer?
>> >>>>>>>
>> >>>>>>
>> >>>>>> How would I do that? You mean inside of Tomcat? I'd much rather
>> >> put
>> >>>>>> together a solution that works independent of a container, and in
>> >> SE
>> >>>>> since
>> >>>>>> I really want there to be a single context for the JVM.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> Yes. It is actually the cleanest if you dont support multi apps
>> >>>>> deployment
>> >>>>>> cause this way you unify all libs look ups (ds, beanutils, mp
>> >> config,
>> >>>>> ....)
>> >>>>>>
>> >>>>>>
>> >>>>>> I've narrowed the issue down to the classloader used once the
>> >> servlet
>> >>>>>> listener starts up. It is in fact using the webapp classloader at
>> >>> that
>> >>>>>> point.
>> >>>>>>
>> >>>>>> I was thinking a cleaner solution would be to create an additional
>> >>>>>> constructor in WebBeansConfigurationListener that took the proper
>> >>>>>> WebBeansContext to look up, instead of relying on the singleton
>> >>> service
>> >>>>> to
>> >>>>>> look one up.
>> >>>>>>
>> >>>>>>
>> >>>>>> It is the same, you just have to set the singleton service matching
>> >>>> your
>> >>>>>> environment.
>> >>>>>>
>> >>>>>> You can also delay the cdi startup to be done in the web context
>> >> with
>> >>>> the
>> >>>>>> right tccl.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>>
>> >>>>>>> Le 7 mars 2018 03:27, "John D. Ament" <jo...@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
>> >>>> <struberg@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 <
>> >>>> johndament@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
>> >> <struberg@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 <
>> >>>>>>>>> rmannibucau@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" <johndament@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
>>
>>
Re: Consistent results for CDI.current().getBeanManager()
Posted by "John D. Ament" <jo...@apache.org>.
Did you mean ClassLoaderLock in meecrowave? Or something like the Rule
defined by MonoMeecrowave?
John
On Mon, Apr 9, 2018 at 8:27 AM Mark Struberg <st...@yahoo.de.invalid>
wrote:
> John, another proposal. I've implemented the same for the Meecrowave JUnit
> integration.
> Could you create a 'client' UrlClassLoader with no own URLs?
> And then per your 'slice' switch the TCCL accordingly?
>
> That way you will get perfect isolation.
>
> LieGrue,
> strub
>
>
> > Am 09.04.2018 um 14:10 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > 2018-04-09 14:07 GMT+02:00 John D. Ament <jo...@apache.org>:
> >
> >> On Mon, Apr 9, 2018 at 7:55 AM Romain Manni-Bucau <
> rmannibucau@gmail.com>
> >> wrote:
> >>
> >>> 2018-04-09 13:34 GMT+02:00 John D. Ament <jo...@apache.org>:
> >>>
> >>>> Yeah, I hit that. I was able to get around the listener issue, but
> >> then
> >>>> this still occurred (its actually within OwbCDI where it fails next).
> >>>>
> >>>> Basically, TCCLs don't make sense in SE, and its pretty key to how OWB
> >>>> works.
> >>>>
> >>>
> >>> Hmm why? it is as important than in other cases.
> >>>
> >>>
> >>>>
> >>>> Is there a way that CDI.current() could resolve to the OWBContainer
> >> that
> >>>> was used to bootstrap? Since SeContainer implements Instance, most of
> >>> the
> >>>> work would be there already for the CDI object.
> >>>>
> >>>> Or should OWB somehow override the finder in OWBInitializer
> (initialize
> >>> or
> >>>> newContainer methods I had in mind).
> >>>>
> >>>
> >>> Think you really want to impl a finder for your particular case. Sounds
> >>> like you want a singleton and not a webapp instance but still
> deploying a
> >>> webapp, no?
> >>>
> >>>
> >> I was thinking its blocked by the spec, but you have
> >> your SeContainerSelector so I can replace with my own impl. Not ideal,
> >> since SE really should just mean single container but I suppose it will
> >> work.
> >>
> >
> > Not sure, in meecrowave or tomee (to come) we support it for N contexts
> > potentially.
> > Spec allows to manipulate one context but still deploy N (N>1) which is
> > important for packaged apps (=including N elementary apps).
> >
> > If you don't respect the TCCL then you are probably broken with most
> > mainstream libs - it is sadly common to use the classloader as a key of a
> > cache - so maybe the first step is to fix that?
> > Forcing tomcat or jetty to reuse the launching classloader is quite easy
> so
> > maybe the way to go for your case?
> >
> >
> >>
> >>
> >>>
> >>>>
> >>>> John
> >>>>
> >>>> On Mon, Apr 9, 2018 at 3:21 AM Mark Struberg
> <struberg@yahoo.de.invalid
> >>>
> >>>> wrote:
> >>>>
> >>>>> This is kind of a circular issue.
> >>>>>
> >>>>> Look at WebBeansContext#getInstance()
> >>>>>
> >>>>> public static WebBeansContext getInstance()
> >>>>> {
> >>>>> WebBeansContext webBeansContext =
> >>>>> WebBeansFinder.getSingletonInstance();
> >>>>>
> >>>>>
> >>>>> And WebBeansFinder.getSingletonInstance() in turn again uses the
> >> TCCL
> >>> to
> >>>>> look up the WebBeansContext.
> >>>>>
> >>>>> So even if you create a WebBeansContext with an explicit
> >> FinderService,
> >>>> it
> >>>>> would not make much difference I fear.
> >>>>>
> >>>>> LieGrue,
> >>>>> strub
> >>>>>
> >>>>>
> >>>>>> Am 09.04.2018 um 08:25 schrieb Romain Manni-Bucau <
> >>>> rmannibucau@gmail.com
> >>>>>> :
> >>>>>>
> >>>>>> Le 9 avr. 2018 02:33, "John D. Ament" <jo...@apache.org> a
> >>> écrit
> >>>> :
> >>>>>>
> >>>>>> On Wed, Mar 7, 2018 at 1:33 AM Romain Manni-Bucau <
> >>>> rmannibucau@gmail.com
> >>>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Is it in hammock? Did you force the webapp container to use the
> >>>>>>> appclassloader in case of a secontainer?
> >>>>>>>
> >>>>>>
> >>>>>> How would I do that? You mean inside of Tomcat? I'd much rather
> >> put
> >>>>>> together a solution that works independent of a container, and in
> >> SE
> >>>>> since
> >>>>>> I really want there to be a single context for the JVM.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Yes. It is actually the cleanest if you dont support multi apps
> >>>>> deployment
> >>>>>> cause this way you unify all libs look ups (ds, beanutils, mp
> >> config,
> >>>>> ....)
> >>>>>>
> >>>>>>
> >>>>>> I've narrowed the issue down to the classloader used once the
> >> servlet
> >>>>>> listener starts up. It is in fact using the webapp classloader at
> >>> that
> >>>>>> point.
> >>>>>>
> >>>>>> I was thinking a cleaner solution would be to create an additional
> >>>>>> constructor in WebBeansConfigurationListener that took the proper
> >>>>>> WebBeansContext to look up, instead of relying on the singleton
> >>> service
> >>>>> to
> >>>>>> look one up.
> >>>>>>
> >>>>>>
> >>>>>> It is the same, you just have to set the singleton service matching
> >>>> your
> >>>>>> environment.
> >>>>>>
> >>>>>> You can also delay the cdi startup to be done in the web context
> >> with
> >>>> the
> >>>>>> right tccl.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Le 7 mars 2018 03:27, "John D. Ament" <jo...@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
> >>>> <struberg@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 <
> >>>> johndament@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
> >> <struberg@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 <
> >>>>>>>>> rmannibucau@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" <johndament@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
>
>
Re: Consistent results for CDI.current().getBeanManager()
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
John, another proposal. I've implemented the same for the Meecrowave JUnit integration.
Could you create a 'client' UrlClassLoader with no own URLs?
And then per your 'slice' switch the TCCL accordingly?
That way you will get perfect isolation.
LieGrue,
strub
> Am 09.04.2018 um 14:10 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> 2018-04-09 14:07 GMT+02:00 John D. Ament <jo...@apache.org>:
>
>> On Mon, Apr 9, 2018 at 7:55 AM Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>
>>> 2018-04-09 13:34 GMT+02:00 John D. Ament <jo...@apache.org>:
>>>
>>>> Yeah, I hit that. I was able to get around the listener issue, but
>> then
>>>> this still occurred (its actually within OwbCDI where it fails next).
>>>>
>>>> Basically, TCCLs don't make sense in SE, and its pretty key to how OWB
>>>> works.
>>>>
>>>
>>> Hmm why? it is as important than in other cases.
>>>
>>>
>>>>
>>>> Is there a way that CDI.current() could resolve to the OWBContainer
>> that
>>>> was used to bootstrap? Since SeContainer implements Instance, most of
>>> the
>>>> work would be there already for the CDI object.
>>>>
>>>> Or should OWB somehow override the finder in OWBInitializer (initialize
>>> or
>>>> newContainer methods I had in mind).
>>>>
>>>
>>> Think you really want to impl a finder for your particular case. Sounds
>>> like you want a singleton and not a webapp instance but still deploying a
>>> webapp, no?
>>>
>>>
>> I was thinking its blocked by the spec, but you have
>> your SeContainerSelector so I can replace with my own impl. Not ideal,
>> since SE really should just mean single container but I suppose it will
>> work.
>>
>
> Not sure, in meecrowave or tomee (to come) we support it for N contexts
> potentially.
> Spec allows to manipulate one context but still deploy N (N>1) which is
> important for packaged apps (=including N elementary apps).
>
> If you don't respect the TCCL then you are probably broken with most
> mainstream libs - it is sadly common to use the classloader as a key of a
> cache - so maybe the first step is to fix that?
> Forcing tomcat or jetty to reuse the launching classloader is quite easy so
> maybe the way to go for your case?
>
>
>>
>>
>>>
>>>>
>>>> John
>>>>
>>>> On Mon, Apr 9, 2018 at 3:21 AM Mark Struberg <struberg@yahoo.de.invalid
>>>
>>>> wrote:
>>>>
>>>>> This is kind of a circular issue.
>>>>>
>>>>> Look at WebBeansContext#getInstance()
>>>>>
>>>>> public static WebBeansContext getInstance()
>>>>> {
>>>>> WebBeansContext webBeansContext =
>>>>> WebBeansFinder.getSingletonInstance();
>>>>>
>>>>>
>>>>> And WebBeansFinder.getSingletonInstance() in turn again uses the
>> TCCL
>>> to
>>>>> look up the WebBeansContext.
>>>>>
>>>>> So even if you create a WebBeansContext with an explicit
>> FinderService,
>>>> it
>>>>> would not make much difference I fear.
>>>>>
>>>>> LieGrue,
>>>>> strub
>>>>>
>>>>>
>>>>>> Am 09.04.2018 um 08:25 schrieb Romain Manni-Bucau <
>>>> rmannibucau@gmail.com
>>>>>> :
>>>>>>
>>>>>> Le 9 avr. 2018 02:33, "John D. Ament" <jo...@apache.org> a
>>> écrit
>>>> :
>>>>>>
>>>>>> On Wed, Mar 7, 2018 at 1:33 AM Romain Manni-Bucau <
>>>> rmannibucau@gmail.com
>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> Is it in hammock? Did you force the webapp container to use the
>>>>>>> appclassloader in case of a secontainer?
>>>>>>>
>>>>>>
>>>>>> How would I do that? You mean inside of Tomcat? I'd much rather
>> put
>>>>>> together a solution that works independent of a container, and in
>> SE
>>>>> since
>>>>>> I really want there to be a single context for the JVM.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes. It is actually the cleanest if you dont support multi apps
>>>>> deployment
>>>>>> cause this way you unify all libs look ups (ds, beanutils, mp
>> config,
>>>>> ....)
>>>>>>
>>>>>>
>>>>>> I've narrowed the issue down to the classloader used once the
>> servlet
>>>>>> listener starts up. It is in fact using the webapp classloader at
>>> that
>>>>>> point.
>>>>>>
>>>>>> I was thinking a cleaner solution would be to create an additional
>>>>>> constructor in WebBeansConfigurationListener that took the proper
>>>>>> WebBeansContext to look up, instead of relying on the singleton
>>> service
>>>>> to
>>>>>> look one up.
>>>>>>
>>>>>>
>>>>>> It is the same, you just have to set the singleton service matching
>>>> your
>>>>>> environment.
>>>>>>
>>>>>> You can also delay the cdi startup to be done in the web context
>> with
>>>> the
>>>>>> right tccl.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Le 7 mars 2018 03:27, "John D. Ament" <jo...@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
>>>> <struberg@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 <
>>>> johndament@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
>> <struberg@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 <
>>>>>>>>> rmannibucau@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" <johndament@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
Re: Consistent results for CDI.current().getBeanManager()
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2018-04-09 14:07 GMT+02:00 John D. Ament <jo...@apache.org>:
> On Mon, Apr 9, 2018 at 7:55 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > 2018-04-09 13:34 GMT+02:00 John D. Ament <jo...@apache.org>:
> >
> > > Yeah, I hit that. I was able to get around the listener issue, but
> then
> > > this still occurred (its actually within OwbCDI where it fails next).
> > >
> > > Basically, TCCLs don't make sense in SE, and its pretty key to how OWB
> > > works.
> > >
> >
> > Hmm why? it is as important than in other cases.
> >
> >
> > >
> > > Is there a way that CDI.current() could resolve to the OWBContainer
> that
> > > was used to bootstrap? Since SeContainer implements Instance, most of
> > the
> > > work would be there already for the CDI object.
> > >
> > > Or should OWB somehow override the finder in OWBInitializer (initialize
> > or
> > > newContainer methods I had in mind).
> > >
> >
> > Think you really want to impl a finder for your particular case. Sounds
> > like you want a singleton and not a webapp instance but still deploying a
> > webapp, no?
> >
> >
> I was thinking its blocked by the spec, but you have
> your SeContainerSelector so I can replace with my own impl. Not ideal,
> since SE really should just mean single container but I suppose it will
> work.
>
Not sure, in meecrowave or tomee (to come) we support it for N contexts
potentially.
Spec allows to manipulate one context but still deploy N (N>1) which is
important for packaged apps (=including N elementary apps).
If you don't respect the TCCL then you are probably broken with most
mainstream libs - it is sadly common to use the classloader as a key of a
cache - so maybe the first step is to fix that?
Forcing tomcat or jetty to reuse the launching classloader is quite easy so
maybe the way to go for your case?
>
>
> >
> > >
> > > John
> > >
> > > On Mon, Apr 9, 2018 at 3:21 AM Mark Struberg <struberg@yahoo.de.invalid
> >
> > > wrote:
> > >
> > > > This is kind of a circular issue.
> > > >
> > > > Look at WebBeansContext#getInstance()
> > > >
> > > > public static WebBeansContext getInstance()
> > > > {
> > > > WebBeansContext webBeansContext =
> > > > WebBeansFinder.getSingletonInstance();
> > > >
> > > >
> > > > And WebBeansFinder.getSingletonInstance() in turn again uses the
> TCCL
> > to
> > > > look up the WebBeansContext.
> > > >
> > > > So even if you create a WebBeansContext with an explicit
> FinderService,
> > > it
> > > > would not make much difference I fear.
> > > >
> > > > LieGrue,
> > > > strub
> > > >
> > > >
> > > > > Am 09.04.2018 um 08:25 schrieb Romain Manni-Bucau <
> > > rmannibucau@gmail.com
> > > > >:
> > > > >
> > > > > Le 9 avr. 2018 02:33, "John D. Ament" <jo...@apache.org> a
> > écrit
> > > :
> > > > >
> > > > > On Wed, Mar 7, 2018 at 1:33 AM Romain Manni-Bucau <
> > > rmannibucau@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > >> Is it in hammock? Did you force the webapp container to use the
> > > > >> appclassloader in case of a secontainer?
> > > > >>
> > > > >
> > > > > How would I do that? You mean inside of Tomcat? I'd much rather
> put
> > > > > together a solution that works independent of a container, and in
> SE
> > > > since
> > > > > I really want there to be a single context for the JVM.
> > > > >
> > > > >
> > > > >
> > > > > Yes. It is actually the cleanest if you dont support multi apps
> > > > deployment
> > > > > cause this way you unify all libs look ups (ds, beanutils, mp
> config,
> > > > ....)
> > > > >
> > > > >
> > > > > I've narrowed the issue down to the classloader used once the
> servlet
> > > > > listener starts up. It is in fact using the webapp classloader at
> > that
> > > > > point.
> > > > >
> > > > > I was thinking a cleaner solution would be to create an additional
> > > > > constructor in WebBeansConfigurationListener that took the proper
> > > > > WebBeansContext to look up, instead of relying on the singleton
> > service
> > > > to
> > > > > look one up.
> > > > >
> > > > >
> > > > > It is the same, you just have to set the singleton service matching
> > > your
> > > > > environment.
> > > > >
> > > > > You can also delay the cdi startup to be done in the web context
> with
> > > the
> > > > > right tccl.
> > > > >
> > > > >
> > > > >
> > > > >>
> > > > >> Le 7 mars 2018 03:27, "John D. Ament" <jo...@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
> > > <struberg@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 <
> > > johndament@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
> <struberg@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 <
> > > > >>>> rmannibucau@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" <johndament@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
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: Consistent results for CDI.current().getBeanManager()
Posted by "John D. Ament" <jo...@apache.org>.
On Mon, Apr 9, 2018 at 7:55 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> 2018-04-09 13:34 GMT+02:00 John D. Ament <jo...@apache.org>:
>
> > Yeah, I hit that. I was able to get around the listener issue, but then
> > this still occurred (its actually within OwbCDI where it fails next).
> >
> > Basically, TCCLs don't make sense in SE, and its pretty key to how OWB
> > works.
> >
>
> Hmm why? it is as important than in other cases.
>
>
> >
> > Is there a way that CDI.current() could resolve to the OWBContainer that
> > was used to bootstrap? Since SeContainer implements Instance, most of
> the
> > work would be there already for the CDI object.
> >
> > Or should OWB somehow override the finder in OWBInitializer (initialize
> or
> > newContainer methods I had in mind).
> >
>
> Think you really want to impl a finder for your particular case. Sounds
> like you want a singleton and not a webapp instance but still deploying a
> webapp, no?
>
>
I was thinking its blocked by the spec, but you have
your SeContainerSelector so I can replace with my own impl. Not ideal,
since SE really should just mean single container but I suppose it will
work.
>
> >
> > John
> >
> > On Mon, Apr 9, 2018 at 3:21 AM Mark Struberg <st...@yahoo.de.invalid>
> > wrote:
> >
> > > This is kind of a circular issue.
> > >
> > > Look at WebBeansContext#getInstance()
> > >
> > > public static WebBeansContext getInstance()
> > > {
> > > WebBeansContext webBeansContext =
> > > WebBeansFinder.getSingletonInstance();
> > >
> > >
> > > And WebBeansFinder.getSingletonInstance() in turn again uses the TCCL
> to
> > > look up the WebBeansContext.
> > >
> > > So even if you create a WebBeansContext with an explicit FinderService,
> > it
> > > would not make much difference I fear.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > > > Am 09.04.2018 um 08:25 schrieb Romain Manni-Bucau <
> > rmannibucau@gmail.com
> > > >:
> > > >
> > > > Le 9 avr. 2018 02:33, "John D. Ament" <jo...@apache.org> a
> écrit
> > :
> > > >
> > > > On Wed, Mar 7, 2018 at 1:33 AM Romain Manni-Bucau <
> > rmannibucau@gmail.com
> > > >
> > > > wrote:
> > > >
> > > >> Is it in hammock? Did you force the webapp container to use the
> > > >> appclassloader in case of a secontainer?
> > > >>
> > > >
> > > > How would I do that? You mean inside of Tomcat? I'd much rather put
> > > > together a solution that works independent of a container, and in SE
> > > since
> > > > I really want there to be a single context for the JVM.
> > > >
> > > >
> > > >
> > > > Yes. It is actually the cleanest if you dont support multi apps
> > > deployment
> > > > cause this way you unify all libs look ups (ds, beanutils, mp config,
> > > ....)
> > > >
> > > >
> > > > I've narrowed the issue down to the classloader used once the servlet
> > > > listener starts up. It is in fact using the webapp classloader at
> that
> > > > point.
> > > >
> > > > I was thinking a cleaner solution would be to create an additional
> > > > constructor in WebBeansConfigurationListener that took the proper
> > > > WebBeansContext to look up, instead of relying on the singleton
> service
> > > to
> > > > look one up.
> > > >
> > > >
> > > > It is the same, you just have to set the singleton service matching
> > your
> > > > environment.
> > > >
> > > > You can also delay the cdi startup to be done in the web context with
> > the
> > > > right tccl.
> > > >
> > > >
> > > >
> > > >>
> > > >> Le 7 mars 2018 03:27, "John D. Ament" <jo...@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
> > <struberg@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 <
> > johndament@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 <struberg@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 <
> > > >>>> rmannibucau@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" <jo...@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
> > > >>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
>
Re: Consistent results for CDI.current().getBeanManager()
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2018-04-09 13:34 GMT+02:00 John D. Ament <jo...@apache.org>:
> Yeah, I hit that. I was able to get around the listener issue, but then
> this still occurred (its actually within OwbCDI where it fails next).
>
> Basically, TCCLs don't make sense in SE, and its pretty key to how OWB
> works.
>
Hmm why? it is as important than in other cases.
>
> Is there a way that CDI.current() could resolve to the OWBContainer that
> was used to bootstrap? Since SeContainer implements Instance, most of the
> work would be there already for the CDI object.
>
> Or should OWB somehow override the finder in OWBInitializer (initialize or
> newContainer methods I had in mind).
>
Think you really want to impl a finder for your particular case. Sounds
like you want a singleton and not a webapp instance but still deploying a
webapp, no?
>
> John
>
> On Mon, Apr 9, 2018 at 3:21 AM Mark Struberg <st...@yahoo.de.invalid>
> wrote:
>
> > This is kind of a circular issue.
> >
> > Look at WebBeansContext#getInstance()
> >
> > public static WebBeansContext getInstance()
> > {
> > WebBeansContext webBeansContext =
> > WebBeansFinder.getSingletonInstance();
> >
> >
> > And WebBeansFinder.getSingletonInstance() in turn again uses the TCCL to
> > look up the WebBeansContext.
> >
> > So even if you create a WebBeansContext with an explicit FinderService,
> it
> > would not make much difference I fear.
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 09.04.2018 um 08:25 schrieb Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >:
> > >
> > > Le 9 avr. 2018 02:33, "John D. Ament" <jo...@apache.org> a écrit
> :
> > >
> > > On Wed, Mar 7, 2018 at 1:33 AM Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > > wrote:
> > >
> > >> Is it in hammock? Did you force the webapp container to use the
> > >> appclassloader in case of a secontainer?
> > >>
> > >
> > > How would I do that? You mean inside of Tomcat? I'd much rather put
> > > together a solution that works independent of a container, and in SE
> > since
> > > I really want there to be a single context for the JVM.
> > >
> > >
> > >
> > > Yes. It is actually the cleanest if you dont support multi apps
> > deployment
> > > cause this way you unify all libs look ups (ds, beanutils, mp config,
> > ....)
> > >
> > >
> > > I've narrowed the issue down to the classloader used once the servlet
> > > listener starts up. It is in fact using the webapp classloader at that
> > > point.
> > >
> > > I was thinking a cleaner solution would be to create an additional
> > > constructor in WebBeansConfigurationListener that took the proper
> > > WebBeansContext to look up, instead of relying on the singleton service
> > to
> > > look one up.
> > >
> > >
> > > It is the same, you just have to set the singleton service matching
> your
> > > environment.
> > >
> > > You can also delay the cdi startup to be done in the web context with
> the
> > > right tccl.
> > >
> > >
> > >
> > >>
> > >> Le 7 mars 2018 03:27, "John D. Ament" <jo...@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
> <struberg@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 <
> johndament@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 <st...@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 <
> > >>>> rmannibucau@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" <jo...@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
> > >>>>
> > >>>>
> > >>>
> > >>
> >
> >
>
Re: Consistent results for CDI.current().getBeanManager()
Posted by "John D. Ament" <jo...@apache.org>.
Yeah, I hit that. I was able to get around the listener issue, but then
this still occurred (its actually within OwbCDI where it fails next).
Basically, TCCLs don't make sense in SE, and its pretty key to how OWB
works.
Is there a way that CDI.current() could resolve to the OWBContainer that
was used to bootstrap? Since SeContainer implements Instance, most of the
work would be there already for the CDI object.
Or should OWB somehow override the finder in OWBInitializer (initialize or
newContainer methods I had in mind).
John
On Mon, Apr 9, 2018 at 3:21 AM Mark Struberg <st...@yahoo.de.invalid>
wrote:
> This is kind of a circular issue.
>
> Look at WebBeansContext#getInstance()
>
> public static WebBeansContext getInstance()
> {
> WebBeansContext webBeansContext =
> WebBeansFinder.getSingletonInstance();
>
>
> And WebBeansFinder.getSingletonInstance() in turn again uses the TCCL to
> look up the WebBeansContext.
>
> So even if you create a WebBeansContext with an explicit FinderService, it
> would not make much difference I fear.
>
> LieGrue,
> strub
>
>
> > Am 09.04.2018 um 08:25 schrieb Romain Manni-Bucau <rmannibucau@gmail.com
> >:
> >
> > Le 9 avr. 2018 02:33, "John D. Ament" <jo...@apache.org> a écrit :
> >
> > On Wed, Mar 7, 2018 at 1:33 AM Romain Manni-Bucau <rmannibucau@gmail.com
> >
> > wrote:
> >
> >> Is it in hammock? Did you force the webapp container to use the
> >> appclassloader in case of a secontainer?
> >>
> >
> > How would I do that? You mean inside of Tomcat? I'd much rather put
> > together a solution that works independent of a container, and in SE
> since
> > I really want there to be a single context for the JVM.
> >
> >
> >
> > Yes. It is actually the cleanest if you dont support multi apps
> deployment
> > cause this way you unify all libs look ups (ds, beanutils, mp config,
> ....)
> >
> >
> > I've narrowed the issue down to the classloader used once the servlet
> > listener starts up. It is in fact using the webapp classloader at that
> > point.
> >
> > I was thinking a cleaner solution would be to create an additional
> > constructor in WebBeansConfigurationListener that took the proper
> > WebBeansContext to look up, instead of relying on the singleton service
> to
> > look one up.
> >
> >
> > It is the same, you just have to set the singleton service matching your
> > environment.
> >
> > You can also delay the cdi startup to be done in the web context with the
> > right tccl.
> >
> >
> >
> >>
> >> Le 7 mars 2018 03:27, "John D. Ament" <jo...@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 <struberg@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 <johndament@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 <st...@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 <
> >>>> rmannibucau@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" <jo...@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
> >>>>
> >>>>
> >>>
> >>
>
>
Re: Consistent results for CDI.current().getBeanManager()
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
This is kind of a circular issue.
Look at WebBeansContext#getInstance()
public static WebBeansContext getInstance()
{
WebBeansContext webBeansContext = WebBeansFinder.getSingletonInstance();
And WebBeansFinder.getSingletonInstance() in turn again uses the TCCL to look up the WebBeansContext.
So even if you create a WebBeansContext with an explicit FinderService, it would not make much difference I fear.
LieGrue,
strub
> Am 09.04.2018 um 08:25 schrieb Romain Manni-Bucau <rm...@gmail.com>:
>
> Le 9 avr. 2018 02:33, "John D. Ament" <jo...@apache.org> a écrit :
>
> On Wed, Mar 7, 2018 at 1:33 AM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> Is it in hammock? Did you force the webapp container to use the
>> appclassloader in case of a secontainer?
>>
>
> How would I do that? You mean inside of Tomcat? I'd much rather put
> together a solution that works independent of a container, and in SE since
> I really want there to be a single context for the JVM.
>
>
>
> Yes. It is actually the cleanest if you dont support multi apps deployment
> cause this way you unify all libs look ups (ds, beanutils, mp config, ....)
>
>
> I've narrowed the issue down to the classloader used once the servlet
> listener starts up. It is in fact using the webapp classloader at that
> point.
>
> I was thinking a cleaner solution would be to create an additional
> constructor in WebBeansConfigurationListener that took the proper
> WebBeansContext to look up, instead of relying on the singleton service to
> look one up.
>
>
> It is the same, you just have to set the singleton service matching your
> environment.
>
> You can also delay the cdi startup to be done in the web context with the
> right tccl.
>
>
>
>>
>> Le 7 mars 2018 03:27, "John D. Ament" <jo...@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 <st...@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 <johndament@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 <st...@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 <
>>>> rmannibucau@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" <jo...@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
>>>>
>>>>
>>>
>>
Re: Consistent results for CDI.current().getBeanManager()
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le 9 avr. 2018 02:33, "John D. Ament" <jo...@apache.org> a écrit :
On Wed, Mar 7, 2018 at 1:33 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Is it in hammock? Did you force the webapp container to use the
> appclassloader in case of a secontainer?
>
How would I do that? You mean inside of Tomcat? I'd much rather put
together a solution that works independent of a container, and in SE since
I really want there to be a single context for the JVM.
Yes. It is actually the cleanest if you dont support multi apps deployment
cause this way you unify all libs look ups (ds, beanutils, mp config, ....)
I've narrowed the issue down to the classloader used once the servlet
listener starts up. It is in fact using the webapp classloader at that
point.
I was thinking a cleaner solution would be to create an additional
constructor in WebBeansConfigurationListener that took the proper
WebBeansContext to look up, instead of relying on the singleton service to
look one up.
It is the same, you just have to set the singleton service matching your
environment.
You can also delay the cdi startup to be done in the web context with the
right tccl.
>
> Le 7 mars 2018 03:27, "John D. Ament" <jo...@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 <st...@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 <johndament@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 <st...@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 <
> > > rmannibucau@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" <jo...@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
> > >
> > >
> >
>
Re: Consistent results for CDI.current().getBeanManager()
Posted by "John D. Ament" <jo...@apache.org>.
On Wed, Mar 7, 2018 at 1:33 AM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Is it in hammock? Did you force the webapp container to use the
> appclassloader in case of a secontainer?
>
How would I do that? You mean inside of Tomcat? I'd much rather put
together a solution that works independent of a container, and in SE since
I really want there to be a single context for the JVM.
I've narrowed the issue down to the classloader used once the servlet
listener starts up. It is in fact using the webapp classloader at that
point.
I was thinking a cleaner solution would be to create an additional
constructor in WebBeansConfigurationListener that took the proper
WebBeansContext to look up, instead of relying on the singleton service to
look one up.
>
> Le 7 mars 2018 03:27, "John D. Ament" <jo...@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 <st...@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 <johndament@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 <st...@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 <
> > > rmannibucau@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" <jo...@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
> > >
> > >
> >
>
Re: Consistent results for CDI.current().getBeanManager()
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <jo...@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 <st...@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 <jo...@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 <st...@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 <
> > rmannibucau@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" <jo...@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
> >
> >
>
Re: Consistent results for CDI.current().getBeanManager()
Posted by "John D. Ament" <jo...@apache.org>.
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 <st...@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 <jo...@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 <st...@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 <
> rmannibucau@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" <jo...@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
>
>
Re: Consistent results for CDI.current().getBeanManager()
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
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 <jo...@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 <st...@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 <rm...@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" <jo...@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
Re: Consistent results for CDI.current().getBeanManager()
Posted by "John D. Ament" <jo...@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 <st...@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 <rm...@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" <jo...@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
> >>
>
>
Re: Consistent results for CDI.current().getBeanManager()
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
+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 <rm...@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" <jo...@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
>>
Re: Consistent results for CDI.current().getBeanManager()
Posted by Romain Manni-Bucau <rm...@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" <jo...@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
>