Hello, Graham and I have been looking at supporting OSGi bundles as contributions in Tuscany. This is the packaging of SCA contributions as OSGi bundles where OSGi will bring modularity and versioning to SCA.
Resolution of artifacts in OSGi contribution bundles will be handled by an OSGi runtime (if an OSGi runtime is not present on the classpath, the bundle will be treated as a plain jar). This would mean that classes used in < implementation.java/> and interfaces etc. will be loaded using standard OSGi resolution mechanisms, enabling different versions of classes to be loaded into a domain (there is also better isolation because each bundle has its own classloader). Unfortunately in the current Tuscany implementation, there doesn't seem to be a neat way of plugging in support for OSGi contributions. While < implementation.osgi/> is a completely independent module, support for OSGi contributions would require changes to other processors. I would like to add a new module "modules/contribution-osgi" which provides all the code needed for supporting OSGi contribution bundles. But the code will have to be explicitly invoked from outside this module. OSGi bundles are jar files. Since there is only one processor for each contribution file type, the Jar processor will have to call OSGi bundle processor to do any special processing for OSGi bundles - the OSGi bundle processor installs the bundle into an OSGi runtime (starting a new runtime if necessary). Since class resolution for OSGi bundles should be done using OSGi resolution mechanisms rather than directly using a classloader, and there is only one resolver called by ExtensibleModelResolver for each model type, ClassReferenceModelResolver will need to call OSGiClassReferenceModelResolver to load the class using the OSGi bundle if the contribution is an OSGi bundle. The changes to JarContributionProcessor and ClassReferenceModelResolver are fairly minimal - in both cases they try to dynamically load the corresponding OSGi processor and call a method on it. All the OSGi specific code is in modules/contribution-osgi. A better solution would have been to allow multiple processors for each contribution file type and multiple resolvers for each model type, where they are called in some order until the processing is complete. But that would require more extensive changes to Tuscany. I would like your feedback on the approach to follow, and would also like to know if I should wait till 1.0 is released before submitting a patch. Thank you... Regards, Rajini