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

Reply via email to