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