*Classloading in Tuscany - Tuscany Extension Classloading*
*Current implementation*
Details on the Tuscany extension architecture are described here:
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+Extension+Development+Guide
This extension architecture is based on standard J2SE
Hi,
Please see my comments inline.
Thanks,
Raymond
- Original Message -
From: Rajini Sivaram [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Friday, October 26, 2007 5:00 AM
Subject: Re: Classloading in Tuscany
*Classloading in Tuscany - Tuscany Extension Classloading
, 2007 5:00 AM
Subject: Re: Classloading in Tuscany
*Classloading in Tuscany - Tuscany Extension Classloading*
*Current implementation*
Details on the Tuscany extension architecture are described here:
http://cwiki.apache.org/confluence/display/TUSCANY/SCA+Java+Extension+Development
Sebastien,
Comments inline.
On 10/25/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Some comments and use cases.
Rajini Sivaram wrote:
The bundles that I have at the moment are:
1. org.apache.tuscany.sca.api.jar
14,942 bytes
2.
On 10/25/07, Rajini Sivaram [EMAIL PROTECTED] wrote:
snip
This does imply splitting both Tuscany extension bundle
and the big 3rd party bundle, into smaller chunks. Because of its size, I
am
more inclined to split the 3rd party bundle into smaller bundles first
(though I have no idea where
Thank you, Ant. That will be very helpful.
Let me finish off the classloading changes first, and I will get back to you
(hopefully sometime next week).
Thank you...
Regards,
Rajini
On 10/25/07, ant elder [EMAIL PROTECTED] wrote:
On 10/25/07, Rajini Sivaram [EMAIL PROTECTED] wrote:
snip
Some comments and use cases.
Rajini Sivaram wrote:
The bundles that I have at the moment are:
1. org.apache.tuscany.sca.api.jar
14,942 bytes
2. org.apache.tuscany.sca.tuscany.corespi.jar
370,228 bytes
3. org.apache.tuscany.sca.tuscany.runtime.jar
571,159 bytes
4.
application bundles.
Based on the notes, I think the desired classloading hierarchy for Tuscany
is:
http://cwiki.apache.org/confluence/download/attachments/68801/desired-classloader.png
The solid lines show parent-child relationship used for standard Java
classloader delegation
43,928,926 bytes
From a packaging point of view, it doesn't make sense to split Tuscany, and
it makes a lot more sense to split the 3rd party code.
[snip]
Based on the notes, I think the desired classloading hierarchy for
Tuscany
is:
http://cwiki.apache.org/confluence/download
the desired classloading hierarchy for
Tuscany
is:
http://cwiki.apache.org/confluence/download/attachments/68801/desired-classloader.png
You said desired classloading, can you help me understand the use
cases that this structure will help with?
I'm asking because I'm surprised
This note is getting a bit long now. I added two comments inline
and cut out some of the previous discussion.
Simon
Rajini Sivaram wrote:
Simon,
Comments inline...
(cut)
maven module names
1. SCA API (sca-api)
2. Tuscany SPI (core-spi, assembly, contribution, policy, interface,
Simon,
Shall I work on the classloading changes with the extension classloader as a
child of Tuscany Runtime (rather than the SPI), and look at separating the
Runtime and SPI properly later? I would like to keep Core-SPI and Runtime as
two different bundles, so that when running under OSGi, the
*Classloading in Tuscany - Application contribution classloaders*
*Current implementation*
Application classes from contributions are loaded by Tuscany in
ClassReferenceModelResolver. At the moment, this uses the thread context
classloader, which is typically set as the Java application
Simon,
I would like to retain two bundles and hence two separate classloaders for
SPI and Runtime under OSGi. I will use a single classloader for SPI and
Runtime outside of OSGi.
Thank you...
Regards,
Rajini
On 10/23/07, Simon Nash [EMAIL PROTECTED] wrote:
Rajini Sivaram wrote:
Simon,
Sounds good. My answers to your questions are below.
Simon
Rajini Sivaram wrote:
*Classloading in Tuscany - Application contribution classloaders*
*Current implementation*
Application classes from contributions are loaded by Tuscany in
ClassReferenceModelResolver. At the moment
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
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
will be added for classloading which checks if
Tuscany runs with multiple classloaders and verifies that all the isolation
requirements are met.
Based on the notes, I think the desired classloading hierarchy for Tuscany
is:
http://cwiki.apache.org/confluence/download/attachments/68801/desired
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
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
classloading hierarchy for Tuscany
is:
http://cwiki.apache.org/confluence/download/attachments/68801/desired-classloader.png
The solid lines show parent-child relationship used for standard Java
classloader delegation, providing static visibility. The dotted lines show
dependencies which are more targetted
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
(Axis2 etc)
6. Application contributions
Do you know give the approx size of each bundle?
[snip]
Based on the notes, I think the desired classloading hierarchy for Tuscany
is:
http://cwiki.apache.org/confluence/download/attachments/68801/desired-classloader.png
You said desired
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
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
On 10/18/07, Rajini Sivaram [EMAIL PROTECTED] 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
Simon,
At the moment my SPI bundle contains tuscany-core-spi, tuscany-contribution,
tuscany-policy, tuscany-interface and tuscany-assembly. From Simon Nash's
note, I assumed that SPI meant tuscany-core-spi and used that project + its
dependencies. I am ignoring host-embedded classes at the
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.?
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
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
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.
PROTECTED] wrote:
Hi, Rajini.
Thank you for the detailed writeup. I copied your note into the following
wiki page so we can capture the design points.
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Classloading+in+Tuscany+SCA+Java
I found it a bit difficult to reply in long e-mails so I
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
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
Mike,
There are two sets of classloading in Tuscany that we need to look at and
these can be handled independently of each other.
1) Classloading architecture for SCA contributions
2) Classloading architecture for SCA runtime modules
In both cases, there are two ways of improving modularity
Hi, Rajini.
Thank you for the detailed writeup. I copied your note into the following
wiki page so we can capture the design points.
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Classloading+in+Tuscany+SCA+Java
I found it a bit difficult to reply in long e-mails so I decide
be run inside OSGi without CLASSPATH, by setting the
context
classloader.
I would like to propose the following fixes to Tuscany classloading (my
aim
is to implement neater isolation without too much impact on the code):
1) Fix contribution classloading to enforce SCA
be run inside OSGi without CLASSPATH, by setting the
context
classloader.
I would like to propose the following fixes to Tuscany classloading (my
aim
is to implement neater isolation without too much impact on the code):
1) Fix contribution classloading to enforce SCA contribution
Tuscany. All Tuscany tests rely on CLASSPATH,
while
Tuscany can be run inside OSGi without CLASSPATH, by setting the
context
classloader.
I would like to propose the following fixes to Tuscany classloading (my
aim
is to implement neater isolation without too much impact on the code):
1) Fix
on the CLASSPATH, or should set the thread context classloader
for its threads using Tuscany. All Tuscany tests rely on CLASSPATH, while
Tuscany can be run inside OSGi without CLASSPATH, by setting the context
classloader.
I would like to propose the following fixes to Tuscany classloading (my
40 matches
Mail list logo
