Jean-Sebastien Delfino wrote:
Rajini Sivaram wrote:
On 8/29/08, *Raymond Feng* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Great!
Worth to point out is that [1] can preprocess the 3rd party jars to
be OSGi bundles instead of on-the-fly conversion during runtime.
Based on the discussion in one of the other threads, I would also like
to point out that the manifest entries of Tuscany modules are also
modified by tuscany-maven-bundle-plugin to introduce versioning. So
for creating distributions, it will be good if you can use both
Tuscany modules and 3rd party jars generated by
tuscany-maven-bundle-plugin.
Here's what I'm going to try:
a) put the right versioning in the Tuscany modules when they are built,
to avoid having to post-process them;
b) derive the OSGi metadata from 3rd party jars on the fly from their
Maven metadata, to not require two copies of these JARs;
c) do (b) in a
org.eclipse.osgi.baseadaptor.hooks.BundleFileWrapperFactoryHook, to
avoid having to read/rewrite/read the whole JAR in memory like we
currently do.
With the nice improvements to the Equinox integration made by Raymond
the last few days, and a few more fixes that I just committed, I'm able
to get a simple end to end scenario working with Tuscany / Equinox.
One of the initial difficulties, if I understand correctly, was to
handle non-bundle 3rd party JARs. Here's how node-launcher-equinox
handles them now, and that seems to work quite nicely.
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
If people want to try it, the calculator-osgi sample is a (simplistic)
example that shows how to use the Equinox-based Tuscany launcher.
It would be nice to have another sample showing how to use SCA from an
Equinox RCP application as that's a scenario that users have talked
about on the Tuscany user list.
Obviously a lot more work is needed to get all of Tuscany working well
on Equinox with a good development / build / test experience but that
looks encouraging to me.
Hope this helps.
--
Jean-Sebastien
