Simon, I would like to retain two bundles and hence two separate classloaders for SPI and Runtime under OSGi. I will use a single classloader for SPI and Runtime outside of OSGi.
Thank you... Regards, Rajini On 10/23/07, Simon Nash <[EMAIL PROTECTED]> wrote: > > > Rajini Sivaram wrote: > > > Simon, > > > > Shall I work on the classloading changes with the extension classloader > as a > > child of Tuscany Runtime (rather than the SPI), and look at separating > the > > Runtime and SPI properly later? I would like to keep Core-SPI and > Runtime as > > two different bundles, so that when running under OSGi, the dependencies > > will be specified explicitly (making it slightly simpler to remove the > > dependencies later on). > > > The picture you posted in > > > http://cwiki.apache.org/confluence/download/attachments/68801/proposed-classloader.png > > for your initial implementation proposal has the extension classloader > as a child of the Tuscany runtime classloader, and the runtime classloader > as a child of the Tuscany SPI classloader. > > When running outside of the OSGi environment, I don't think it is worth > having separate classloaders for Tuscany runtime and Tuscany SPI in the > initial implementation, until we have resolved the separation issues. > If you want to keep these separate as OSGi bundles, and run them under > separate OSGi classloaders in the OSGi environment, I'm OK with that. > > Are you proposing that there would be separate classloaders for SPI and > runtime when running under OSGi, but only one classloader for both of > these when running outside OSGi? Or are you proposing that in both > cases there would be two separate classloaders? I'm sorry that I have > not quite understood what you are proposing here. > > > The alternative is to clean up the SPI first before working on the > > classloader changes. What do you think? > > > I think you should start on the new classloader structure now, as Ant > has said. The SPI cleanup is likely to be quite a lot of work, so it > makes more sense to do that as a second round. > > Simon > > > > > Thank you... > > > > Regards, > > > > Rajini > > > > > > On 10/23/07, Simon Nash <[EMAIL PROTECTED]> wrote: > > > >>This note is getting a bit long now. I added two comments inline > >>and cut out some of the previous discussion. > >> > >> Simon > >> > >>Rajini Sivaram wrote: > >> > >> > >>>Simon, > >>> > >>>Comments inline... > >>> > >>>(cut) > >>> > >>>>>maven module names > >>>>> > >>>>> 1. SCA API (sca-api) > >>>>> 2. Tuscany SPI (core-spi, assembly, contribution, policy, > interface, > >>>>> interface-java, interface-wsdl, databinding) > >>>>> > >>>> > >>>>Some of the above maven modules contain implementation code as well as > >>>>SPI code. For example, in the assembly module, Service.java is an SPI > >>>>and ServiceImpl.java is an implementation class. > >>> > >>> > >>> > >>>Yes, unfortunately many of these implementation classes are used > outside > >> > >>of > >> > >>>the SPI modules. At the moment the core-spi bundle that I use to run > >> > >>Tuscany > >> > >>>under OSGi is forced to export all the packages from these modules, > >> > >>rather > >> > >>>than just the SPI. eg. ComponentImpl from the assembly module along > with > >> > >>SPI > >> > >>>forms the base class of RuntimeComponentImpl in Runtime. > >> > >>ComponentTypeImpl > >> > >>>from the assembly module is used by many extensions. > >>> > >> > >>For impl classes that are intended as extension points, we do have an > >>approach used in some places where an empty SPI class extends the impl > >>class and other modules extend the SPI class. Perhaps we could change > >>all these places to use that approach. > >> > >> > >>>(cut) > >>> > >>>> > >> > http://cwiki.apache.org/confluence/download/attachments/68801/tuscany-binding-ws-axis2-dependencies.png > >> > >> > http://cwiki.apache.org/confluence/download/attachments/68801/tuscany-implementation-spring-dependencies.png > >> > >>>>>These dependency diagrams show that either the extension modules are > >>>>>dependent on the Tuscany Runtime or I have the wrong list of modules > >> > >>for > >> > >>>>>Core-SPI and Runtime. > >>>>> > >>>> > >>>>I looked at one of these dependencies. It's a helper class in > >>>>implementation-java-xml that looks like it should be an SPI. > >>> > >>> > >>> > >>>There may be many others as well. In particular, I am sure that all the > >>>domain/node related code are in the wrong place, and I will sort those > >> > >>out > >> > >>>later. > >>> > >> > >>We should go through all these uses and decide if they are correct. > >>If they are, we should move these impl classes to the SPI, or create new > >>SPI classes that provide the same functionality. > >> > >> Simon > >> > >> > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
