@john: >if< we really need workarounds for shrinkwarp, we need to create some additional tests in the test-control module (or an own test-module with tests based on test-control only) to test such cases without workaround/s.
regards, gerhard 2014-11-07 1:54 GMT+01:00 John D. Ament <[email protected]>: > 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 > > >
