Some comments online... 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). >
So, isn't this the case where you could identify that the jar being processed is a OSGI bundle, and call a OSGI processor directly, instead of making the jar processor delegating ? > 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. > Maybe we need to extend the packageProcessor to influence more what type of resolution and loading mechanisms to be used > 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'll wait to see a patch to better comment on your proposal. > 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 > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
