Page Comparison

Contribution Imports and Exports

Embedding artifacts and libraries in the META-INF/lib directory of a contribution is simple but lacks the flexibility required by many applications. For example, several applications may need to share the same WSDL document or library. Fabric3 supports three forms of sharing:

• Java package sharing
• XML resource sharingJava package sharing
• Java contribution sharing

In all cases, a resource (or set of resources) are exported by one contribution and *imported*by another. Imports and exports are specified in the contribution manifest file.

XML Resource Sharing

XML resources are shared by exporting and importing their qualified name (qname). For example, assume a set of portTypes in a WSDL document need to be shared among several contributions. The contribution manifest file contining the WSDL document will export the document's qname using the <export> element:

...

<contribution xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912">
   <export name={"urn:somenamespace:1.0"/>
</contribution>

Contributions that require access to the portTypes defined in the urn:somenamespace:1.0 namespace may import it using the <import> element in their manifest:

...

<contribution xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912">
   <import name="urn:somenamespace:1.0"/>
</contribution>

When the qname is imported, Fabric3 will ensure the portTypes may be referenced by artifacts such as composite files contained in the importing contribution.

Java Package Sharing

Java resources (i.e. classes) are shared by exporting and importing their packages. Java package sharing in Fabric3 is based on OSGi, so if you are familiar with that technology, you already understand Fabric3's approach and capabilities. Classes contained in Java packages are made available to other contributions using the <export.java> element in the contribution manifest:

...

The previous examples make classes in the com.foo.bar package available to the importing contribution.

Fabric3 and OSGi Classloading

Fabric3 loads contributions in separate classloaders using OSGi. This provides contribution isolation (Java classes and artifacts are not visibile to other contributions unless they are exported, thereby reducing the potential for conflicts) and allows versioning. Further, each contribution is associated a classloader space. When a package is imported, a "wire" is created between the importing and exporting contribution. This wire is used by the importing contribution's classloader to load classes belonging to the package using the exporting conribution's classloader. A classloader space therefore consists of the contribution classloader and the classloaders it is wired to via a set of import/export pairs.

...

<import.java package="org.foo.bar" version="1.0.0" required="false"/>

XML Resource Sharing

XML resources are shared by exporting and importing their qualified name (qname). For example, assume a set of portTypes in a WSDL document need to be shared among several contributions. The contribution manifest file contining the WSDL document will export the document's qname using the <export> element:

<contribution xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912">
   <export name={"urn:somenamespace:1.0"/>
</contribution>

Contributions that require access to the portTypes defined in the urn:somenamespace:1.0 namespace may import it using the <import> element in their manifest:

<contribution xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912">
   <import name="urn:somenamespace:1.0"/>
</contribution>

When the qname is imported, Fabric3 will ensure the portTypes may be referenced by artifacts such as composite files contained in the importing contribution.

Contribution Imports and Exports

...