Hi, Mike.
You can use the following method to tweak the TCCL.
org.apache.tuscany.sca.extensibility.ClassLoaderContext.setContextClassLoader(ClassLoader,
ServiceDiscovery, Class<?>...);
For example, if you need to give the TCCL access to service provider
javax.persistence.spi.PersistenceProvider in addition to the current class,
write:
ClassLoaderContext.setContextClassLoader(getClass().getClassLoader(),
serviceDiscovery, PersistenceProvider.class);
Underneath, ServiceDiscovery discovers the impl class for
PersistenceProvider and adds its classloader to TCCL.
Thanks,
Raymond
--------------------------------------------------
From: "Mike Edwards" <[email protected]>
Sent: Friday, January 29, 2010 7:35 AM
To: "dev" <[email protected]>
Subject: The right way to use ClassLoaderContext ?
Folks,
I'd appreciate some assistance from anyone who understands the
ClassLoaderContext class.
The situation concerns the implementation-bpel-runtime module and in
particular the class BPELImplementationProvider and its start() method.
This method needs to set up an appropriate TCCL for the ODE BPEL runtime
code that gets invoked from this class, to deal with classloading when
running under OSGi.
In particular, there are some "old style" META-INF/services to deal with,
plus some JPA code that also does class loading across bundle boundaries.
Basically, there are 2 needs:
1) TCCL needs to access the Provider class for the Persistence API
- this needs to be org.apache.openjpa.persistence.PersistenceProviderImpl
contained in the openjpa_1.2.1 package
- this is a classic META-INF/services style of service, using
"javax.persistence.spi.PersistenceProvider" as its key
2) TCCL needs to access the ODE JPA DAO implementation classes, loaded by
the OpenJPA code, which is accessed through a search for a
META-INF/persistence.xml file, contained in the ode-dao-jpa_1.3.2.jar
bundle
The current code, which does work correctly, is this rather ugly stuff:
ClassLoader tccl =
ClassLoaderContext.setContextClassLoader(EmbeddedODEServer.class.getClassLoader(),
PersistenceProviderImpl.class.getClassLoader(),
ProcessDAOImpl.class.getClassLoader() );
The problem with this is the explicit dependence on
PersistenceProviderImpl and ProcessDAOImpl classes.
Is there some better alternative that we could use based on the use of
names only rather than classes?
I can see that there might be for the Persistence provider, but how to
handle the JPA "implementation" classes?
Yours, Mike.
