On 10/23/07, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > > 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 >
I've been staying quiet for most of this to try to give you some space to go write the code, but for the record, i agree with everything you've said here and would really love to see us get this OSGi enablement. I'm sure this discussion has been useful to clarify some of the finer points but may be its time to just do it and once its started we can all incrementally improve things to get to something everyone is happy with. This would be a great piece of work to have for a 1.1 release so how about aiming for getting it done and a release out with it in a month or so? ...ant
