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

Reply via email to