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