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
