On 10/22/07, Simon Nash <[EMAIL PROTECTED]> wrote: > > Thanks for these clarifications. One question inline below. > > Simon > > Rajini Sivaram wrote: > > > Simon, > > > > Comments inline. > > > > > > Thank you... > > > > Regards, > > > > Rajini > > > > On 10/22/07, Simon Nash <[EMAIL PROTECTED] > wrote: > > > >> > >>Rajini Sivaram wrote: > >> > >> > >>>Sebastien, > >>> > >>>I think we could implement the following classloading changes to > Tuscany > >> > >>(in > >> > >>>this order). I will post a more detailed proposal (along with > >>>some questions) based on the feedback. > >>> > >>> > >>> 1. Application classloading - move from a single thread context > based > >>> classloader to OSGi-style multiple-classloader framework > >> > >>Am I correct in thinking that the intention is to enable this but not > >>require it? "Move" suggests it might be required. > > > > > > > > I will submit detailed proposals for each of the changes. My intention > was > > to modify contribution classloading in Tuscany, so that Tuscany created > > separate classloaders for the contributions. After the changes, it will > no > > longer be possible to run multiple contributions in a single > classloader. > > This is different from the proposed changes for Tuscany runtime > classloading > > which was enabling the use of multiple classloaders, without requiring > them. > > > > > > > > > >>> 2. Tuscany runtime classloading framework - enable the use of > >> > >>multiple > >> > >>> classloaders, with an API in host-embedded or the new domain APIs to > > >> > >>specify > >> > >>> multiple runtime/extension classloaders > >> > >>I'd need to see more details on this before I can comment. I'm > wondering > >>how much of the Tuscany runtime's classloading mechanism for its own > >>classes should be controllable by external APIs. > > > > > > > > It is not necessary to externalize the API, it could be an SPI used > > purely for testing. The externally visible use of the multi-classloader > > framework could be purely under OSGi (where classloaders will be > registered > > by bundle activators and no additional API is required). > > > > At the moment, to create an EmbeddedSCADomain, there is an API which > > specifies the runtimeClassLoader: > > public EmbeddedSCADomain(ClassLoader runtimeClassLoader, String > > domainURI) > > This is specifying the classloader where all Tuscany related classes can > be > > found. What I would like (at least for testing) is something like: > > public EmbeddedSCADomain(ClassLoader runtimeClassLoader, > ClassLoader[] > > extensionClassLoaders, Class, String domainURI) > > > > > > > >> 3. Reimplement Tuscany runtime extension mechanism so that SPI > >> > >>> classloader does not require visibility of extension modules. > >> > >>Sounds good. > >> > >> > >>> 4. Remove the use of thread context classloader inside Tuscany - use > >>> specific classloaders based on what is being loaded. Thread context > >>> classloader will be the parent of all classloaders used in Tuscany > to > >> > >>enable > >> > >>> applications as well as 3rd party code to continue to use it. > >> > >>Can you give a bit more detail about the scenarios in which this > parenting > >>is needed? Is it needed to make Tuscany classloading work correctly, > >>or to make third party code classloading work correctly? > > > > > > > > The goal of this work is to remove the use of thread context > classloaders in > > Tuscany so that Tuscany itself does not load any classes using it. But > many > > 3rd party libraries which Tuscany depends on, use the thread context > > classloader. eg. javax.xml.stream uses thread context classloader to > find > > XMLOutputFactory/XMLInputFactory implementation classes (requiring 3rd > party > > code to be available through the thread context classloader), and Axis2 > uses > > thread context classloader to find Tuscany's message receivers like > > > org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSyncMessageReceiver > (requiring > > Tuscany extensions to be available through the thread context > > classloader). Applications or third party libraries used by applications > > > could also have a dependency on the context classloader. > > > How does having the thread context classloader as the parent of > Tuscany's classloaders help with this? If the third party code uses the > thread context classloader, it won't see any Tuscany classloaders that > are children of the thread context classloader.
I just read through what I wrote originally, and my last reply which was sort of unrelated to that statement, and realized why I have caused the confusion. The only classloaders I want to create from within Tuscany are contribution classloaders. I would expect contributions to have access to classes defined within the contribution, other explicitly imported classes from other contributions and other 3rd party code which may not be inside an SCA contribution (this is different from OSGi where all classes are exported by some bundle). At the moment, applications can refer to any class in CLASSPATH. I wanted to continue to support this. In my original statement, what I meant was that the parent of application classloaders created by Tuscany would be the Java application classloader based on CLASSPATH. In the implementation, I was going to use Thread.currentThread().getContextClassLoader() to obtain this classloader, and I wanted to remove all other references to getContextClassLoader(). I didn't really mean the position of the thread context classloader in the classloader hierarchy (sorry). When multiple classloaders are used for classes in the Tuscany runtime, these classloaders need to be visible from the thread context classloader. At the moment, I am running this only under OSGi, where the thread context classloader is set to one using OSGi class resolution based on the Tuscany bundles. When we have code to do this without OSGi, Tuscany will have to set the thread context classloader to make extension classloaders available through the thread context classloader (I haven't worked out the details yet, but I was hoping to set a thread context classloader like the one I have now under OSGi where the classloader is purely used to initiate classloading and does not actually define any classes). > > > >>> 5. Enable extensions to be packaged as separate OSGi bundles with >>> separate classloaders, but with OSGi-defined package dependencies >> >>across >> >>> extension modules. >> >>Sounds good. >> >> >>> >>>Default classloading for Tuscany runtime+extensions (CLASSPATH based >> >>single >> >>>Java application classloader) will continue to be used for all existing >>>tests and samples, but new tests will be added to test classloader-based >>>isolation. >>> >> >>Sounds good as a first step. >> >> Simon >> >>> >>>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] Thank you... Regards, Rajini
