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
>>
>>
