tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raymond Feng" <enjoyj...@gmail.com>
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
Date Mon, 05 Feb 2007 22:33:58 GMT
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" <jmarino@myromatours.com>
To: <tuscany-dev@ws.apache.org>
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
> jmarino@myromatours.com
>
>
>
>
>
>
>



> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org 


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


Mime
View raw message