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?
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... 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 >
