...
- tuscany-extensibility-osgi: https://svn.apache.org/repos/asf/tuscany/java/sca/modules/extensibility-osgi (Based on Felix for testing)
- tuscany-extensibility-eclipse: https://svn.apache.org/repos/asf/tuscany/java/sca/modules/extensibility-equinox (based on Equinox)
...
- tuscany-node2-launcher-osgi: https://svn.apache.org/repos/asf/tuscany/java/sca/modules/node2-launcher-osgi
This special launcher will discover tuscany bundles and 3rd party jars on paths defined by TUSCANY_HOME and TUSCANY_PATH system properties/environment variables. It will start an embedded OSGi runtime (Felix, Equinox or other), install (or wrap plain jars into) bundles, and use the SCA Node/Domain APIs to create/launch SCA nodes or domain manager.
...
- tuscany-contribution-osgi: https://svn.apache.org/repos/asf/tuscany/java/sca/modules/contribution-osgi
OSGi bundles as SCA contributions (OSGi providing modularity for Java implementation types (e.g. implementation.osgi and implementation.java)).
...
- tuscany-implementation-osgi: https://svn.apache.org/repos/asf/tuscany/java/sca/modules/implementation-osgi
OSGi bundles as an implementation technology for SCA components (implementation.osgi). Here OSGi services and references are mapped to SCA services/references and can be integrated with other
implementation technologies (e.g. BPEL, POJO, Groovy, etc...) and invoked or can invoke over the various SCA bindings. This is business as usual for SCA, which is designed to enable the assembly of
heterogeneous implementation technologies.
Running environment
- JSE with embedded OSGi runtime such as Eclipse Equinox and Apache Felix
- Running inside Eclipse workspace
- Maven surefire plugin for testing
- External OSGi runtime such as Eclipse or Felix Shell
- Other environment such as JEE (Web Container, EJB container)
Different approaches to convert 3rd party jars into OSGi
Strategy | Options | Pros | Cons | Note |
---|---|---|---|---|
Build-time conversion | Using tools (such as maven-bundle-plugin) to convert plain jars into OSGi bundles |
|
| Maven Bundle Plugin: http://felix.apache.org/site/maven-bundle-plugin-bnd.html\\\\\\\\\\\\\\\\\\\\\\\\ Felix Commons: http://felix.apache.org/site/apache-felix-commons.html |
| Use already-converted 3rd party bundles from Spring DM, Felix Common or Eclipse Orbit |
| Not all 3rd party jars are available in OSGi bundles |
|
Runtime converstion | Before the jar is installed (BundleContext.installBundle()) |
|
|
|
| Add a hook to the OSGi runtime to wrap the jar (such as |
|
| Equinox Hooks: |
Hybrid conversion | Build-time will generate the META-INF/MANIFEST.MF as a side file |
|
|
|
Virtual Libary Bundle for 3rd party jars
1) The launcher looks for runtime JARs and class folders in a Tuscany distribution install or just the classpath entries used to start it.
2) Then it looks for OSGi Bundle-SymbolicName entries in their manifests to determine if they are OSGi bundles or just regular JARs.
3) It creates a single in-memory bundle for these regular JARs, in an Equinox BundleFileFactoryHook:
- export and import all their packages
- import * with a DynamicImport
- reference the JARs outside of the bundle in Bundle-classpath
That step is fast as it just writes a Manifest to a byte[] in memory, with no need to copy the JARs and re-package them, as the manifest
simply references their actual locations.
4) Bundle tuscany-extensibility-equinox contains a DynamicImport *, enabling ServiceDiscovery to access the 3rd party packages.
5) Instead of Thread.getContextClassLoader(), Tuscany code must use Class.forName() from modules that have the proper imports, and the
Tuscany ServiceDiscovery to discover META-INF/services.
The above seems to work well in the following environments:
- an installed distro, JARs and bundles are loaded from the distro
- Maven surefire, classes are loaded from the Maven repos
- an Eclipse project, classes are loaded from the project's classpath
Build a distribution with the OSGi bundle layout
tuscany-sca
...modules
......tuscany-module.jar
...lib
......3rd-party-non-osgi
.........META-INF/MANIFEST.MF
.........3rd-party-non-osgi.jar
......3rd-party-osgi.jar
Tuscany OSGi Integration
Enable Tuscany runtime with OSGi (Use OSGi under the cover for Tuscany runtime or work with existing OSGi environment such as Eclipse RCP)
Work Items | Status | |
Package Tuscany modules as OSGi bundles | Partially done. The following items remain:
| |
Package all of the 3rd party jars as an OSGi bundle | Partially done. The following items remain:
| |
Provide a SCA node launcher to run SCA application with OSGi-enabled Tuscany runtime | The launcher now works with SCA node.
| |
Support different bundle packaging and distribution schemes (jars and class folders, distribution and Eclipse workspace) | ||
Bring up the calculator sample with Equinox Node Launcher | Done |
|
Bring up the calculator RCP with Eclipse Equinox | Under bring-up | |
Use the Import/Export packages for Tuscany modules to enforce the SPI contracts, Refactor SPIs if necessary, Split a few modules into model and runtime | ||
Change how JDK factories are discovered and instantiated | Done for the core | |
Rationalize and clean up the SCA contribution classloading strategy |
| |
Convert samples and itests to use the OSGi-enabled Tuscany runtime |
|
OSGi bundles as SCA contributions
Work Items | Status |
Support packaging of SCA contributions as OSGi bundles |
|
Support the OSGi import/export as SCA contribution import/export |
|
Convert some samples or itests to use OSGi bundle as the SCA contributions |
|
Integrate SCA assembly with OSGi services
Work Items | Status |
First step: Define a set of scenarios to better understand the resulting programming model (OSGi + SCA) |
|
---|---|
|
|