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