On 10/18/07, Rajini Sivaram <[EMAIL PROTECTED]> wrote: > > Simon, > > Thank you for your note. Yes, you are right, we should have a separate > classloader for the SPI with its own visibility rules. > > In terms of static dependencies (these are shown in Raymond's graph), > Tuscany modules are fairly neatly separated out. These are the > compile-time > dependencies in pom.xml, and Eclipse would throw up if there were any > cyclic > dependencies. From your list, 1. is currently not true, but can be easily > fixed. 2., 3. and 5. are true. 4. is only partially true, because there > are > many dependencies across modules - for instance, implementation.spring and > implementation.osgi use code from implementation.java. > > But for dynamic classloading, the dependencies are not so straightforward, > and any classloader-based isolation has to handle either dynamic > visibility > or access to classloaders which have the visibility. An example of the > difference between static and dynamic dependencies is 3. Tuscany SPIs dont > need static access to Tuscany runtime code, but there is code in > tuscany-core-spi which loads classes from the runtime modules. Here is an > example: > > * > > DefaultExtensionPointRegistry.getExtensionPoint(Class<T> > extensionPointType): > * > > *Class<?> extensionPointClass = > Class.forName(classNames.iterator().next(), > **true**, classLoader);* > > **Here, the classloader used is the classloader of <extensionPointType> > which is from the SPI. But the class being loaded is from a runtime > module. > This type of dynamic classloading is used in many places in Tuscany, and > they work at the moment because all modules including the SPI are loaded > using a single classloader. In this case, SPI doesn't need to "see" the > classes from the runtime module, but it needs to know how to obtain the > classloader which can see those classes. > > > Thank you... > > Regards, > > Rajini > > > On 10/17/07, Simon Nash <[EMAIL PROTECTED]> wrote: > > > > I'm just catching up with this very interesting thread. Comments > inline. > > > > Rajini Sivaram wrote: > > > > > Sebastien, > > > > > > I have the second path - (multiple application loaders, one runtime > > loader) > > > working in my sandbox. I need to write some tests and run all the > > existing > > > tests before I submit the patch. This works without OSGi, and is a > very > > > minor change. > > > > > > For the first path, I am still running under OSGi. At the moment I > have > > four > > > different scenarios (they are all running tests using Axis2 binding to > > > support distributed-OSGi): > > > > > > 1. One Tuscany bundle containing Tuscany + dependencies (one > > > classloader for all the jars referred to in > tuscany-sca-manifest.jar > > ). > > > This works and corresponds to CL1 application loader, CL2 runtime > > loader. > > > 2. Two Tuscany bundles, one containing Tuscany, another containing > > all > > > 3rd party dependencies(Axis2 etc.). This also works and corresponds > > to CL1 > > > application loader, and CL2 Tuscany, CL3 3rd party code. > > > 3. Split Tuscany bundles into multiple bundles, one bundle for 3rd > > > party (splitting CL2 into multiple loaders from 2.) > > > 4. Split 3rd party into multiple bundles, one bundle for Tuscany > > > (splitting CL3 into multiple loaders from 2.) > > > > > > 3. and 4. dont work yet. From your note (and Raymond's), I think I > > should > > > have another scenario before 3. which splits Tuscany into API and > > runtime. I > > > think that should work without much trouble (ie, CL1 application > loader, > > CL2 > > > Tuscany API loader, CL3 Tuscany runtime loader, CL4 3rd party loader). > > > > > Where do the SPIs fit into this? They aren't really part of the API > > loader, because aplication code shouldn't see them. The aren't really > > part of the runtime loader, because they need to be exposed between > > different runtime modules, but the runtime code shouldn't be exposed. > > > > I think Raymond's graph of dependencies was helpful in laying out the > > visbility relationships. There's also a counterpoint for what things > > should NOT be visible. In the following, "see" means that it's > > statically referenceable using the same classloader. > > > > 1. Application code shouldn't be able to see non-imported contributions, > > Tuscany SPIs, or Tuscany runtime code. > > > > 2. Tuscany APIs shouldn't be able to see anything else. > > > > 3. Tuscany SPIs shouldn't be able to see Tuscany runtime code or > > application code. > > > > 4. Tuscany runtime code shouldn't be able to see Tuscany runtime code > > in other modules, or application code. > > > > 5. 3rd party code (not written with knowledge of Tuscany) shouldn't be > > able to see Tuscany runtime code, Tuscany SPIs, Tuscany APIs, or > > application code. > > > > Simon > > > > > The tests for multiple application loaders (second path in your note) > > will > > > be non-OSGi tests - Tuscany OSGi contributions are already tested with > > > multiple bundles and hence multiple classloaders. For the first path, > I > > > haven't really considered testing without OSGi - I would probably > still > > > continue to work with OSGi to isolate the issues, but try and > introduce > > > tests later which run without OSGi. > > > > > > > > > > > > Thank you... > > > > > > Regards, > > > > > > Rajini > > > > > > > > > > > > On 10/16/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > > >>Rajini Sivaram wrote: > > >> > > >>>Raymond, > > >>> > > >>>Thank you for your reply (and the diagram). > > >>> > > >>>The biggest advantage of migrating to an OSGi classloader scheme > would > > >> > > >>be > > >> > > >>>that apart from module isolation, OSGi would also provide module > > >> > > >>versioning, > > >> > > >>>enabling multiple versions of SCA runtime to exist within a single > VM. > > >> > > >>OSGi > > >> > > >>>would also enable Tuscany modules to be dynamically installed, > started > > >> > > >>and > > >> > > >>>uninstalled. The use of multi-parent classloaders to load modules in > > >> > > >>Tuscany > > >> > > >>>would require the same amount of code changes as migrating to OSGi, > but > > >> > > >>it > > >> > > >>>would be much harder to implement versioning and dynamic replacement > of > > >>>modules (which come for free with OSGi). > > >>> > > >>>The desired visibility of classes that you have listed correspond to > > the > > >>>static dependencies that currently exist in the code. The actual > > >> > > >>visibility > > >> > > >>>that exists today includes arrows from the core modules to > extensions, > > >>>forming a cycle. It is this visibility that is used to locate and > start > > >>>modules dynamically in Tuscany today. There is also an arrow from the > > >> > > >>Axis > > >> > > >>>library to binding.ws.axis2, through the thread context classloader, > > and > > >>>even though not particularly desirable, it is not avoidable. > > >>> > > >>> > > >>>Thank you... > > >>> > > >>>Regards, > > >>> > > >>>Rajini > > >>> > > >>> > > >> > > >>How about going step by step and: > > >>1. try to bootstrap the tuscany runtime with two classloaders: CL1 > > >>application code, CL2 runtime > > >>2. extend to CL1 application code, CL2 Tuscany and SCA APIs, CL3 > runtime > > >>3. split the runtime in multiple CLs > > >> > > >>and on a separate path: > > >>1. try to bootstrap the tuscany runtime with two classloaders: CL1 > > >>application code, CL2 runtime > > >>2. split the application code in multiple CLs > > >> > > >>We could create integration tests for these configurations (not > > >>necessarily using OSGi, as these can be built with just plain > > >>classloaders IMO), and it would help us identify bad classloader > usages, > > >>fix them, and detect+prevent classloader issues over time. > > >> > > >>Thoughts? > > >> > > >>-- > > >>Jean-Sebastien > > >> > > >> > > >>--------------------------------------------------------------------- > > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > > >>For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > 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. 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. 4b Tuscany runtime code shouldn't be able to see Tuscany extension code or application code. 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
