You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Matt Benson <mb...@apache.org> on 2014/11/06 23:47:26 UTC
BeanManagerProvider for parent classloader
Hi all,
I have a situation where I'm trying to get the BeanManager
associated with the parent CL of my TCCL. Using DS 1.1.0 and 1.0.3 I
note that BeanManagerProvider#getBeanManagerInfo(ClassLoader) blows
away the already-initialized BeanManagerInfo for my parent CL due to
the commit at [1]; however even with DS 1.0.2 (before this commit), I
don't see that any related code actually uses the parent ClassLoader
to retrieve a BeanManager for a given context ClassLoader
(BeanManagerProvider#getBeanManager() does call
#isParentBeanManagerBooted(), but the parent CL does not seem to be
consulted anywhere else). The simple way to address [1] is to check
whether there is already an info object stored for the parent before
initializing it. But what do we think is the correct behavior in
general? It would seem reasonable to say that for a given context, the
nearest BeanManager associated with the CCL or any ancestor CL would
be the appropriate result. What do others think?
Matt
[1] https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=35883fbd0d1a1c3dfc9023d67d4c5449e97fe6c2;hp=88fdfaee36b7639af46ca0f811e4bac9dd63197d
Re: BeanManagerProvider for parent classloader
Posted by Gerhard Petracek <ge...@gmail.com>.
@romain: +1 (i was going to create a ticket for that anyway.)
regards,
gerhard
2014-11-07 19:24 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> I'd go for the default support of CDI.current(). In all case we leak
> by default (redeployment) so we should do something
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-11-07 18:23 GMT+00:00 Matt Benson <gu...@gmail.com>:
> > Romain: CDI.current() was a good suggestion. It works for me with a
> > recent version of Weld SE. Now I can use the
> > BeanProvider#getContextualReference() variants that accept the
> > BeanManager. In this case it would seem we should overload
> > BeanProvider#getContextualReference() with (BeanManager, String,
> > boolean, Class).
> >
> > Matt
> >
> > On Fri, Nov 7, 2014 at 11:34 AM, Romain Manni-Bucau
> > <rm...@gmail.com> wrote:
> >> Hi Matt,
> >>
> >> nearest is totally broken in OSGi, it is also in EE with ear (you can
> >> desire an IllegalStateException from a webapp but a BeanManager from
> >> the lib part). BeanManagerProvider should try CDI.current() if
> >> availabe (by reflection to not depend on CDI 1.1) and use Weld/OWB api
> >> if not and finally use the classloader if nothing worked (ie
> >> ClassNotFoundException/NoClassDefFoundError).
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau
> >> http://www.tomitribe.com
> >> http://rmannibucau.wordpress.com
> >> https://github.com/rmannibucau
> >>
> >>
> >> 2014-11-07 17:30 GMT+00:00 Matt Benson <gu...@gmail.com>:
> >>> Hi John,
> >>> The concept is IMO broadly applicable to any situation using child
> >>> ClassLoaders, but by way of providing a specific example, I have a
> >>> process in which I'm firing up a standalone CDI container; then,
> >>> parallel to that, I have a CRaSH shell running. I want visibility from
> >>> my custom CRaSH commands to my BeanManager, but CRaSH invokes my
> >>> commands using an intermediate ClassLoader. I suppose that in DS 1.0.2
> >>> I could call BeanProvider#getBeanManager(), catch
> >>> IllegalStateException, and walk up the CL hierarchy setting the CCL
> >>> until I find the BeanManager, but from 1.0.3 forward your change will
> >>> wipe out the parent BM info if the child CL has none. So this is the
> >>> first order of business; next is the larger question of whether it is
> >>> appropriate to do as I suggest: implement #getBeanMaangre() such that
> >>> the "nearest" (in the sense of walking up the CL hierarcy) BeanManager
> >>> associated with the CCL is returned. If not, why not?
> >>>
> >>> Thanks,
> >>> Matt
> >>>
> >>> On Thu, Nov 6, 2014 at 6:54 PM, John D. Ament <jo...@gmail.com>
> wrote:
> >>>> Matt,
> >>>>
> >>>> Can you provide some more info about your use case?
> >>>>
> >>>> This commit was supposed to be for some shrinkwrap specific issue.
> >>>>
> >>>> John
> >>>>
> >>>> On Thu, Nov 6, 2014 at 5:47 PM, Matt Benson <mb...@apache.org>
> wrote:
> >>>>
> >>>>> Hi all,
> >>>>> I have a situation where I'm trying to get the BeanManager
> >>>>> associated with the parent CL of my TCCL. Using DS 1.1.0 and 1.0.3 I
> >>>>> note that BeanManagerProvider#getBeanManagerInfo(ClassLoader) blows
> >>>>> away the already-initialized BeanManagerInfo for my parent CL due to
> >>>>> the commit at [1]; however even with DS 1.0.2 (before this commit), I
> >>>>> don't see that any related code actually uses the parent ClassLoader
> >>>>> to retrieve a BeanManager for a given context ClassLoader
> >>>>> (BeanManagerProvider#getBeanManager() does call
> >>>>> #isParentBeanManagerBooted(), but the parent CL does not seem to be
> >>>>> consulted anywhere else). The simple way to address [1] is to check
> >>>>> whether there is already an info object stored for the parent before
> >>>>> initializing it. But what do we think is the correct behavior in
> >>>>> general? It would seem reasonable to say that for a given context,
> the
> >>>>> nearest BeanManager associated with the CCL or any ancestor CL would
> >>>>> be the appropriate result. What do others think?
> >>>>>
> >>>>> Matt
> >>>>>
> >>>>> [1]
> >>>>>
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=35883fbd0d1a1c3dfc9023d67d4c5449e97fe6c2;hp=88fdfaee36b7639af46ca0f811e4bac9dd63197d
> >>>>>
>
Re: BeanManagerProvider for parent classloader
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I'd go for the default support of CDI.current(). In all case we leak
by default (redeployment) so we should do something
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-11-07 18:23 GMT+00:00 Matt Benson <gu...@gmail.com>:
> Romain: CDI.current() was a good suggestion. It works for me with a
> recent version of Weld SE. Now I can use the
> BeanProvider#getContextualReference() variants that accept the
> BeanManager. In this case it would seem we should overload
> BeanProvider#getContextualReference() with (BeanManager, String,
> boolean, Class).
>
> Matt
>
> On Fri, Nov 7, 2014 at 11:34 AM, Romain Manni-Bucau
> <rm...@gmail.com> wrote:
>> Hi Matt,
>>
>> nearest is totally broken in OSGi, it is also in EE with ear (you can
>> desire an IllegalStateException from a webapp but a BeanManager from
>> the lib part). BeanManagerProvider should try CDI.current() if
>> availabe (by reflection to not depend on CDI 1.1) and use Weld/OWB api
>> if not and finally use the classloader if nothing worked (ie
>> ClassNotFoundException/NoClassDefFoundError).
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau
>> http://www.tomitribe.com
>> http://rmannibucau.wordpress.com
>> https://github.com/rmannibucau
>>
>>
>> 2014-11-07 17:30 GMT+00:00 Matt Benson <gu...@gmail.com>:
>>> Hi John,
>>> The concept is IMO broadly applicable to any situation using child
>>> ClassLoaders, but by way of providing a specific example, I have a
>>> process in which I'm firing up a standalone CDI container; then,
>>> parallel to that, I have a CRaSH shell running. I want visibility from
>>> my custom CRaSH commands to my BeanManager, but CRaSH invokes my
>>> commands using an intermediate ClassLoader. I suppose that in DS 1.0.2
>>> I could call BeanProvider#getBeanManager(), catch
>>> IllegalStateException, and walk up the CL hierarchy setting the CCL
>>> until I find the BeanManager, but from 1.0.3 forward your change will
>>> wipe out the parent BM info if the child CL has none. So this is the
>>> first order of business; next is the larger question of whether it is
>>> appropriate to do as I suggest: implement #getBeanMaangre() such that
>>> the "nearest" (in the sense of walking up the CL hierarcy) BeanManager
>>> associated with the CCL is returned. If not, why not?
>>>
>>> Thanks,
>>> Matt
>>>
>>> On Thu, Nov 6, 2014 at 6:54 PM, John D. Ament <jo...@gmail.com> wrote:
>>>> Matt,
>>>>
>>>> Can you provide some more info about your use case?
>>>>
>>>> This commit was supposed to be for some shrinkwrap specific issue.
>>>>
>>>> John
>>>>
>>>> On Thu, Nov 6, 2014 at 5:47 PM, Matt Benson <mb...@apache.org> wrote:
>>>>
>>>>> Hi all,
>>>>> I have a situation where I'm trying to get the BeanManager
>>>>> associated with the parent CL of my TCCL. Using DS 1.1.0 and 1.0.3 I
>>>>> note that BeanManagerProvider#getBeanManagerInfo(ClassLoader) blows
>>>>> away the already-initialized BeanManagerInfo for my parent CL due to
>>>>> the commit at [1]; however even with DS 1.0.2 (before this commit), I
>>>>> don't see that any related code actually uses the parent ClassLoader
>>>>> to retrieve a BeanManager for a given context ClassLoader
>>>>> (BeanManagerProvider#getBeanManager() does call
>>>>> #isParentBeanManagerBooted(), but the parent CL does not seem to be
>>>>> consulted anywhere else). The simple way to address [1] is to check
>>>>> whether there is already an info object stored for the parent before
>>>>> initializing it. But what do we think is the correct behavior in
>>>>> general? It would seem reasonable to say that for a given context, the
>>>>> nearest BeanManager associated with the CCL or any ancestor CL would
>>>>> be the appropriate result. What do others think?
>>>>>
>>>>> Matt
>>>>>
>>>>> [1]
>>>>> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=35883fbd0d1a1c3dfc9023d67d4c5449e97fe6c2;hp=88fdfaee36b7639af46ca0f811e4bac9dd63197d
>>>>>
Re: BeanManagerProvider for parent classloader
Posted by Matt Benson <gu...@gmail.com>.
Romain: CDI.current() was a good suggestion. It works for me with a
recent version of Weld SE. Now I can use the
BeanProvider#getContextualReference() variants that accept the
BeanManager. In this case it would seem we should overload
BeanProvider#getContextualReference() with (BeanManager, String,
boolean, Class).
Matt
On Fri, Nov 7, 2014 at 11:34 AM, Romain Manni-Bucau
<rm...@gmail.com> wrote:
> Hi Matt,
>
> nearest is totally broken in OSGi, it is also in EE with ear (you can
> desire an IllegalStateException from a webapp but a BeanManager from
> the lib part). BeanManagerProvider should try CDI.current() if
> availabe (by reflection to not depend on CDI 1.1) and use Weld/OWB api
> if not and finally use the classloader if nothing worked (ie
> ClassNotFoundException/NoClassDefFoundError).
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2014-11-07 17:30 GMT+00:00 Matt Benson <gu...@gmail.com>:
>> Hi John,
>> The concept is IMO broadly applicable to any situation using child
>> ClassLoaders, but by way of providing a specific example, I have a
>> process in which I'm firing up a standalone CDI container; then,
>> parallel to that, I have a CRaSH shell running. I want visibility from
>> my custom CRaSH commands to my BeanManager, but CRaSH invokes my
>> commands using an intermediate ClassLoader. I suppose that in DS 1.0.2
>> I could call BeanProvider#getBeanManager(), catch
>> IllegalStateException, and walk up the CL hierarchy setting the CCL
>> until I find the BeanManager, but from 1.0.3 forward your change will
>> wipe out the parent BM info if the child CL has none. So this is the
>> first order of business; next is the larger question of whether it is
>> appropriate to do as I suggest: implement #getBeanMaangre() such that
>> the "nearest" (in the sense of walking up the CL hierarcy) BeanManager
>> associated with the CCL is returned. If not, why not?
>>
>> Thanks,
>> Matt
>>
>> On Thu, Nov 6, 2014 at 6:54 PM, John D. Ament <jo...@gmail.com> wrote:
>>> Matt,
>>>
>>> Can you provide some more info about your use case?
>>>
>>> This commit was supposed to be for some shrinkwrap specific issue.
>>>
>>> John
>>>
>>> On Thu, Nov 6, 2014 at 5:47 PM, Matt Benson <mb...@apache.org> wrote:
>>>
>>>> Hi all,
>>>> I have a situation where I'm trying to get the BeanManager
>>>> associated with the parent CL of my TCCL. Using DS 1.1.0 and 1.0.3 I
>>>> note that BeanManagerProvider#getBeanManagerInfo(ClassLoader) blows
>>>> away the already-initialized BeanManagerInfo for my parent CL due to
>>>> the commit at [1]; however even with DS 1.0.2 (before this commit), I
>>>> don't see that any related code actually uses the parent ClassLoader
>>>> to retrieve a BeanManager for a given context ClassLoader
>>>> (BeanManagerProvider#getBeanManager() does call
>>>> #isParentBeanManagerBooted(), but the parent CL does not seem to be
>>>> consulted anywhere else). The simple way to address [1] is to check
>>>> whether there is already an info object stored for the parent before
>>>> initializing it. But what do we think is the correct behavior in
>>>> general? It would seem reasonable to say that for a given context, the
>>>> nearest BeanManager associated with the CCL or any ancestor CL would
>>>> be the appropriate result. What do others think?
>>>>
>>>> Matt
>>>>
>>>> [1]
>>>> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=35883fbd0d1a1c3dfc9023d67d4c5449e97fe6c2;hp=88fdfaee36b7639af46ca0f811e4bac9dd63197d
>>>>
Re: BeanManagerProvider for parent classloader
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Matt,
nearest is totally broken in OSGi, it is also in EE with ear (you can
desire an IllegalStateException from a webapp but a BeanManager from
the lib part). BeanManagerProvider should try CDI.current() if
availabe (by reflection to not depend on CDI 1.1) and use Weld/OWB api
if not and finally use the classloader if nothing worked (ie
ClassNotFoundException/NoClassDefFoundError).
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-11-07 17:30 GMT+00:00 Matt Benson <gu...@gmail.com>:
> Hi John,
> The concept is IMO broadly applicable to any situation using child
> ClassLoaders, but by way of providing a specific example, I have a
> process in which I'm firing up a standalone CDI container; then,
> parallel to that, I have a CRaSH shell running. I want visibility from
> my custom CRaSH commands to my BeanManager, but CRaSH invokes my
> commands using an intermediate ClassLoader. I suppose that in DS 1.0.2
> I could call BeanProvider#getBeanManager(), catch
> IllegalStateException, and walk up the CL hierarchy setting the CCL
> until I find the BeanManager, but from 1.0.3 forward your change will
> wipe out the parent BM info if the child CL has none. So this is the
> first order of business; next is the larger question of whether it is
> appropriate to do as I suggest: implement #getBeanMaangre() such that
> the "nearest" (in the sense of walking up the CL hierarcy) BeanManager
> associated with the CCL is returned. If not, why not?
>
> Thanks,
> Matt
>
> On Thu, Nov 6, 2014 at 6:54 PM, John D. Ament <jo...@gmail.com> wrote:
>> Matt,
>>
>> Can you provide some more info about your use case?
>>
>> This commit was supposed to be for some shrinkwrap specific issue.
>>
>> John
>>
>> On Thu, Nov 6, 2014 at 5:47 PM, Matt Benson <mb...@apache.org> wrote:
>>
>>> Hi all,
>>> I have a situation where I'm trying to get the BeanManager
>>> associated with the parent CL of my TCCL. Using DS 1.1.0 and 1.0.3 I
>>> note that BeanManagerProvider#getBeanManagerInfo(ClassLoader) blows
>>> away the already-initialized BeanManagerInfo for my parent CL due to
>>> the commit at [1]; however even with DS 1.0.2 (before this commit), I
>>> don't see that any related code actually uses the parent ClassLoader
>>> to retrieve a BeanManager for a given context ClassLoader
>>> (BeanManagerProvider#getBeanManager() does call
>>> #isParentBeanManagerBooted(), but the parent CL does not seem to be
>>> consulted anywhere else). The simple way to address [1] is to check
>>> whether there is already an info object stored for the parent before
>>> initializing it. But what do we think is the correct behavior in
>>> general? It would seem reasonable to say that for a given context, the
>>> nearest BeanManager associated with the CCL or any ancestor CL would
>>> be the appropriate result. What do others think?
>>>
>>> Matt
>>>
>>> [1]
>>> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=35883fbd0d1a1c3dfc9023d67d4c5449e97fe6c2;hp=88fdfaee36b7639af46ca0f811e4bac9dd63197d
>>>
Re: BeanManagerProvider for parent classloader
Posted by Matt Benson <gu...@gmail.com>.
Hi John,
The concept is IMO broadly applicable to any situation using child
ClassLoaders, but by way of providing a specific example, I have a
process in which I'm firing up a standalone CDI container; then,
parallel to that, I have a CRaSH shell running. I want visibility from
my custom CRaSH commands to my BeanManager, but CRaSH invokes my
commands using an intermediate ClassLoader. I suppose that in DS 1.0.2
I could call BeanProvider#getBeanManager(), catch
IllegalStateException, and walk up the CL hierarchy setting the CCL
until I find the BeanManager, but from 1.0.3 forward your change will
wipe out the parent BM info if the child CL has none. So this is the
first order of business; next is the larger question of whether it is
appropriate to do as I suggest: implement #getBeanMaangre() such that
the "nearest" (in the sense of walking up the CL hierarcy) BeanManager
associated with the CCL is returned. If not, why not?
Thanks,
Matt
On Thu, Nov 6, 2014 at 6:54 PM, John D. Ament <jo...@gmail.com> wrote:
> Matt,
>
> Can you provide some more info about your use case?
>
> This commit was supposed to be for some shrinkwrap specific issue.
>
> John
>
> On Thu, Nov 6, 2014 at 5:47 PM, Matt Benson <mb...@apache.org> wrote:
>
>> Hi all,
>> I have a situation where I'm trying to get the BeanManager
>> associated with the parent CL of my TCCL. Using DS 1.1.0 and 1.0.3 I
>> note that BeanManagerProvider#getBeanManagerInfo(ClassLoader) blows
>> away the already-initialized BeanManagerInfo for my parent CL due to
>> the commit at [1]; however even with DS 1.0.2 (before this commit), I
>> don't see that any related code actually uses the parent ClassLoader
>> to retrieve a BeanManager for a given context ClassLoader
>> (BeanManagerProvider#getBeanManager() does call
>> #isParentBeanManagerBooted(), but the parent CL does not seem to be
>> consulted anywhere else). The simple way to address [1] is to check
>> whether there is already an info object stored for the parent before
>> initializing it. But what do we think is the correct behavior in
>> general? It would seem reasonable to say that for a given context, the
>> nearest BeanManager associated with the CCL or any ancestor CL would
>> be the appropriate result. What do others think?
>>
>> Matt
>>
>> [1]
>> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=35883fbd0d1a1c3dfc9023d67d4c5449e97fe6c2;hp=88fdfaee36b7639af46ca0f811e4bac9dd63197d
>>
Re: BeanManagerProvider for parent classloader
Posted by Gerhard Petracek <ge...@gmail.com>.
@john:
>if< we really need workarounds for shrinkwarp, we need to create some
additional tests in the test-control module (or an own test-module with
tests based on test-control only) to test such cases without workaround/s.
regards,
gerhard
2014-11-07 1:54 GMT+01:00 John D. Ament <jo...@gmail.com>:
> Matt,
>
> Can you provide some more info about your use case?
>
> This commit was supposed to be for some shrinkwrap specific issue.
>
> John
>
> On Thu, Nov 6, 2014 at 5:47 PM, Matt Benson <mb...@apache.org> wrote:
>
> > Hi all,
> > I have a situation where I'm trying to get the BeanManager
> > associated with the parent CL of my TCCL. Using DS 1.1.0 and 1.0.3 I
> > note that BeanManagerProvider#getBeanManagerInfo(ClassLoader) blows
> > away the already-initialized BeanManagerInfo for my parent CL due to
> > the commit at [1]; however even with DS 1.0.2 (before this commit), I
> > don't see that any related code actually uses the parent ClassLoader
> > to retrieve a BeanManager for a given context ClassLoader
> > (BeanManagerProvider#getBeanManager() does call
> > #isParentBeanManagerBooted(), but the parent CL does not seem to be
> > consulted anywhere else). The simple way to address [1] is to check
> > whether there is already an info object stored for the parent before
> > initializing it. But what do we think is the correct behavior in
> > general? It would seem reasonable to say that for a given context, the
> > nearest BeanManager associated with the CCL or any ancestor CL would
> > be the appropriate result. What do others think?
> >
> > Matt
> >
> > [1]
> >
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=35883fbd0d1a1c3dfc9023d67d4c5449e97fe6c2;hp=88fdfaee36b7639af46ca0f811e4bac9dd63197d
> >
>
Re: BeanManagerProvider for parent classloader
Posted by "John D. Ament" <jo...@gmail.com>.
Matt,
Can you provide some more info about your use case?
This commit was supposed to be for some shrinkwrap specific issue.
John
On Thu, Nov 6, 2014 at 5:47 PM, Matt Benson <mb...@apache.org> wrote:
> Hi all,
> I have a situation where I'm trying to get the BeanManager
> associated with the parent CL of my TCCL. Using DS 1.1.0 and 1.0.3 I
> note that BeanManagerProvider#getBeanManagerInfo(ClassLoader) blows
> away the already-initialized BeanManagerInfo for my parent CL due to
> the commit at [1]; however even with DS 1.0.2 (before this commit), I
> don't see that any related code actually uses the parent ClassLoader
> to retrieve a BeanManager for a given context ClassLoader
> (BeanManagerProvider#getBeanManager() does call
> #isParentBeanManagerBooted(), but the parent CL does not seem to be
> consulted anywhere else). The simple way to address [1] is to check
> whether there is already an info object stored for the parent before
> initializing it. But what do we think is the correct behavior in
> general? It would seem reasonable to say that for a given context, the
> nearest BeanManager associated with the CCL or any ancestor CL would
> be the appropriate result. What do others think?
>
> Matt
>
> [1]
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=35883fbd0d1a1c3dfc9023d67d4c5449e97fe6c2;hp=88fdfaee36b7639af46ca0f811e4bac9dd63197d
>