[jboss-as7-dev] [Discuss] Making Shrinkwrap more module-classloader friendly

[Kabir Khan]

For all the other tests shrinkwrap is executed 'on the client', so the full classpath is available. The product is then deployed on the server and runs in the server with modular classloading. Aslak says that Arquillian will soon support multiple @Deployment methods so what ever you are doing will probably just be a temporaty workaround. So I think you have two choices:
-Either construct your extra archives on the server and set up the arquillian module to see the shrinkwrap module. But I think this might cause some problems since I think arquillian uses a service loader to load up things from META-INF/services which will not be visible from the arquillian service module (due to MODULES-55) unless you simply put the shrinkwrap jars into the arquillian service module
-Have what calls shrinkwrap to create the extra deployment jars execute 'on the client'. If I have understood you correctly you are doing this by using JMX notifications? So the way to do that would be to register a notification listener with the MBeanServerConnection on the client side, for example when starting up the server. You could perhaps configure that with a system property or a META-INF/services service.

On 10 Dec 2010, at 10:17, David Bosschaert wrote:

> Hi all,
> 
> I have been looking at getting Shrinkwrap to work in a module-based 
> environment, like OSGi and JBoss Modules. I ran into issues with this 
> basically because the interaction goes through the ShrinkWrap-API module 
> and some static methods in there while the implementation requires that 
> the ThreadContextClassLoader has visibility of Shrinkwrap-Impl module.
> 
> In a classloader setting where all the SW jars are visible to the same 
> classloader this works fine, but in a modules-based system these two 
> modules would be loaded by two different classloaders so the only way to 
> get the current approach work is to set the TCCL explicitly to the 
> classloader that loads the ShrinkWrap-Impl module, which is a little 
> awkward to do but also typically requires a dependency on a 
> ShrinkWrap-Impl class which is ugly (IMHO), e.g:
>   ClassLoader oldCL = Thread.currentThread().getContextClassLoader();
>   try {
>     Thread.currentThread().setContextClassLoader(
>       JavaArchiveImpl.class.getClassloader()); // The impl class
>     Archive a = ShrinkWrap.create(...);
>   } finally {
>     Thread.currentThread().setContextClassLoader(oldCL);
>   }
> 
> I can see two solutions to this.
> 
> 1. The nicest one (IMHO) would be to let the impl module register a 
> ShrinkWrap service (with MSC and/or OSGi) which handles all the TCCL 
> details. The nice thing is that the user doesn't need to get into any SW 
> implementation detail. Just use the service and it works - the API of 
> the service would be similar to the ShrinkWrap class that's there today 
> and defined in the API module. I guess the disadvantage would be that 
> you need to obtain the service instance from the service registry, so 
> you can't use a static API like ShrinkWrap.create().
> 
> 2. An alternative could be to add additional static ShrinkWrap.create() 
> (etc) methods that take a classloader as an argument. You would then 
> still need to get hold of that classloader somehow, but at least you're 
> freed of the TCCL setter wrapping code...
> 
> Thoughts anyone?
> 
> David
> 
> BTW more context can be found in 
> https://jira.jboss.org/browse/SHRINKWRAP-242 where I'm providing an 
> initial proposal for #1 above to work in OSGi.
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev