Hi,
Let me clarify a bit here:
Module 1 (implementation-spring) contains the Java model and XML processors
for <implementation.spring> element.
Module 2 (implementation-spring-runtime) contains the runtime logic
(implementation provider) that dispatches SCA invocations to components
using implementation.spring
The separation of 1 and 2 is desired so that 1 can be reused by tools or SCA
domain manager without dragging in the runtime code.
Module 3 (implementation-spring-sca) handles the sca extension to Spring. It
has direct dependencies on Spring jars.
If Spring jars are shipped with Tuscany or a product that embeds Tuscany,
then 3 can be merged with 2.
There is one use case that drives us to have 3 in a separate module. If the
Spring jars are packaged in a JEE application, we need to have
"implementation-spring-sca" on the classpath of the application. In such
deployment, Spring classes are not visible to the Tuscany modules (such as
implementation-spring-runtime). As a result, module 2 talks to module 3
using reflection APIs.
Thanks,
Raymond
--------------------------------------------------
From: "Mike Edwards" <[email protected]>
Sent: Wednesday, May 06, 2009 1:06 PM
To: <[email protected]>
Subject: Re: [2.x] Porting Spring Modules into 2.x
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
