Ant, Thank you, I will start coding now and submit patches for each step - I will provide details of the implementation of each step on the mailing list before submitting the patch. Aiming for 1.1 sounds good.
Thank you... Regards, Rajini On 10/23/07, ant elder <[EMAIL PROTECTED]> wrote: > > 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 >
