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.


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