If you can get a patch together that you're comfortable with by tomorrow then I'd say go for it. But we plan to take the 1.0 branch on Friday so if its much later then then it probably will have to miss 1.0.
...ant On 9/12/07, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > > 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 >
