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