Ant, Luciano, Thank you for your comments.
I will try to submit a patch later today. I am trying to move the installation of the bundle to a contribution listener in the OSGi-specific code so that the changes to JarContributionProcessor wont be required. If I can get that to work, the only change outside the OSGi-specific projects would be in ClassReferenceModelResolver. Thank you... Regards, Rajini On 9/12/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > 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] > >
