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

[Thomas Diesler]

I think SW should work as a utility, not as a service. The client needs 
to have the appropriate dependencies setup. If you don't want a direct 
dependency on the SW impl you could re-export that from a SW wrapper module

org.jboss.shrinkwrap
     +- org.jboss.shrinkwrap.api;export=true
     +- org.jboss.shrinkwrap.impl;export=true
     +- org.jboss.shrinkwrap.spi;export=true


Clients would than only need to have a dependency on org.jboss.shrinkwrap
The usage of TCCL in SW is questionable in the first place. SW should 
work as a utility in the class loading context of the caller IMHO.

Also, there seem to be two separate issues

#1 SW initialization
#2 SW usage

The obvious client for SW in AS are ARQ test cases, so perhaps #1 can be 
done as part of the Aquillian subsystem startup. For #2 to work, test 
modules would need to have a dependency on org.jboss.shrinkwrap

cheers
-thomas

On 12/10/2010 11:17 AM, 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

-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx