Please see my comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "Graham Charters" <[EMAIL PROTECTED]>
Sent: Tuesday, September 09, 2008 4:46 AM
To: <[email protected]>
Subject: Re: Tuscany / Equinox-OSGi integration, was: Creating distros for
OSGi-enabled Tuscany/SCA
Hi Sebastien,
I see from the design (and also the module name :-) ) that this work
is Equinox-specific and will not work in other OSGi runtimes. I think
it would be a shame to make this the only way to use an OSGi
implementation and I know Rajini worked very hard to ensure the osgi
runtime work she did also supported Apache Felix. Is the intention to
deprecate support for other OSGi implementations?
We use Equinox to get the idea working. It doesn't really prevent other OSGi
runtime from supporting the same design.
For Apache Felix, we can just slightly change the way how we create the
virtual bundle for 3rd party jars (it might be a
bit more expensive as Felix doesn't support "external" classpaths for the
"Bundle-ClassPath" entry and we can create a folder-based
bundle that include the 3rd party jars).
BTW, it might be worth trying to propose the Hook ideas to Felix to support
various Bundle formats, Bundle wrapping and ClassLoading :-).
Regarding Class.forName and TCCL, you might find the following blog
posts from BJ Hargrave interesting. I'm not sure whether these
circumstances are likely to arise in Tuscany, but it's something to be
aware of:
http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html
http://blog.bjhargrave.com/2007/07/contextfinder-in-eclipse-is-broken.html
Regarding META-INF/services, is there any reason why we couldn't use
the OSGi service registry to register and discover these services?
The more we use of standard OSGi capabilities, the more we can perhaps
leverage standard or third-party tools for things like configuration,
administration, analysis, etc...
One reason is that we want to keep the support to run Tuscany in an
environment without OSGi.
Regards, Graham.
2008/9/9 Jean-Sebastien Delfino <[EMAIL PROTECTED]>:
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
