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