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