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