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