Folks,
Whoa there. Lets not go rushing off to implement something without some
agreement about it, please.
Can you explain the split you propose in some more detail, please.
What is "the SCA hook to Spring"? What classes and functions do you think are in that package - and
more importantly, what other classes do they access?
The two way split that we had been working was to give 2 packages, one of which was on the "Tuscany"
side of things and the other which was entirely based around Spring code, with *no* dependencies on
Tuscany classes at all.
What is in each of the 3 packages you propose and what is their relation to other code, including
Spring and other Tuscany code.
Yours, Mike.
Raymond Feng wrote:
Hi,
By further investigation of the code, I realized that the current
implementation-spring-runtime module contains the code to parse SCA
namespace and invoke the spring beans by instantiating the application
context. It is the SCA hook to Spring. But the -runtime convention is
really confusing as we always use -runtime in Tuscany to package the
implementation/binding provider code.
I propose that we refactor the code into three modules:
1) implementation-spring: the model and xml processor (to move the
org.apache.tuscany.sca.implementation.spring.invocation into the
implementation-spring-runtime)
2) implementation-spring-runtime: implementation.spring runtime provider
3) implementation-spring-sca: the SCA hook for Spring applications (to
be renamed from the current implementation-spring-runtime)
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <[email protected]>
Sent: Wednesday, May 06, 2009 12:11 AM
To: <[email protected]>
Subject: Re: [2.x] Porting Spring Modules into 2.x
That dependency was a hang over form an earlier round of refactoring,
it isn't required and i've removed it now.
...ant
On Tue, May 5, 2009 at 11:32 PM, Raymond Feng <[email protected]>
wrote:
I'm looking to the implementation-spring module. There are a few
things that
confuse me:
1) Why does implementation-spring depend on the
implementation-spring-runtime. Shouldn't it be reversed?
2) The implementation provider for Spring is packaged in
implementation-spring which should be used to contain the model and
processor code.
I would appreciate some clarifications.
Thanks,
Raymond
From: Ramkumar R
Sent: Tuesday, April 28, 2009 10:34 AM
To: [email protected]
Subject: Re: [2.x] Porting Spring Modules into 2.x
On Fri, Apr 24, 2009 at 3:04 PM, Mike Edwards
<[email protected]> wrote:
Luciano,
The Spring implementation-xml module is one that I propose we get
rid of.
It is one of my "suspicious" ones - it contains a single class
only. This
seems very wasteful, as it does not really offer much in the way of
"pluggability". Putting it into the main implementation-spring module
really does simplify things in this case.
It is notable that the dependencies of the module are all already
contained in the dependencies of implementation-spring, so this will
not
increase coupling.
Yours, Mike.
Another round of re-factoring with spring module.
1. Removed the implementation-spring-xml module and moved that one
class in
implementation-spring module.
2. Moved the classes in
org.apache.tuscany.sca.implementation.spring.processor package to
implementation-spring-runtime module.
3. Changed the SpringImplementation.java to implement
ComponentPreProcessor.
--
Thanks & Regards,
Ramkumar Ramalingam
