Re: Consistent results for CDI.current().getBeanManager()

Le 11 avr. 2018 01:55, "John D. Ament" 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.

Re: Consistent results for CDI.current().getBeanManager()

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

Re: Consistent results for CDI.current().getBeanManager()

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 wrote: > John, another proposal. I've implemented the same for the Meecrowave JUnit > integration. > Could you create

Re: Consistent results for CDI.current().getBeanManager()

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

Re: Consistent results for CDI.current().getBeanManager()

2018-04-09 14:07 GMT+02:00 John D. Ament : > On Mon, Apr 9, 2018 at 7:55 AM Romain Manni-Bucau > wrote: > > > 2018-04-09 13:34 GMT+02:00 John D. Ament : > > > > > Yeah, I hit that. I was able to get around the listener issue,

Re: Consistent results for CDI.current().getBeanManager()

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. Is there a way that CDI.current() could resolve to the OWBContainer that

Re: Consistent results for CDI.current().getBeanManager()

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

Re: Consistent results for CDI.current().getBeanManager()

Le 9 avr. 2018 02:33, "John D. Ament" a écrit : On Wed, Mar 7, 2018 at 1:33 AM Romain Manni-Bucau 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

Re: Consistent results for CDI.current().getBeanManager()

On Wed, Mar 7, 2018 at 1:33 AM Romain Manni-Bucau 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

Re: Consistent results for CDI.current().getBeanManager()

Is it in hammock? Did you force the webapp container to use the appclassloader in case of a secontainer? Le 7 mars 2018 03:27, "John D. Ament" a écrit : > That pretty much sums up the issue. > > When the app starts, the current thread is main. > When the webapp launches,

Re: Consistent results for CDI.current().getBeanManager()

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 : > > Yes,

Re: Consistent results for CDI.current().getBeanManager()

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

Re: Consistent results for CDI.current().getBeanManager()

+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. But you can change this to a custom one. Btw CDI.current() will always give you an

Re: Consistent results for CDI.current().getBeanManager()

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

Consistent results for CDI.current().getBeanManager()

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