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
...
...
The tuscany-extensibility-equinox bundle also has a dynamic import
| Code Block |
|---|
DynamicImport-Package: org.apache.tuscany.sca.extensibility.equinox, |
...
javax.transaction;version="1.1", |
...
javax.transaction.xa;version="1.1", |
Which allows it to generally load any classes in the runtime
Split Packages - JSE
We don't take any special account of this in JSE 
We avoid split packages across the JARs we create as it messes OSGi up.
Split Packages - OSGI
We avoid split packages across the bundles we create
They may exist in third party bundles (or jars that we turn into bundles) so we need a way round it
The Tuscany eclipse plugin is used to generate bundles manifest for jars which don't have them. This is done automatically with all packages exported and the resulting bundle it in the distribution modules directory in the following form
| Code Block |
|---|
bundle-name
META-INF
MANIFEST.MF
bundle-name.jar
|
The MANIFEST.MF is generated and will have a bundle classpath pointing to the jar (which doesn't itself have a manifest
The runtime (node-launcher-equinox) has code to load these directories as bundles.
There is a way of overriding these automatically generated bundles so that split packages (or any other manifest problems) can be worked round. Generate the manifest manually and put it in
| Code Block |
|---|
distribution/all/manifests
|
Update distribution/pom.xml to configure the Tuscany version of the maven bundle plugin to apply this manifest
| 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>
|
You'll note that there is an artifact aggregation element that doesn't work at the moment. This should aggregate the two bundles together so that a split package isn't an issue. As this doesn't work at the moment another way to achieve the same result is to make one package a fragement of the other by configuring separate manifests manually.
NOTE!!!!! you also need to put the manually generated manifest in node-launcher-equinox\src\main\resources\org\apache\tuscany\sca\node\equinox\launcher otherwise you'll spend a lot of time trying to get this to work. (we need to fix this!)
Third-party libraries - JSE
...
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]