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