Le 11 avr. 2018 01:55, "John D. Ament" <johndam...@apache.org> a écrit :
This is what I was able to get working. https://github.com/hammock-project/hammock/commit/ 8f50242634b370b12c1f291a1f3fc83e3d7533c2 However, I'll be honest and say it seems like a big gap that OWB isn't dealing with this. I haven't done thorough testing, but if I'm using SE and an executor service, I could likely hit a similar issue right? For the "gap" just keep in mind it is easy to report bugs against your setup due to your classloader mix. Your are in the state of tomee embedded a few years ago and we got several issues cause of that and needed to fix it forcing a consistent classloader accross the whole chain so tempted to say the gap is probably not on owb for this one. Not sure what you mean with the executor service but you will get one per context if not using the default yes. On Mon, Apr 9, 2018 at 11:10 AM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Yes but this will not work for you John since you will end up with 3 > classloaders instead of 1 still and no singleton service unifying it. > > What can work if you use the default singleton is to register the > existing context for other classloaders: > > DefaultSingletonService.class.cast(singletonInstance).register(loader, > context); > > > Romain Manni-Bucau > @rmannibucau | Blog | Old Blog | Github | LinkedIn | Book > > > 2018-04-09 16:37 GMT+02:00 John D. Ament <johndam...@apache.org>: > > Did you mean ClassLoaderLock in meecrowave? Or something like the Rule > > defined by MonoMeecrowave? > > > > John > > > > On Mon, Apr 9, 2018 at 8:27 AM Mark Struberg <strub...@yahoo.de.invalid> > > wrote: > > > >> John, another proposal. I've implemented the same for the Meecrowave > JUnit > >> integration. > >> Could you create a 'client' UrlClassLoader with no own URLs? > >> And then per your 'slice' switch the TCCL accordingly? > >> > >> That way you will get perfect isolation. > >> > >> LieGrue, > >> strub > >> > >> > >> > Am 09.04.2018 um 14:10 schrieb Romain Manni-Bucau < > rmannibu...@gmail.com > >> >: > >> > > >> > 2018-04-09 14:07 GMT+02:00 John D. Ament <johndam...@apache.org>: > >> > > >> >> 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. > >> >> > >> > > >> > Not sure, in meecrowave or tomee (to come) we support it for N > contexts > >> > potentially. > >> > Spec allows to manipulate one context but still deploy N (N>1) which > is > >> > important for packaged apps (=including N elementary apps). > >> > > >> > If you don't respect the TCCL then you are probably broken with most > >> > mainstream libs - it is sadly common to use the classloader as a key > of a > >> > cache - so maybe the first step is to fix that? > >> > Forcing tomcat or jetty to reuse the launching classloader is quite > easy > >> so > >> > maybe the way to go for your case? > >> > > >> > > >> >> > >> >> > >> >>> > >> >>>> > >> >>>> 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 > >> > >> >
