This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • Classloading
Skip to end of metadata
Go to start of metadata

The Nature of the Tuscany Runtime

The Tuscany runtime comprises a set of core runtime classes that in turn load extensions to provide SCA functionality. This combination of core and extension classes is used to process contributions and load and run composite applications.

The classloading strategy applied to core and extension classes (runtime classloading) differs from that applied to load application artefacts from contributions. Application artefacts are presented in a set of related contributions and classloading must operate in this context (contribution classloading)

Extensions may also have a direct impact on classloading, for example, the use of OSGi to either bundle Tuscany runtime classes or to provide a component implementation implies a different approach to classloading based on OSGi bundles and the relationships defined between bundles.

Runtime Classloading

The classloader used to load the Tuscany runtime itself. It should be able to
locate all Tuscany jar files and all its dependent jar files (eg. axis2).


Tuscany runtime classloader should find Tuscany and all its dependencies (essentially tuscany-sca-manifest.jar).

To enable third party libraries to see Tuscany classes the 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. Not desireable but apparently unavoidable.

It should be usable in a number of different hosting environments

Handle modularity, for example, here is a structure that Rajini investigated.

1. SCA API (sca-api)
2. Tuscany SPI (core-spi, assembly, contribution, policy, interface, etc.)
3. Tuscany Runtime ( assembly-xml, assembly-xsd,etc.)
4. Tuscany Extensions (binding-. implementation-, host-*,
databinding-*, contribution-osgi)
5. 3rd Party Libraries (Axis2 etc)

Contributions are loaded separately

Command Line

For command line operation the core and extension Tuscany classes are treated as user-defined classes and must be provided directly on the classpath, for example,

Java -classpath tuscanydistribution/lib/Tuscany-sca-manifest.jar ...

At startup the hosting environment will start the core runtime and load any extension classes that are found using the classpath based classloader.


Webapp operation is similar principle but the location of the Tuscany jars affect which classloader loads then. For example, the jar could be deployed with each web application or could be deployed into a directory common to all web applications.


The current OSGi runtime bundling (itest/osgi-tuscany) splits Tuscany into the aforementioned bundles.

1. SCA API (sca-api)
2. Tuscany SPI (core-spi, assembly, contribution, policy, interface, etc.)
3. Tuscany Runtime ( assembly-xml, assembly-xsd,etc.)
4. Tuscany Extensions (binding-. implementation-, host-*,
databinding-*, contribution-osgi)
5. 3rd Party Libraries (Axis2 etc)

The felix runtime is started, these bundles are loaded using Felix APIs and the Tuscany runtime is started with the following code (org\apache\tuscany\sca\test\util\TuscanyLoader)

        if (tuscanyRuntimeBundle != null) {
            // Tuscany runtime is started on a different thread when previously cached bundle is used.
            // Set this thread's TCCL to the one used by the runtime.
            try {
                Class<?> runtimeClass = tuscanyRuntimeBundle.loadClass("");
                Method getRuntimeMethod = runtimeClass.getMethod("findRuntime");
                Object runtime = getRuntimeMethod.invoke(runtimeClass);
                Method getTCCLMethod = runtimeClass.getMethod("getContextClassLoader");
                ClassLoader runtimeTCCL = (ClassLoader) getTCCLMethod.invoke(runtime);
            } catch (Throwable e) {

The classloading then relies on the OSGI classloader structure to resolve references across bundles.

What are the issues here now?

Contribution Classloading

Application artifacts such as .composite, .java. and .wsdl files are provided in one or more related contributions. Consider the following;



Where compositeA.composite is a follows;

<composite ...>
    <component name="ComponentA">
        < class="implementation.ComponentA"/>

    <component name="SubtractServiceComponent">
        < class="implementation.ComponentB"/>

Contribution processing reads each contribution into an in-memory artefact model during a read phase and resolves the relationships between artefacts during a subsequent resolve phase.

The model resolved classes are closely associated with classloading as to resolve a java artefact a class must be loaded.


Classloader Visibility - restricted to the transitive closure of all of the classes from the contribution import/ dependency graph + anything on the runtime classpath

One classloader per contribution? With access to all classloaders from contributions that it imports from.

Cycles in imports/exports should be detected (general resolution requirement)

Handle packages split across multiple contributions

Must equally support explicit resolution and automatic triggering from the VM

Use contributions without providing a classloader

Pluggability of classloader strategies

Notes on Proposed Approach

The runtime is not quite like this yet but this is what appears to be favoured from the various mail list discussions.

Model Resolution
For each artefact in contribution
Find a processor for the artefact type to resolve the artefact
At appropriate points call the model resolvers., e.g. resolver
ClassReferenceModelResolver is constructed with a reference to the contribution.

Hence for classloading initiated by Tuscany

ExtensibleModelResolverA->ContributionClassLoaderA(implements ModelResolver>->ContributionClassLoaderB(implements ModelResolver)

For classloading initiated by the application


Issues with the current code

There is currently a separate resolver and contribution class loader hierarchy but there is a proposal to join them together by having the java resolvers extend classloader.

Listeners, Resolvers and ContributionClassloader are involved in processing imports/ in some way which could be simplified.

ContribtutionListeners -  Set up contribution processing based on events
-	sets import model resolver to model resolver from contribution with export
-	sets import model resolver to model resolver from contribution with export
-	sets import model resolver to JavaImportModelResolver
    OSGiClassReferenceModelResolver (delegated to for bundle contributions)


These notes are mainly distilled from the following discussions

  • No labels