Rajini Sivaram 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.
I stated this as an extreme position to see what the reaction would be :-)
I would be OK with extending this to provide static visibility between
Tuscany modules. If we allow this, I'd be inclined to go for a single
shared classloader for all Tuscany modules, not a set of dependency
relationships enforced by separate classloaders as can be done using
fine-grained OSGi modularity.
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.
I think this is fine, and a necessary escape from the static visibility
constraints. The mechanism to get the dynamic classloader can be controlled
so that it is only allowed for code that needs access to it.
Simon
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]
