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