@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 <[email protected]>: > 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 <[email protected]>: > > 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 > > <[email protected]> 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 <[email protected]>: > >>> 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 <[email protected]> > 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 <[email protected]> > 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 > >>>>> >
