Simon, Comments inline...
On 10/22/07, Simon Nash <[EMAIL PROTECTED]> wrote: > > Thanks for all your work on progressing this. Comments inline. > > Simon > > Rajini Sivaram wrote: > > > *An overview of the proposed classloader design for Tuscany* > > > > Thank you for all your emails. Based on your feedback, I would like to > > propose a new classloader architecture for Tuscany. I have created new > > bundles in OSGi to reflect the kind of classloader-based isolation that > we > > may like to have, and if acceptable, I will add support to provide this > > without OSGi. > > > > Simon didn't like the word "modules" being used to describe the level of > > granularity for classloaders since that clashes with maven "modules" > which > > are more fine-grained. So I think in spite of the confusion that it may > > create, I will use "bundle" to refer to a list of modules that we want > to > > treat as a collection, where each bundle can have an associated > classloader. > > When running under OSGi, each "bundle" will correspond to one OSGi > bundle. > > > > We have the following bundles in Tuscany - the names in brackets refer > to > > 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. > > 3. Tuscany Runtime ( assembly-xml, assembly-xsd, contribution-impl, > > contribution-java, contribution-namespace, core, > > core-databinding, definitions, domain, > > domain-api, domain-impl, extension-helper, host-embedded, > > interface-java-xml, interface-wsdl-xml, > > java2wsdl, node, node-impl, osgi-runtime, policy-security, > > policy-xml, topology, topology-xml, wsdl2java, > > binding-sca, binding-sca-xml) > > 4. Tuscany Extensions (binding-*. implementation-*, host-*, > > databinding-*, contribution-osgi) > > 5. 3rd Party Libraries (Axis2 etc) > > 6. Application contributions > > > > > > By default, Tuscany will continue to run using a single classloader with > all > > required classes on the CLASSPATH. But it will also be possible to run > > Tuscany using five different classloaders for the five bundles. > Applications > > will always be run using separate classloaders, created by Tuscany. All > > existing samples and itests will continue to run using a single > classloader. > > But a new set of tests will be added for classloading which checks if > > Tuscany runs with multiple classloaders and verifies that all the > isolation > > requirements are met. > > > There are 6 bundles listed above, but this paragraph refers to five > bundles. > Did you mean to say six bundles here? Sorry, I meant 5 Tuscany bundles plus n application bundles. > Based on the notes, I think the desired classloading hierarchy for Tuscany > > is: > > > > > > > http://cwiki.apache.org/confluence/download/attachments/68801/desired-classloader.png > > > > The solid lines show parent-child relationship used for standard Java > > classloader delegation, providing static visibility. The dotted lines > show > > dependencies which are more targetted, and preferably avoided where > > possible. > > > > 3rd party code could potentially be split across multiple classloaders, > and > > these could be inserted anywhere in the hierarchy as long as SPI, > Runtime > > and Extensions can see the code they require. Tuscany modules will > continue > > to expect to see these dependencies from the classloader of the module > (from > > Tuscany runtime and Tuscany extensions). > > > > I have generated a few dependency diagrams for Tuscany modules, and > these > > dont exactly match the requirements that have been specified in the > notes. > > In particular, it seems to me that the line between Tuscany-SPI and > Tuscany > > Runtime is rather blurred (or I haven't understood the separation > > correctly). > > > > The dependency diagram for the whole of Tuscany/modules is : > > > > > > > http://cwiki.apache.org/confluence/download/attachments/68801/tuscany-dependencies.png > > > > The modules are listed in four columns, the first one is SCA-API and > Tuscany > > SPI, where the dependencies coming in from the right are expected, and > there > > are no dependencies going to the right. The second column is Tuscany > > Runtime, and the third and fourth ones show the extensions. Sorry, the > > diagram is a bit blurred, but if you download it and zoom in, you can > see > > the arrows going into the runtime column from the extensions. And there > are > > many of them. > > > This seems be the opposite case of my comment above. Some of the runtime > code is exposing classes that are used as "pseudo-SPIs" by other code. > > One of the huge benefits of this exercise is that it is exposing these > cases so that we can look at them and decide what we should do about them. > > > To give a better idea of the kind of dependencies in Tuscany, I have > created > > two separate dependency diagrams for binding-ws-axis2 and > > implementation-spring: > > > > > 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. > > Based on the dependencies that we have today, I would like to propose > the > > following classloader hierarchy for the initial implementation: > > > > > http://cwiki.apache.org/confluence/download/attachments/68801/proposed-classloader.png > > > I don't think there's much value in splitting Tuscany-SPI from > Tuscany-Runtime > until we are clearer about which parts of the maven modules are true SPI > and which parts are runtime implementation. Other than that I agree with > the picture. Agreed. > > I am assuming that Tuscany Extension modules will not be run under > multiple > > classloaders, except using OSGi (where cross-module dependencies can be > > specified at the package level). The dependencies across extension > modules > > are actually not bad at all, they form clusters (java based > > implementations at the top of the third column, webservices ones at the > > bottom of the third column in the main dependency diagram), making it > > possible to create separate extension bundles if we need to later on. > > Thank you... > > > Sounds like the right approach. > > Simon > > > Regards, > > > > Rajini > > > > > > On 10/19/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > >>I wanted to summarize this thread as it has been pretty popular - I > >>guess we all know what a classloader is and are happy to talk about it > >>:) - but I am getting lost in the various exchanges. > >> > >>Could anybody please help provide 2 or 3 short sentences summarizing the > >>first 2 or 3 steps that are going to be implemented? > >> > >>Thanks... > >> > >>Simon Laws wrote: > >> > >>>On 10/18/07, Mike Edwards <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>>>Folks, > >>>> > >>>>Comments inline > >>>> > >>>>Simon Laws wrote: > >>>> > >>>> > >>>>>Hi Rajini > >>>>> > >>>>>Re. 4 on Simon's list. Maybe it is useful to more clearly distinguish > >>>>>between those Tuscany modules that are expect to be loaded > statically, > >>>>>assembly, core, etc and those that expected to be loaded dynamically, > >>>>>binding.?, implementation.? etc. I find the term "module" a little > >>>>>unsatisfactory. Raymond, in his diagram, used Tuscany core and > Tuscany > >>>>>extension and in a previous post used Tuscany runtime and Tuscany > >>>>>extension. I prefer the latter pair just because we have a maven > >> > >>module > >> > >>>>>called core. > >>>>> > >>>> > >>>>+1 > >>>> > >>>> > >>>> > >>>>>This leads to a 4a and 4b based on Raymond's post/diagram > >>>>> > >>>>>4a Tuscany extension module code shouldn't be able to see other > >>>>> > >>>> > >>>>extension > >>>> > >>>> > >>>>>modules (not sure what the dotted line on the diagram implies but I > >>>>> > >>>> > >>>>expect > >>>> > >>>> > >>>>>that it's to do with modules like binding-ws-axis2 and binding-ws > >>>>>interacting) or application code or Tuscany runtime code other than > >> > >>via > >> > >>>>the > >>>> > >>>> > >>>>>SPI. > >>>>> > >>>> > >>>>Hmm, first, this ain't the case today and it will need some thought. > >>>> > >>>>The "Java" extensions do share code and it would be crazy for them not > >>>>to share the code. So, Spring uses stuff out of the base Java > >> > >>extension > >> > >>>>- and I am sure that other "Java" type extensions would want to do the > >>>>same. > >>>> > >>>>In an OSGi world, it would be fine to express the dependency in a > >> > >>simple > >> > >>>>way. For non-OSGi I'm not sure of the best route. > >>>> > >>>>I suspect that other extension types may want to share stuff as well. > >>>> > >>> > >>> > >>>Agreed. Hence I pointed out the relationship between binding-ws-axis2 > >> > >>and > >> > >>>binding-ws. There are loose groups of software spread across multiple > >> > >>maven > >> > >>>modules that just represent modularization of the software for clarity > >> > >>and > >> > >>>reuse purposes. Then there are the modules that are intended to be > >> > >>loaded as > >> > >>>extensions. Not all maven modules are create equal :-) The non OSGi > >> > >>world is > >> > >>>managed by the dependencies that appear in out maven pom files. Without > >> > >>this > >> > >>>dependency tree you just have to know that, for example, binding-ws has > >> > >>to > >> > >>>be on the classpath when you also include binding-ws-xml which is in > >> > >>turn a > >> > >>>dependency of binding-ws-axis2. Nothing too unusual there until you > >> > >>start > >> > >>>talking about having separate class loaders for each extension as has > >> > >>been > >> > >>>discussed previously in this thread. You really need to understand what > >> > >>an > >> > >>>extension is, i.e. it is unlikely to be a single maven module. > >>> > >>> > >>> > >>> > >>>>4b Tuscany runtime code shouldn't be able to see Tuscany extension > code > >> > >>or > >> > >>>>>application code. > >>>>> > >>>> > >>>>That sounds a bit odd. Perhaps I've not got the right end of the > >> > >>stick, > >> > >>>>but the some code - either core and or extensions has to get very > >>>>intimate with the application code. Introspection, instantiation, > >>>>injection - all has to be done either by core code or extension code. > >>>> > >>>>Perhaps I've not understood the separation you're looking for? > >>>> > >>> > >>> > >>>This should say "shouldn't be able to statically see..". I had imagined > >> > >>that > >> > >>>these are all of the implementation modules that sit behind the SPI > >>> > >>> > >>> > >>>>>Then, from reading your comments, we have to be clearer about what > the > >>>>> > >>>> > >>>>SPI > >>>> > >>>> > >>>>>is providing an interface to because it current includes interfaces > to > >>>>> > >>>> > >>>>the > >>>> > >>>> > >>>>>underlying runtime modules but also the host-embedded classes which > >>>>> > >>>> > >>>>strike > >>>> > >>>> > >>>>>me as being more API than SPI. We are reorganizing the domain/node > >>>>>interfaces at the moment so hopefully we can clear this last point up > >> > >>as > >> > >>>>>part of that. > >>>>> > >>>>>Regards > >>>>> > >>>>>Simon > >>>>> > >>>>> > >>>> > >>>>--------------------------------------------------------------------- > >>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >>>> > >>> > >>> > >> > >>-- > >>Jean-Sebastien > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thank you... Regards, Rajini
