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). 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] > >
