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]
