Rajini Sivaram wrote:
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 dependencies
will be specified explicitly (making it slightly simpler to remove the
dependencies later on).
The picture you posted in
http://cwiki.apache.org/confluence/download/attachments/68801/proposed-classloader.png
for your initial implementation proposal has the extension classloader
as a child of the Tuscany runtime classloader, and the runtime classloader
as a child of the Tuscany SPI classloader.
When running outside of the OSGi environment, I don't think it is worth
having separate classloaders for Tuscany runtime and Tuscany SPI in the
initial implementation, until we have resolved the separation issues.
If you want to keep these separate as OSGi bundles, and run them under
separate OSGi classloaders in the OSGi environment, I'm OK with that.
Are you proposing that there would be separate classloaders for SPI and
runtime when running under OSGi, but only one classloader for both of
these when running outside OSGi? Or are you proposing that in both
cases there would be two separate classloaders? I'm sorry that I have
not quite understood what you are proposing here.
The alternative is to clean up the SPI first before working on the
classloader changes. What do you think?
I think you should start on the new classloader structure now, as Ant
has said. The SPI cleanup is likely to be quite a lot of work, so it
makes more sense to do that as a second round.
Simon
Thank you...
Regards,
Rajini
On 10/23/07, Simon Nash <[EMAIL PROTECTED]> wrote:
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,
interface-java, interface-wsdl, databinding)
Some of the above maven modules contain implementation code as well as
SPI code. For example, in the assembly module, Service.java is an SPI
and ServiceImpl.java is an implementation class.
Yes, unfortunately many of these implementation classes are used outside
of
the SPI modules. At the moment the core-spi bundle that I use to run
Tuscany
under OSGi is forced to export all the packages from these modules,
rather
than just the SPI. eg. ComponentImpl from the assembly module along with
SPI
forms the base class of RuntimeComponentImpl in Runtime.
ComponentTypeImpl
from the assembly module is used by many extensions.
For impl classes that are intended as extension points, we do have an
approach used in some places where an empty SPI class extends the impl
class and other modules extend the SPI class. Perhaps we could change
all these places to use that approach.
(cut)
http://cwiki.apache.org/confluence/download/attachments/68801/tuscany-binding-ws-axis2-dependencies.png
http://cwiki.apache.org/confluence/download/attachments/68801/tuscany-implementation-spring-dependencies.png
These dependency diagrams show that either the extension modules are
dependent on the Tuscany Runtime or I have the wrong list of modules
for
Core-SPI and Runtime.
I looked at one of these dependencies. It's a helper class in
implementation-java-xml that looks like it should be an SPI.
There may be many others as well. In particular, I am sure that all the
domain/node related code are in the wrong place, and I will sort those
out
later.
We should go through all these uses and decide if they are correct.
If they are, we should move these impl classes to the SPI, or create new
SPI classes that provide the same functionality.
Simon
---------------------------------------------------------------------
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]
