Hi, Jim.
There are a few people working on features toward SCA 1.0 in core. When will
refactoring be done so that we can build on top of it? Ideally, we want to
move in parallel. Do you see areas that should be on hold till the
refactoring is finished?
Thanks,
Raymond
----- Original Message -----
From: "Jim Marino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, February 03, 2007 10:17 AM
Subject: Re: svn commit: r502853 [1/7] - in
/incubator/tuscany/java/sca/kernel:
core/src/main/java/org/apache/tuscany/core/binding/local/
core/src/main/java/org/apache/tuscany/core/bootstrap/
core/src/main/java/org/apache/tuscany/core/builder/ core/src/main/java/or
On Feb 3, 2007, at 8:35 AM, Raymond Feng wrote:
Hi, Jim.
I would appreciate if you can share with us the ideas behind this
refactoring which is not very obvious to follow since it touched a
lot of code. The following information would help:
1) What problem do we have with the current code that you're fixing?
2) What are the key changes in your fix?
3) What's next if it's a staging approach?
I've mentioned the motivations behind this change earlier this week.
It corresponds to the work we are doing to support federation. The
change is actually quite simple, although it does touch a lot of
code. Basically it introduces a URI-based addressing scheme for
runtime artifacts. This will ultimately allow us to support
federated component hierarchies and wiring.
The next set of changes (which I will write up when I have more time)
will involve externalizing the management of the component tree to a
ComponentManager. I've already introduced a skeleton of the former
which will need to be expanded on. The ComponentManager will handle
parent-child relationships as well as serve implement a flattened
mechanism for component resolution. This will allow us to collapse
the distinctions between CompositeComponent and AtomicComponent. It
will also allow us to move the wiring into the resolution phase as we
have talked about previously. It will also enable us to perform wire-
path optimizations.
Several other side-effects will be that the connector becomes dead
simple, as it no longer needs to traverse a component tree (it just
uses ComponentManager), the exception handling becomes easier (URIs
tell the position), and SCAObject.getParent() is no longer needed.
Further SCAObject.isSystem will no longer be needed since that can be
accomodated by URI schemes.
So, to sum up, the latest commit was to move over to the URI-based
approach and introduce the ComponentManager; the other refactors I
mentioned to switch over to the ComponentManager will be coming.
HTH
Jim
Jim Marino
[EMAIL PROTECTED]
---------------------------------------------------------------------
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]
