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

[David Bosschaert]

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.