Jean-Sebastien Delfino 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?
While going through some JIRAs I came across
http://issues.apache.org/jira/browse/TUSCANY-1487, this is basically
step (1) reported as a user requirement.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
