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