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(a)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