On Mon, Apr 9, 2018 at 7:55 AM Romain Manni-Bucau <[email protected]> wrote:
> 2018-04-09 13:34 GMT+02:00 John D. Ament <[email protected]>: > > > 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 <[email protected]> > > 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 < > > [email protected] > > > >: > > > > > > > > Le 9 avr. 2018 02:33, "John D. Ament" <[email protected]> a > écrit > > : > > > > > > > > On Wed, Mar 7, 2018 at 1:33 AM Romain Manni-Bucau < > > [email protected] > > > > > > > > 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" <[email protected]> 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 > > <[email protected] > > > > > > > >>> 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 < > > [email protected] > > > >>> : > > > >>>>> > > > >>>>> 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 <[email protected] > > > > > >>> 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 < > > > >>>> [email protected]>: > > > >>>>>>> > > > >>>>>>> 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" <[email protected]> > 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 > > > >>>> > > > >>>> > > > >>> > > > >> > > > > > > > > >
