*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)
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.
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.
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.
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 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...
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]
>
>
