Sebastien,
Comments inline.
On 10/22/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> I have two questions.
>
> [snip]
> Rajini Sivaram wrote:
> > 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
> >
> >
> Do you know give the approx size of each bundle?
The bundles that I have at the moment are:
1. org.apache.tuscany.sca.api.jar
14,942 bytes
2. org.apache.tuscany.sca.tuscany.corespi.jar
370,228 bytes
3. org.apache.tuscany.sca.tuscany.runtime.jar
571,159 bytes
4. org.apache.tuscany.sca.tuscany.extensions.jar 996,238
bytes
5. org.apache.tuscany.sca.tuscany.dependencies.jar
43,928,926 bytes
>From a packaging point of view, it doesn't make sense to split Tuscany, and
it makes a lot more sense to split the 3rd party code.
> [snip]
> > Based on the notes, I think the desired classloading hierarchy for
> Tuscany
> > is:
> >
> >
> >
> http://cwiki.apache.org/confluence/download/attachments/68801/desired-classloader.png
> >
> You said "desired classloading", can you help me understand the use
> cases that this structure will help with?
>
> I'm asking because I'm surprised to see "the whole world" in a single
> "3rd party libraries" bundle, which I think is where we're going to see
> version conflicts. I'm also not sure about what steps I'd have to follow
> if I wanted to add a new extension to Tuscany with additional 3rd party
> libraries.
I dont want to sound like I am doing a sales pitch for OSGi, but I am not
sure there is a cleaner or easier way to sort out versioning issues that
Tuscany would face if different versions of 3rd party libraries were
used, compared to running Tuscany under OSGi. An OSGi runtime would enable
different versions of 3rd party libraries, different versions of Tuscany
runtime and different versions of Tuscany extensions to coexist in a single
VM with very little extra effort. Implementing something similar with a
classloader architecture outside of OSGi would be significantly more complex
(and will eventually reinvent OSGi).
The desired classloading hierarchy is based on Raymond's graph and the notes
from Simon Nash and Simon Laws about static visibility (and non-visibility)
from classes in the different bundles. It is the best you can get with a
single-parent Java delegation model without running into
ClassCastExceptions. If the 3rd party code is split into multiple
classloaders, you would invariably need multi-parent or OSGi style
classloading.
You are absolutely right, apart from cleaning up Tuscany modularization,
there would be no perceivable difference from enabling a multi-classloader
framework for the Tuscany runtime (ignoring application classloading for the
moment), when Tuscany is run outside of OSGi. In fact, I imagine the
multi-classloader framework would probably never be used except for testing.
So why go to all this trouble? In my opinion, the advantages of enabling a
multi-classloader framework in Tuscany are:
1. Application contribution isolation based on the SCA contribution
spec, regardless of whether the contribution is an OSGi bundle or not.
2. Enable Tuscany to be split into multiple bundles to enable Tuscany
to run under OSGi with full modularity and versioning (rather than as a
single bundle containing all of Tuscany and its dependencies)
3. Enable the use of a classloader hierarchy which matches everyone's
understanding of Tuscany modularization, and adding tests which verify that
this level of modularity is maintained. Raymond's graph and the other notes
give an almost identical picture of the dependency relationship across
bundles in Tuscany. But this does not match the current implementation, and
the ad-hoc use of thread context classloaders and the sprinkling of
someClass.getClassLoader() used in Class.forName/ClassLoader.loadClass
throughout Tuscany make it difficult to modify the classloader hierarchy
without pervasive code changes. With the proposed changes, there would be a
clearer definition of class visibility across bundles.
If there is a requirement to add new extensions with different versions of
3rd party libraries, but without running Tuscany under OSGi, I will look at
implementing multi-parent extension classloaders. It may be possible to do
this at a later stage.
> Thanks
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Thank you...
Regards,
Rajini
