Thanks for these clarifications. One question inline below.
Simon
Rajini Sivaram wrote:
Simon,
Comments inline.
Thank you...
Regards,
Rajini
On 10/22/07, Simon Nash <[EMAIL PROTECTED]> wrote:
Rajini Sivaram wrote:
Sebastien,
I think we could implement the following classloading changes to Tuscany
(in
this order). I will post a more detailed proposal (along with
some questions) based on the feedback.
1. Application classloading - move from a single thread context based
classloader to OSGi-style multiple-classloader framework
Am I correct in thinking that the intention is to enable this but not
require it? "Move" suggests it might be required.
I will submit detailed proposals for each of the changes. My intention was
to modify contribution classloading in Tuscany, so that Tuscany created
separate classloaders for the contributions. After the changes, it will no
longer be possible to run multiple contributions in a single classloader.
This is different from the proposed changes for Tuscany runtime classloading
which was enabling the use of multiple classloaders, without requiring them.
2. Tuscany runtime classloading framework - enable the use of
multiple
classloaders, with an API in host-embedded or the new domain APIs to
specify
multiple runtime/extension classloaders
I'd need to see more details on this before I can comment. I'm wondering
how much of the Tuscany runtime's classloading mechanism for its own
classes should be controllable by external APIs.
It is not necessary to externalize the API, it could be an SPI used
purely for testing. The externally visible use of the multi-classloader
framework could be purely under OSGi (where classloaders will be registered
by bundle activators and no additional API is required).
At the moment, to create an EmbeddedSCADomain, there is an API which
specifies the runtimeClassLoader:
public EmbeddedSCADomain(ClassLoader runtimeClassLoader, String
domainURI)
This is specifying the classloader where all Tuscany related classes can be
found. What I would like (at least for testing) is something like:
public EmbeddedSCADomain(ClassLoader runtimeClassLoader, ClassLoader[]
extensionClassLoaders, Class, String domainURI)
3. Reimplement Tuscany runtime extension mechanism so that SPI
classloader does not require visibility of extension modules.
Sounds good.
4. Remove the use of thread context classloader inside Tuscany - use
specific classloaders based on what is being loaded. Thread context
classloader will be the parent of all classloaders used in Tuscany to
enable
applications as well as 3rd party code to continue to use it.
Can you give a bit more detail about the scenarios in which this parenting
is needed? Is it needed to make Tuscany classloading work correctly,
or to make third party code classloading work correctly?
The goal of this work is to remove the use of thread context classloaders in
Tuscany so that Tuscany itself does not load any classes using it. But many
3rd party libraries which Tuscany depends on, use the thread context
classloader. eg. javax.xml.stream uses thread context classloader to find
XMLOutputFactory/XMLInputFactory implementation classes (requiring 3rd party
code to be available through the thread context classloader), and Axis2 uses
thread context classloader to find Tuscany's message receivers like
org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSyncMessageReceiver(requiring
Tuscany extensions to be available through the thread context
classloader). Applications or third party libraries used by applications
could also have a dependency on the context classloader.
How does having the thread context classloader as the parent of
Tuscany's classloaders help with this? If the third party code uses the
thread context classloader, it won't see any Tuscany classloaders that
are children of the thread context classloader.
Simon
5. Enable extensions to be packaged as separate OSGi bundles with
separate classloaders, but with OSGi-defined package dependencies
across
extension modules.
Sounds good.
Default classloading for Tuscany runtime+extensions (CLASSPATH based
single
Java application classloader) will continue to be used for all existing
tests and samples, but new tests will be added to test classloader-based
isolation.
Sounds good as a first step.
Simon
Thank you...
Regards,
Rajini
On 10/19/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
I wanted to summarize this thread as it has been pretty popular - I
guess we all know what a classloader is and are happy to talk about it
:) - but I am getting lost in the various exchanges.
Could anybody please help provide 2 or 3 short sentences summarizing the
first 2 or 3 steps that are going to be implemented?
Thanks...
Simon Laws wrote:
On 10/18/07, Mike Edwards <[EMAIL PROTECTED]> wrote:
Folks,
Comments inline
Simon Laws wrote:
Hi Rajini
Re. 4 on Simon's list. Maybe it is useful to more clearly distinguish
between those Tuscany modules that are expect to be loaded
statically,
assembly, core, etc and those that expected to be loaded dynamically,
binding.?, implementation.? etc. I find the term "module" a little
unsatisfactory. Raymond, in his diagram, used Tuscany core and
Tuscany
extension and in a previous post used Tuscany runtime and Tuscany
extension. I prefer the latter pair just because we have a maven
module
called core.
+1
This leads to a 4a and 4b based on Raymond's post/diagram
4a Tuscany extension module code shouldn't be able to see other
extension
modules (not sure what the dotted line on the diagram implies but I
expect
that it's to do with modules like binding-ws-axis2 and binding-ws
interacting) or application code or Tuscany runtime code other than
via
the
SPI.
Hmm, first, this ain't the case today and it will need some thought.
The "Java" extensions do share code and it would be crazy for them not
to share the code. So, Spring uses stuff out of the base Java
extension
- and I am sure that other "Java" type extensions would want to do the
same.
In an OSGi world, it would be fine to express the dependency in a
simple
way. For non-OSGi I'm not sure of the best route.
I suspect that other extension types may want to share stuff as well.
Agreed. Hence I pointed out the relationship between binding-ws-axis2
and
binding-ws. There are loose groups of software spread across multiple
maven
modules that just represent modularization of the software for clarity
and
reuse purposes. Then there are the modules that are intended to be
loaded as
extensions. Not all maven modules are create equal :-) The non OSGi
world is
managed by the dependencies that appear in out maven pom files. Without
this
dependency tree you just have to know that, for example, binding-ws has
to
be on the classpath when you also include binding-ws-xml which is in
turn a
dependency of binding-ws-axis2. Nothing too unusual there until you
start
talking about having separate class loaders for each extension as has
been
discussed previously in this thread. You really need to understand what
an
extension is, i.e. it is unlikely to be a single maven module.
4b Tuscany runtime code shouldn't be able to see Tuscany extension
code
or
application code.
That sounds a bit odd. Perhaps I've not got the right end of the
stick,
but the some code - either core and or extensions has to get very
intimate with the application code. Introspection, instantiation,
injection - all has to be done either by core code or extension code.
Perhaps I've not understood the separation you're looking for?
This should say "shouldn't be able to statically see..". I had imagined
that
these are all of the implementation modules that sit behind the SPI
Then, from reading your comments, we have to be clearer about what
the
SPI
is providing an interface to because it current includes interfaces
to
the
underlying runtime modules but also the host-embedded classes which
strike
me as being more API than SPI. We are reorganizing the domain/node
interfaces at the moment so hopefully we can clear this last point up
as
part of that.
Regards
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
