THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
The runtime must work in both OSGi and non-OSGI environments. I.e. we can't rely on the OSGi service registry for extensibility
The runtime must not be genberally generally environment specific. I.e. no buddy classloading
...
...
| No Format |
|---|
<plugin>
<groupId>org.apache.tuscany.maven.plugins</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>1.0.6</version>
<executions>
<execution>
<id>distribution-modules</id>
<phase>generate-resources</phase>
<goals>
<goal>generate-modules</goal>
</goals>
<configuration>
<targetDirectory>target/modules</targetDirectory>
<useDistributionName>${useDistributionName}</useDistributionName>
<generateAggregatedBundle>${generateAggregatedBundle}</generateAggregatedBundle>
<generateManifestJar>true</generateManifestJar>
<artifactManifests>
<artifactManifest>
<groupId>org.apache.ws.commons.axiom</groupId>
<artifactId>axiom-api</artifactId>
<version>1.2.8</version>
<manifestFile>${basedir}/manifests/axiom-api-1.2.8.MF</manifestFile>
</artifactManifest>
<artifactManifest>
<groupId>org.apache.woden</groupId>
<artifactId>woden-impl-dom</artifactId>
<version>1.0M8</version>
<manifestFile>${basedir}/manifests/woden-impl-dom-1.0M8.MF</manifestFile>
</artifactManifest>
<!--artifactManifest>
<groupId>org.apache.tuscany.sdo</groupId>
<artifactId>tuscany-sdo-api-r2.1</artifactId>
<version>1.1.1</version>
<manifestFile>${basedir}/manifests/tuscany-sdo-api-r2.1-1.1.1.MF</manifestFile>
</artifactManifest-->
<!-- artifactAggregations (below) is the right approach to solving the split
package between axis-kernel and axis2-transport-http however the Tuscany
runtime doesn't take any notice of it so using a fragment at the moment -->
<artifactManifest>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-kernel</artifactId>
<version>1.5.1</version>
<manifestFile>${basedir}/manifests/axis2-kernel-1.5.1.MF</manifestFile>
</artifactManifest>
<artifactManifest>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-transport-http</artifactId>
<version>1.5.1</version>
<manifestFile>${basedir}/manifests/axis2-transport-http-1.5.1.MF</manifestFile>
</artifactManifest>
<artifactManifest>
<groupId>org.apache.axis2</groupId>
<artifactId>*</artifactId>
<version>*</version>
</artifactManifest>
</artifactManifests>
<!--artifactAggregations>
<artifactAggregation>
<symbolicName>org.apache.tuscany.sca.axis2-kernel</symbolicName>
<version>1.5.1</version>
<artifactMembers>
<artifactMember>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-kernel</artifactId>
<version>1.5.1</version>
</artifactMember>
<artifactMember>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-transport-http</artifactId>
<version>1.5.1</version>
</artifactMember>
</artifactMembers>
</artifactAggregation>
</artifactAggregations-->
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>org.eclipse</groupId>
<artifactId>osgi</artifactId>
<version>3.3.0-v20070530</version>
</dependency>
</dependencies>
</plugin>
|
...
NodeFactory maintains a NodeProxy inner class that supports cross-classloader calls. The calling client api will have been loaded by the app classloader but the underlying node will have been loaded by a bundle classloader. We need to bridge that gap.
#Contribution Class Loading
When a contribution is read, containing an implementation.java element, a ClassReference is instantiated, which contains the name of the class. ClassReference instances are resolved by a ClassLoaderModelResolver, by virtue of the entry in [2]
The ClassLoaderModelResolver (CLMR) specializes java.net.URL.URLClassLoader and implements o.a.t.s....ModelResolver. Each contribution is associated with a single CLMR . On construction the CLMR is endowed with a set of URLs that allow it to find all classes in its contribution via the URLClassLoader behaviour.
The itest project import-export-tests has a class TestTestCase with method testOneNode which demonstrates a more complex scenario where a cross contribution import/export of a java package exists between the contributions. In this example a node is created using 2 composite URIs for contributions ... "../exports/target/classes", "../imports/target/classes". An imported class is resolved using the CLMR of the exporting contribution. The exporter's CLMR is made available to the importing CLMR by deployment [1] code which traverses all contributions, identifying cross contribution dependencies (see buildDependencies at [1]) and using the set of remaining contributions to resolve the import, potentially more than once.
[1] http://svn.apache.org/viewvc/tuscany/sca-java-2.x/trunk/modules/deployment/src/main/java/org/apache/tuscany/sca/deployment/impl/DeployerImpl.java?view=markup&pathrev=948564|http://svn.apache.org/viewvc/tuscany/sca-java-2.x/trunk/modules/deployment/src/main/java/org/apache/tuscany/sca/deployment/impl/DeployerImpl.java?view=markup&pathrev=948564]