Simon, At the moment my SPI bundle contains tuscany-core-spi, tuscany-contribution, tuscany-policy, tuscany-interface and tuscany-assembly. From Simon Nash's note, I assumed that SPI meant tuscany-core-spi and used that project + its dependencies. I am ignoring host-embedded classes at the moment, and I will try and fit those in once your reorganized code is in place. I am working with 1.0 release since that was the most stable code I could find when I started, but I think I should move to the latest code soon.
Once I get the SPI bundle sorted, I will see if I can split the rest of Tuscany into a runtime and extensions (two bundles). Thank you... Regards, Rajini On 10/18/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > 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.springand > > 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 >
