You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2009/05/06 00:32:36 UTC
Re: [2.x] Porting Spring Modules into 2.x
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: dev@tuscany.apache.org
Subject: Re: [2.x] Porting Spring Modules into 2.x
On Fri, Apr 24, 2009 at 3:04 PM, Mike Edwards <mi...@gmail.com> 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
Re: [2.x] Porting Spring Modules into 2.x
Posted by ant elder <an...@apache.org>.
On Wed, May 6, 2009 at 8:37 AM, Ramkumar R <ra...@gmail.com> wrote:
> I am planning to do the refactoring of spring module in 1.x code similar to
> what we have in 2.x. But for the time being, I would like to keep the
> existing spring module in 1.x by renaming it as implementation-spring-old.
>
> Please let me know if there are any concerns, in keeping the old code.
>
Seems ok to me as a point in time thing.
...ant
Re: [2.x] Porting Spring Modules into 2.x
Posted by Ramkumar R <ra...@gmail.com>.
I am planning to do the refactoring of spring module in 1.x code similar to
what we have in 2.x. But for the time being, I would like to keep the
existing spring module in 1.x by renaming it as implementation-spring-old.
Please let me know if there are any concerns, in keeping the old code.
On Wed, May 6, 2009 at 12:41 PM, ant elder <an...@gmail.com> wrote:
> 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 <en...@gmail.com> 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: dev@tuscany.apache.org
> > Subject: Re: [2.x] Porting Spring Modules into 2.x
> >
> > On Fri, Apr 24, 2009 at 3:04 PM, Mike Edwards
> > <mi...@gmail.com> 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
> >
>
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [2.x] Porting Spring Modules into 2.x
Posted by Ramkumar R <ra...@gmail.com>.
On Wed, May 6, 2009 at 9:26 PM, Raymond Feng <en...@gmail.com> 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)
>
>
I agree with you Raymond, I shall make the necessary changes as you have
suggested above.
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [2.x] Porting Spring Modules into 2.x
Posted by ant elder <an...@gmail.com>.
On Wed, May 6, 2009 at 9:06 PM, Mike Edwards
<mi...@gmail.com> wrote:
> Folks,
>
> Whoa there. Lets not go rushing off to implement something without some
> agreement about it, please.
>
Big +1 to that.
...ant
Re: [2.x] Porting Spring Modules into 2.x
Posted by ant elder <an...@gmail.com>.
>From whats been said so far I'd prefer to keep the two modules named
implementation-spring and implementation-spring-runtime. Comments
below.
...ant
On Wed, May 6, 2009 at 9:38 PM, Raymond Feng <en...@gmail.com> wrote:
> 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.
>
The modules already work fine like that - all the runtime dependencies
are in the -runtime module so nothing is dragged in when using just
the implementation-spring module. So splitting the module into two
doesn't appear to provide any benefits and just adds complexity.
Having as few modules as possible makes Tuscany simpler to user.
Having a consistent module naming pattern makes Tuscany simpler to
use. It can be hard to work out what modules are needed when using an
extension, consistent naming using the -runtime suffix helps make that
simple - you want to use the SCA Spring implementation then you
include implementation-spring-runtime - thats quite easy to work out
once you're used to the Tuscany naming conventions so I don't think we
should break it without good reason.
...ant
Re: [2.x] Porting Spring Modules into 2.x
Posted by ant elder <an...@gmail.com>.
That sounds fine to me
...ant
On Thu, May 7, 2009 at 11:41 AM, Ramkumar R <ra...@gmail.com> wrote:
> I believe, this debate is growing and yet to settle with an agreement. While
> the debate is still on....
>
> I would like to propose this....
>
> For 1.x lets stick to the model of having 2 modules... implementation-spring
> and implementation-spring-runtime as what we have currently. As we are
> expecting any major changes with 1.x after this point of time.
>
> For 2.x, we can still keep the debate on and make changes according to the
> agreement we come up in relation to Tuscany structure.
>
>
> On Thu, May 7, 2009 at 3:10 PM, Mike Edwards
> <mi...@gmail.com> wrote:
>>
>> Raymond,
>>
>> Some comments here, which relate to a bigger debate that is going on in
>> relation to Tuscany structure.
>>
>> Raymond Feng wrote:
>>>
>>> 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.
>>>
>>
>> This sounds like a good principle, since it might seem that by NOT
>> separating "model" and "runtime" code, that tools folk would be pulling in
>> some huge pile of "runtime" code that they don't need.
>>
>> However, I note that the TOTAL size of the Spring related Tuscany code is
>> 64K + 13K = 77K. The potential saving to tooling guys is actually very
>> small. As long as the "runtime" Tuscany Spring classes don't bring in the
>> actual Spring runtime itself unless asked to run an implementation, then
>> there is actually little benefit to the tools folks in this instance.
>>
>> So in the case of implementation-spring I'm not convinced about this
>> separation of 1 & 2. In other cases, where the code in 2 is substantial, I
>> can see the point. I can also see a point where there is the need for
>> pluggability of 2 in the case of multiple alternative runtimes. But neither
>> of those apply to implementation-spring.
>>
>> Meanwhile there are very real costs to having extra modules to keep track
>> of. So I think in this case, it is better to combine 1 & 2 into a single
>> module.
>>
>>
>>> 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.
>>
>> I'm not so convinced about that, since the files in 3 are very much linked
>> to the Spring code - and in an OSGi world, coupling between Spring and the
>> stuff in 2 is undesirable and unnecessary.
>>
>>>
>>> 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
>>
>>
>> Yours, Mike.
>
>
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>
Re: [2.x] Porting Spring Modules into 2.x
Posted by Simon Laws <si...@googlemail.com>.
On Thu, May 7, 2009 at 11:41 AM, Ramkumar R <ra...@gmail.com> wrote:
> I believe, this debate is growing and yet to settle with an agreement. While
> the debate is still on....
>
> I would like to propose this....
>
> For 1.x lets stick to the model of having 2 modules... implementation-spring
> and implementation-spring-runtime as what we have currently. As we are
> expecting any major changes with 1.x after this point of time.
>
> For 2.x, we can still keep the debate on and make changes according to the
> agreement we come up in relation to Tuscany structure.
>
>
+1
Simon
Re: [2.x] Porting Spring Modules into 2.x
Posted by Ramkumar R <ra...@gmail.com>.
I believe, this debate is growing and yet to settle with an agreement. While
the debate is still on....
I would like to propose this....
For 1.x lets stick to the model of having 2 modules... implementation-spring
and implementation-spring-runtime as what we have currently. As we are
expecting any major changes with 1.x after this point of time.
For 2.x, we can still keep the debate on and make changes according to the
agreement we come up in relation to Tuscany structure.
On Thu, May 7, 2009 at 3:10 PM, Mike Edwards <
mike.edwards.inglenook@gmail.com> wrote:
> Raymond,
>
> Some comments here, which relate to a bigger debate that is going on in
> relation to Tuscany structure.
>
> Raymond Feng wrote:
>
>> 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.
>>
>>
> This sounds like a good principle, since it might seem that by NOT
> separating "model" and "runtime" code, that tools folk would be pulling in
> some huge pile of "runtime" code that they don't need.
>
> However, I note that the TOTAL size of the Spring related Tuscany code is
> 64K + 13K = 77K. The potential saving to tooling guys is actually very
> small. As long as the "runtime" Tuscany Spring classes don't bring in the
> actual Spring runtime itself unless asked to run an implementation, then
> there is actually little benefit to the tools folks in this instance.
>
> So in the case of implementation-spring I'm not convinced about this
> separation of 1 & 2. In other cases, where the code in 2 is substantial, I
> can see the point. I can also see a point where there is the need for
> pluggability of 2 in the case of multiple alternative runtimes. But neither
> of those apply to implementation-spring.
>
> Meanwhile there are very real costs to having extra modules to keep track
> of. So I think in this case, it is better to combine 1 & 2 into a single
> module.
>
>
> 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.
>>
>
> I'm not so convinced about that, since the files in 3 are very much linked
> to the Spring code - and in an OSGi world, coupling between Spring and the
> stuff in 2 is undesirable and unnecessary.
>
>
>> 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
>>
>
>
> Yours, Mike.
>
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [2.x] Porting Spring Modules into 2.x
Posted by ant elder <an...@gmail.com>.
On Thu, May 7, 2009 at 6:40 PM, Mike Edwards
<mi...@gmail.com> wrote:
> OK, so this is getting towards the heart of the matter.
>
> Can we be clear about what "runtime dependencies" are the issue here.
>
> Do you have a clearly defined set of dependencies which are acceptable for
> tooling use, and a set which are regarded as "runtime" and are unacceptable?
>
If we could establish this i think it will help immensely. And we
could write a testcase using some contributions containing artifacts
for all the extensions we have which reads/writes the models, verifies
it looks ok, and then verifies the dependencies used are only the
non-runtime ones. I'd be happy to volunteer to write such a testcase
if we can come up with this list of dependencies
...ant
Re: [2.x] Porting Spring Modules into 2.x
Posted by Mike Edwards <mi...@gmail.com>.
Hi Raymond,
Good debate - and I'm not unsympathetic - some comments below.
Yours, Mike.
Raymond Feng wrote:
> See my comments below.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "Mike Edwards" <mi...@gmail.com>
> Sent: Thursday, May 07, 2009 2:40 AM
> To: <de...@tuscany.apache.org>
> Subject: Re: [2.x] Porting Spring Modules into 2.x
>
>> Raymond,
>>
>> Some comments here, which relate to a bigger debate that is going on
>> in relation to Tuscany structure.
>>
>> Raymond Feng wrote:
>>> 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.
>>>
>>
>> This sounds like a good principle, since it might seem that by NOT
>> separating "model" and "runtime" code, that tools folk would be
>> pulling in some huge pile of "runtime" code that they don't need.
>>
>> However, I note that the TOTAL size of the Spring related Tuscany code
>> is 64K + 13K = 77K. The potential saving to tooling guys is actually
>> very small. As long as the "runtime" Tuscany Spring classes don't
>> bring in the actual Spring runtime itself unless asked to run an
>> implementation, then there is actually little benefit to the tools
>> folks in this instance.
>
> The size is not the big concern. What worries me is the dependency. For
> example, if we combine module 1
> and module 2, extra "runtime" packages have to be added to the
> "Import-Package" header for the OSGi
> bundle. As a result, the bundle cannot be resolved unless we have the
> "runtime" Tuscany bundles in the tooling
> environment such as Eclipse.
>
OK, so this is getting towards the heart of the matter.
Can we be clear about what "runtime dependencies" are the issue here.
Do you have a clearly defined set of dependencies which are acceptable for tooling use, and a set
which are regarded as "runtime" and are unacceptable?
>>
>> So in the case of implementation-spring I'm not convinced about this
>> separation of 1 & 2. In other cases, where the code in 2 is
>> substantial, I can see the point. I can also see a point where there
>> is the need for pluggability of 2 in the case of multiple alternative
>> runtimes. But neither of those apply to implementation-spring.
>>
>> Meanwhile there are very real costs to having extra modules to keep
>> track of. So I think in this case, it is better to combine 1 & 2 into
>> a single module.
>>
>
> I'm looking for packaging consistency for all extensions added to
> Tuscany. That's why I proposed to rename
> "implementation-spring-runtime" to "implementation-spring-sca" as we
> always use the "-runtime" prefix for
> modules that contain "runtime" pieces (such as the Provider) of extensions.
>
> IMO, module 2 is tied to module 3 and it really has dependencies on
> module 3. Using Class.forName() just hides that.
> Without module 3, module 2 is useless.
>
I agree that Module 2 is unusuable without module 3, but module 3 depends on a load of Spring stuff
too. Combining 2 & 3 makes no more sense than combining 3 with Spring itself.
I have no problem with the renaming of module 3.
>>
>>> 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.
>>
>> I'm not so convinced about that, since the files in 3 are very much
>> linked to the Spring code - and in an OSGi world, coupling between
>> Spring and the stuff in 2 is undesirable and unnecessary.
>>
>>>
>>> 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
>>
>>
>> Yours, Mike.
>
>
Re: [2.x] Porting Spring Modules into 2.x
Posted by Raymond Feng <en...@gmail.com>.
See my comments below.
Thanks,
Raymond
--------------------------------------------------
From: "Mike Edwards" <mi...@gmail.com>
Sent: Thursday, May 07, 2009 2:40 AM
To: <de...@tuscany.apache.org>
Subject: Re: [2.x] Porting Spring Modules into 2.x
> Raymond,
>
> Some comments here, which relate to a bigger debate that is going on in
> relation to Tuscany structure.
>
> Raymond Feng wrote:
>> 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.
>>
>
> This sounds like a good principle, since it might seem that by NOT
> separating "model" and "runtime" code, that tools folk would be pulling in
> some huge pile of "runtime" code that they don't need.
>
> However, I note that the TOTAL size of the Spring related Tuscany code is
> 64K + 13K = 77K. The potential saving to tooling guys is actually very
> small. As long as the "runtime" Tuscany Spring classes don't bring in the
> actual Spring runtime itself unless asked to run an implementation, then
> there is actually little benefit to the tools folks in this instance.
The size is not the big concern. What worries me is the dependency. For
example, if we combine module 1
and module 2, extra "runtime" packages have to be added to the
"Import-Package" header for the OSGi
bundle. As a result, the bundle cannot be resolved unless we have the
"runtime" Tuscany bundles in the tooling
environment such as Eclipse.
>
> So in the case of implementation-spring I'm not convinced about this
> separation of 1 & 2. In other cases, where the code in 2 is substantial,
> I can see the point. I can also see a point where there is the need for
> pluggability of 2 in the case of multiple alternative runtimes. But
> neither of those apply to implementation-spring.
>
> Meanwhile there are very real costs to having extra modules to keep track
> of. So I think in this case, it is better to combine 1 & 2 into a single
> module.
>
I'm looking for packaging consistency for all extensions added to Tuscany.
That's why I proposed to rename
"implementation-spring-runtime" to "implementation-spring-sca" as we always
use the "-runtime" prefix for
modules that contain "runtime" pieces (such as the Provider) of extensions.
IMO, module 2 is tied to module 3 and it really has dependencies on module
3. Using Class.forName() just hides that.
Without module 3, module 2 is useless.
>
>> 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.
>
> I'm not so convinced about that, since the files in 3 are very much linked
> to the Spring code - and in an OSGi world, coupling between Spring and the
> stuff in 2 is undesirable and unnecessary.
>
>>
>> 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
>
>
> Yours, Mike.
Re: [2.x] Porting Spring Modules into 2.x
Posted by Mike Edwards <mi...@gmail.com>.
Raymond,
Some comments here, which relate to a bigger debate that is going on in relation to Tuscany structure.
Raymond Feng wrote:
> 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.
>
This sounds like a good principle, since it might seem that by NOT separating "model" and "runtime"
code, that tools folk would be pulling in some huge pile of "runtime" code that they don't need.
However, I note that the TOTAL size of the Spring related Tuscany code is 64K + 13K = 77K. The
potential saving to tooling guys is actually very small. As long as the "runtime" Tuscany Spring
classes don't bring in the actual Spring runtime itself unless asked to run an implementation, then
there is actually little benefit to the tools folks in this instance.
So in the case of implementation-spring I'm not convinced about this separation of 1 & 2. In other
cases, where the code in 2 is substantial, I can see the point. I can also see a point where there
is the need for pluggability of 2 in the case of multiple alternative runtimes. But neither of
those apply to implementation-spring.
Meanwhile there are very real costs to having extra modules to keep track of. So I think in this
case, it is better to combine 1 & 2 into a single module.
> 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.
I'm not so convinced about that, since the files in 3 are very much linked to the Spring code - and
in an OSGi world, coupling between Spring and the stuff in 2 is undesirable and unnecessary.
>
> 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
Yours, Mike.
Re: [2.x] Porting Spring Modules into 2.x
Posted by Raymond Feng <en...@gmail.com>.
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" <mi...@gmail.com>
Sent: Wednesday, May 06, 2009 1:06 PM
To: <de...@tuscany.apache.org>
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" <an...@gmail.com>
>> Sent: Wednesday, May 06, 2009 12:11 AM
>> To: <de...@tuscany.apache.org>
>> 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 <en...@gmail.com>
>>> 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: dev@tuscany.apache.org
>>>> Subject: Re: [2.x] Porting Spring Modules into 2.x
>>>>
>>>> On Fri, Apr 24, 2009 at 3:04 PM, Mike Edwards
>>>> <mi...@gmail.com> 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
>>>>
>>
>
Re: [2.x] Porting Spring Modules into 2.x
Posted by Mike Edwards <mi...@gmail.com>.
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" <an...@gmail.com>
> Sent: Wednesday, May 06, 2009 12:11 AM
> To: <de...@tuscany.apache.org>
> 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 <en...@gmail.com>
>> 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: dev@tuscany.apache.org
>>> Subject: Re: [2.x] Porting Spring Modules into 2.x
>>>
>>> On Fri, Apr 24, 2009 at 3:04 PM, Mike Edwards
>>> <mi...@gmail.com> 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
>>>
>
Re: [2.x] Porting Spring Modules into 2.x
Posted by Raymond Feng <en...@gmail.com>.
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" <an...@gmail.com>
Sent: Wednesday, May 06, 2009 12:11 AM
To: <de...@tuscany.apache.org>
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 <en...@gmail.com> 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: dev@tuscany.apache.org
>> Subject: Re: [2.x] Porting Spring Modules into 2.x
>>
>> On Fri, Apr 24, 2009 at 3:04 PM, Mike Edwards
>> <mi...@gmail.com> 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
>>
Re: [2.x] Porting Spring Modules into 2.x
Posted by ant elder <an...@gmail.com>.
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 <en...@gmail.com> 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: dev@tuscany.apache.org
> Subject: Re: [2.x] Porting Spring Modules into 2.x
>
> On Fri, Apr 24, 2009 at 3:04 PM, Mike Edwards
> <mi...@gmail.com> 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
>