*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
Simon,
Comments inline...
On 10/22/07, Simon Nash [EMAIL PROTECTED] wrote:
Thanks for all your work on progressing this. Comments inline.
Simon
Rajini Sivaram wrote:
*An overview of the proposed classloader design for Tuscany*
Thank you for all your emails. Based on your
Sebastien,
Comments inline.
On 10/22/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
I have two questions.
[snip]
Rajini Sivaram wrote:
We have the following bundles in Tuscany - the names in brackets refer
to
maven module names
1. SCA API (sca-api)
2. Tuscany SPI
On 10/23/07, Rajini Sivaram [EMAIL PROTECTED] wrote:
Sebastien,
Comments inline.
On 10/22/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
I have two questions.
[snip]
Rajini Sivaram wrote:
We have the following bundles in Tuscany - the names in brackets refer
to
maven
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, this
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
*An overview of the proposed classloader design for Tuscany*
Thank you for all your emails. Based on your feedback, I would like to
propose a new classloader architecture for Tuscany. I have created new
bundles in OSGi to reflect the kind of classloader-based isolation that we
may like to have,
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
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
Thanks for all your work on progressing this. Comments inline.
Simon
Rajini Sivaram wrote:
*An overview of the proposed classloader design for Tuscany*
Thank you for all your emails. Based on your feedback, I would like to
propose a new classloader architecture for Tuscany. I have created
On 10/22/07, Simon Nash [EMAIL PROTECTED] wrote:
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
I have two questions.
[snip]
Rajini Sivaram wrote:
We have the following bundles in Tuscany - the names in brackets refer to
maven module names
1. SCA API (sca-api)
2. Tuscany SPI (core-spi, assembly, contribution, policy, interface,
interface-java, interface-wsdl, databinding)
3.
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.
the loading scheme.
Raymond
- Original Message -
From: Rajini Sivaram [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, October 15, 2007 12:52 AM
Subject: Re: Classloading in Tuscany
Mike,
There are two sets of classloading in Tuscany that we need to look
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
- Original Message -
From: Rajini Sivaram [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, October 15, 2007 12:52 AM
Subject: Re: Classloading in Tuscany
Mike,
There are two sets of classloading in Tuscany that we need to look at and
these can be handled independently
Thank you, Ant. I will try to split the work into small pieces and submit
separate patches.
Thank you...
Regards,
Rajini
On 10/12/07, ant elder [EMAIL PROTECTED] wrote:
On 10/11/07, Rajini Sivaram [EMAIL PROTECTED] wrote:
Hello,
Tuscany's use of classloaders doesn't seem to be
On 10/11/07, Rajini Sivaram [EMAIL PROTECTED] wrote:
Hello,
Tuscany's use of classloaders doesn't seem to be well-defined, even though
the concept of a runtime classLoader and contribution classloaders should
have made it easy to isolate these namespaces. All Tuscany samples and
tests
are
Rajini,
Little though here:
- can this be done in a way that moves us closer to the OSGi handling of
classloading?
- so if ever we wanted an OSGi style runtime, it would be easier to
adapt what we have...
Yours, Mike.
Rajini Sivaram wrote:
Thank you, Ant. I will try to split the work
38 matches
Mail list logo
