On 10/11/07, Rajini Sivaram <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> Tuscany's use of classloaders doesn't seem to be well-defined, even though
> the concept of a runtime classLoader and contribution classloaders should
> have made it easy to isolate these namespaces. All Tuscany samples and
> tests
> are currently run with a single application classloader containing
> absolutely everything including Tuscany, all the jar files Tuscany
> requires
> and all the Java contribution jars/folders.
>
> I am running Tuscany as a bundle inside an OSGi runtime, and came across
> some issues with classloading when multiple classloaders are used.
> Even though these can be fixed for OSGi without changes to the non-OSGi
> related code in Tuscany, it will be good to fix these properly in Tuscany
> since these issues affect anyone who wants to use Tuscany without a great
> big classloader hierarchy containing Tuscany, all its dependencies and all
> contributions.
> Here is my understanding of classloaders used by Tuscany:
>
> 1) Tuscany Runtime classloader
> This is the classloader used to load Tuscany itself. It should be able to
> locate all Tuscany jar files and all its dependent jar files (eg. axis2).
> There are many locations in Tuscany which explicitly read the
> classloader used to load one Tuscany class in order to load another
> Tuscany
> class. For example, many of the files defined in META-INF/services and
> the
> classes they refer to are loaded in this way.
>
> 2) Contribution classloaders
> Referred to as application classloader in the DefaultSCADomain, a separate
> classloader can (in theory) be used to refer to the contributions - in the
> case of DefaultSCADomain, this is a single classloader associated with a
> single contribution.
>
> There is currently no concept of a contribution classloader for each
> contribution (except for OSGi contributions), and all resolution of
> classes
> from contributions is done using a single classloader. This does not
> reflect
> the SCA specification, which requires contribution imports/exports to be
> explicitly specified - requiring multiple classloaders to enforce the
> import/export definition during class resolution.
>
> 3) Thread context classloader
> Tuscany sets thread context classloader only in one class -
> HotUpdatableSCADomain (which sets Context classloader to a single
> URLClassLoader containing all the contribution jar files, with the
> original
> context classloader as parent).
>
> Tuscany uses the thread context classloader in around 30 different
> locations. Around half of these have FIXMEs saying that the classloader
> should be passed in. Many of these uses of the context classloader are
> trying to obtain the runtime classloader. And at least one is trying to
> obtain the contribution classloader.
>
> Many libraries which are used by Tuscany require the thread context
> classloader to be able to load the library classes. Most of these use the
> factory pattern and dynamically load implementation classes to create
> instances using the context classloader (eg.
> javax.xml.datatype.DataTypeFactory.newInstance()). The context classloader
> should in these cases to be able to find classes in Tuscany's dependent
> jar
> files, and hence the classloader used to load these dependent jars should
> be
> on the thread context classloader hierarchy.
>
> Axis2 libraries (and possibly others) use the thread context classloader
> to
> load Tuscany classes. Axis2 needs to find Tuscany's message receivers
>
> org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSyncMessageReceiverand
> org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInMessageReceiver, and
> these are loaded by Axis2 using the context classloader. So Tuscany
> runtimeClassloader should be on the thread context classloader hierarchy.
>
> 4) Java Application classloader
> Tuscany doesn't directly rely on the application classloader (the
> classloader corresponding to CLASSPATH). But since Tuscany doesn't set the
> thread context classloader, for any application that doesn't explicitly
> set
> thread context classloader, there is an indirect dependency on the
> application classloader, and hence CLASSPATH should contain everything
> required by the thread context classloader (which at the moment includes
> the
> entire world).
>
> So we have the following requirements on classloaders:
>
>
> 1. Tuscany runtime classloader should find Tuscany and all its
> dependencies (essentially tuscany-sca-manifest.jar).
> 2. Contributions are not required to be on the classpath, nor do they
> have to be visible to the thread context classloader. One classloader
> per
> contribution is required to enforce SCA contribution import/export
> semantics.
> 3. Thread context classloader should be able to see Tuscany's
> dependencies and also Tuscany classes - so this can be the same as (or
> a
> child of) the Tuscany runtime classloader.
> 4. Any code using Tuscany should either have Tuscany runtime and its
> dependencies on the CLASSPATH, or should set the thread context
> classloader
> for its threads using Tuscany. All Tuscany tests rely on CLASSPATH,
> while
> Tuscany can be run inside OSGi without CLASSPATH, by setting the
> context
> classloader.
>
>
> I would like to propose the following fixes to Tuscany classloading (my
> aim
> is to implement neater isolation without too much impact on the code):
>
> 1) Fix contribution classloading to enforce SCA contribution specification
> by using one classloader per contribution. Remove the requirement for
> contributions to be present in the classpath - Tuscany runtime
> classloader,
> thread context classloader and the application classloader should not be
> required to see the contribution classes.
>
> 2) Remove unnecessary usages of thread context classloader in Tuscany
> where
> the classloader that is required is the Tuscany Runtime classloader. It
> should be possible in many cases to determine the classloader directly
> without having to pass classloaders around. This is already done in some
> places, so this is just making the code consistent.
>
> 3) There are many uses of the thread context classloader where it is not
> very clear which classloader is actually required. I would suggest that as
> far as possible, Tuscany should avoid using the thread context
> classloader,
> and in places where it cannot be avoided without major changes, the code
> should be commented to show which classloader is required.
> As an example (the FIXME is from the existing code)
>
> *public JAXBElement<?> create(ElementInfo element, TransformationContext
> context) {*
> * .....*
> * ClassLoader classLoader = context != null ? context.getClassLoader()
> :
> null;*
> * if (classLoader == null) {*
> * //FIXME Understand why we need this, the classloader should be
> passed in*
> * classLoader = Thread.currentThread().getContextClassLoader();*
> * }*
> * Class<?> factoryClass = Class.forName(factoryClassName, true,
> classLoader);*
> * ....*
> *}*
>
> Given that Tuscany and its dependencies need to be visible from the thread
> context classloader anyway because other libraries need them there, this
> change is to merely to clean up Tuscany classloading and provide more
> clarity. It does not aim to remove the external dependencies on the thread
> context classloader.
>
> 4) It will be good to ensure that all uses of the Tuscany runtime
> classloader (eg. to load META-INF/services) continue to work even if each
> Tuscany module was loaded by a different classloader (ie, Tuscany runtime
> classloader is a hierarchy of module classloaders rather than a single
> one).
> This is not strictly necessary at the moment, but it is necessary if we
> want
> to package Tuscany modules as separate OSGi bundles.
>
> 5) Document Tuscany's requirements on classloaders (CLASSPATH and thread
> context classloader).
>
>
> I would appreciate your feedback, both regarding whether there is better
> way
> to fix this, and on areas which I have missed out or
> misunderstood. I will be happy to provide a patch if this is an acceptable
> solution.
>
>
>
>
> Thank you...
>
> Regards,
>
> Rajini
>
That all sounds good to me, i've also struggled with classloaders in the
past, it is a bit hotchpotch at the moment so if you want to have a go at
cleaning things up i think that would be wonderful.
If you were to just submit one big patch that tries to fix it all in one go
that may get bogged down in discussion about approaches, so the smaller bits
you can break this down into with a few smaller discrete patches thats
better. Don't worry to much if you can't though, one big patch is fine if
thats what it takes.
...ant
