You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Ramkumar R <ra...@gmail.com> on 2009/04/22 08:25:05 UTC
[2.x] Porting Spring Modules into 2.x
Hi All,
I have been working on porting the implementation.spring module in 2.x and
have split the modules as implementation.spring,
implementation-spring-runtime and implementation-spring-xml and have also
ported the itest for spring in 2.x.
To successfully run the spring modules with 2.x here are some changes which
would be required... for now I have made these changes locally...
- OASIS version of implementation-spring.xsd is not yet available, so I had
to copy the OSOA version of the XSD and
change the namespace according to OASIS specification.
- Spring Modules uses some of the implementation.java introspecting
techniques by reusing the classes available with
implementation.java available from package
org.apache.tuscany.sca.implementation.java.introspect.impl. This package was
not
exported via the OSGi manifest earlier, so I made this changes locally to
export this package for spring.
Like to know if any one have any issues in makes this changes to 2.x.
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [2.x] Porting Spring Modules into 2.x
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Apr 21, 2009 at 11:39 PM, Ramkumar R <ra...@gmail.com> wrote:
>>
>> This would be ok for now, but the proper fix would be to have pojo
>> related interfaces available in a separated module that could be
>> exported via OSGi and used by all pojo related extensions (e.g java,
>> ejb, spring). I have started doing that in implementation.pojo, but
>> that still need some more work, and then migrate the related
>> extensions to use it.
>
> Hi Luciano,
>
> That seems to be a good idea, as you said that would also benefit the jee
> modules which also needs the java introspecting techniques.
>
> If you wish, I can go ahead and create a seperate module as you have
> suggested.
> As I am currently working in 2.x, there should not be any issue in taking
> this up.
>
+1 on taking this up if you have time, note that implementation.pojo
has some work already started where interfaces/implementations are
available.
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: [2.x] Porting Spring Modules into 2.x
Posted by Ramkumar R <ra...@gmail.com>.
>
>
> This would be ok for now, but the proper fix would be to have pojo
> related interfaces available in a separated module that could be
> exported via OSGi and used by all pojo related extensions (e.g java,
> ejb, spring). I have started doing that in implementation.pojo, but
> that still need some more work, and then migrate the related
> extensions to use it.
>
Hi Luciano,
That seems to be a good idea, as you said that would also benefit the jee
modules which also needs the java introspecting techniques.
If you wish, I can go ahead and create a seperate module as you have
suggested.
As I am currently working in 2.x, there should not be any issue in taking
this up.
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [2.x] Porting Spring Modules into 2.x
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, Apr 22, 2009 at 12:02 AM, ant elder <an...@apache.org> wrote:
>
> Lets not argue if this is going to be changed anyway, but just labeling
> things "breaking" or "hacking" doesn't make it something true. A valid
> export is what *we* decide is what we want the module to export. Any new
> module is going to use exactly the same export.
>
The new module is supposed to provide interfaces and only export those
packages, hiding it' s implementation details from the consumer, which
I think it' s a good modularity practice.
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: [2.x] Porting Spring Modules into 2.x
Posted by ant elder <an...@apache.org>.
On Wed, Apr 22, 2009 at 7:57 AM, Luciano Resende <lu...@gmail.com>wrote:
> On Tue, Apr 21, 2009 at 11:52 PM, ant elder <an...@apache.org> wrote:
> >
> >
> > On Wed, Apr 22, 2009 at 7:50 AM, Luciano Resende <lu...@gmail.com>
> > wrote:
> >>
> >> On Tue, Apr 21, 2009 at 11:37 PM, ant elder <an...@gmail.com>
> wrote:
> >> >
> >> > I don't actually see any serious issues with fixing this by just
> >> > changing
> >> > the export. It doesn't make much difference if the spring extension
> >> > depends
> >> > on implementation-java or implementation-pojo does it?
> >> >
> >>
> >> By doing this, you are allowing modules to have direct dependency on
> >> your implementation artifacts breaking OSGi modularity. As I
> >> mentioned, this would be ok during bring up, but I expect the proper
> >> fix to be available in the future.
> >>
> >
> > Its not "breaking" anything, its going to be depending on the same code
> > whether its in one module or somewhere else.
> >
>
> It' s not breaking because he will be hacking the OSGi manifests,
> which is OK during the bring-up phase, but not as a final solution.
>
>
Lets not argue if this is going to be changed anyway, but just labeling
things "breaking" or "hacking" doesn't make it something true. A valid
export is what *we* decide is what we want the module to export. Any new
module is going to use exactly the same export.
...ant
Re: [2.x] Porting Spring Modules into 2.x
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Apr 21, 2009 at 11:52 PM, ant elder <an...@apache.org> wrote:
>
>
> On Wed, Apr 22, 2009 at 7:50 AM, Luciano Resende <lu...@gmail.com>
> wrote:
>>
>> On Tue, Apr 21, 2009 at 11:37 PM, ant elder <an...@gmail.com> wrote:
>> >
>> > I don't actually see any serious issues with fixing this by just
>> > changing
>> > the export. It doesn't make much difference if the spring extension
>> > depends
>> > on implementation-java or implementation-pojo does it?
>> >
>>
>> By doing this, you are allowing modules to have direct dependency on
>> your implementation artifacts breaking OSGi modularity. As I
>> mentioned, this would be ok during bring up, but I expect the proper
>> fix to be available in the future.
>>
>
> Its not "breaking" anything, its going to be depending on the same code
> whether its in one module or somewhere else.
>
It' s not breaking because he will be hacking the OSGi manifests,
which is OK during the bring-up phase, but not as a final solution.
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: [2.x] Porting Spring Modules into 2.x
Posted by ant elder <an...@apache.org>.
On Wed, Apr 22, 2009 at 7:50 AM, Luciano Resende <lu...@gmail.com>wrote:
> On Tue, Apr 21, 2009 at 11:37 PM, ant elder <an...@gmail.com> wrote:
> >
> > I don't actually see any serious issues with fixing this by just changing
> > the export. It doesn't make much difference if the spring extension
> depends
> > on implementation-java or implementation-pojo does it?
> >
>
> By doing this, you are allowing modules to have direct dependency on
> your implementation artifacts breaking OSGi modularity. As I
> mentioned, this would be ok during bring up, but I expect the proper
> fix to be available in the future.
>
>
Its not "breaking" anything, its going to be depending on the same code
whether its in one module or somewhere else.
...ant
Re: [2.x] Porting Spring Modules into 2.x
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Apr 21, 2009 at 11:37 PM, ant elder <an...@gmail.com> wrote:
>
> I don't actually see any serious issues with fixing this by just changing
> the export. It doesn't make much difference if the spring extension depends
> on implementation-java or implementation-pojo does it?
>
By doing this, you are allowing modules to have direct dependency on
your implementation artifacts breaking OSGi modularity. As I
mentioned, this would be ok during bring up, but I expect the proper
fix to be available in the future.
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: [2.x] Porting Spring Modules into 2.x
Posted by Ramkumar R <ra...@gmail.com>.
On Wed, Apr 22, 2009 at 12:07 PM, ant elder <an...@gmail.com> wrote:
>
>
> On Wed, Apr 22, 2009 at 7:30 AM, Luciano Resende <lu...@gmail.com>wrote:
>
>> On Tue, Apr 21, 2009 at 11:25 PM, Ramkumar R <ra...@gmail.com>
>> wrote:
>> > - Spring Modules uses some of the implementation.java introspecting
>> > techniques by reusing the classes available with
>> > implementation.java available from package
>> > org.apache.tuscany.sca.implementation.java.introspect.impl. This package
>> was
>> > not
>> > exported via the OSGi manifest earlier, so I made this changes locally
>> to
>> > export this package for spring.
>>
>
> Could you commit that change now so we can all see/try it?
>
>
Hi Ant,
I have committed the new schema for spring in 2.x at revision 767393.
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [2.x] Porting Spring Modules into 2.x
Posted by ant elder <an...@gmail.com>.
On Wed, Apr 22, 2009 at 7:30 AM, Luciano Resende <lu...@gmail.com>wrote:
> On Tue, Apr 21, 2009 at 11:25 PM, Ramkumar R <ra...@gmail.com>
> wrote:
> > - Spring Modules uses some of the implementation.java introspecting
> > techniques by reusing the classes available with
> > implementation.java available from package
> > org.apache.tuscany.sca.implementation.java.introspect.impl. This package
> was
> > not
> > exported via the OSGi manifest earlier, so I made this changes locally to
> > export this package for spring.
>
Could you commit that change now so we can all see/try it?
>
> >
> > Like to know if any one have any issues in makes this changes to 2.x.
> >
>
> This would be ok for now, but the proper fix would be to have pojo
> related interfaces available in a separated module that could be
> exported via OSGi and used by all pojo related extensions (e.g java,
> ejb, spring). I have started doing that in implementation.pojo, but
> that still need some more work, and then migrate the related
> extensions to use it.
>
>
I don't actually see any serious issues with fixing this by just changing
the export. It doesn't make much difference if the spring extension depends
on implementation-java or implementation-pojo does it?
...ant
Re: [2.x] Porting Spring Modules into 2.x
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Apr 21, 2009 at 11:25 PM, Ramkumar R <ra...@gmail.com> wrote:
> - Spring Modules uses some of the implementation.java introspecting
> techniques by reusing the classes available with
> implementation.java available from package
> org.apache.tuscany.sca.implementation.java.introspect.impl. This package was
> not
> exported via the OSGi manifest earlier, so I made this changes locally to
> export this package for spring.
>
> Like to know if any one have any issues in makes this changes to 2.x.
>
This would be ok for now, but the proper fix would be to have pojo
related interfaces available in a separated module that could be
exported via OSGi and used by all pojo related extensions (e.g java,
ejb, spring). I have started doing that in implementation.pojo, but
that still need some more work, and then migrate the related
extensions to use it.
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: [2.x] Porting Spring Modules into 2.x
Posted by Mike Edwards <mi...@gmail.com>.
Ramkumar R wrote:
>
>
> Hi Mike,
>
> Thanks for fixes, to make it work in the OSGi environment.
>
> I noticed that, you have made changes to SpringImplementation class
> which was implementing the
> org.apache.tuscany.sca.assembly.builder.ComponentPreProcessor. This one
> is very much needed to map the SCA references with
> spring in case of un-annotated implementation. So I believe we might
> need to put them back in place.
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
Ram,
OK, I'll put it back.
Thanks for the explanation.
Yours, Mike.
Re: [2.x] Porting Spring Modules into 2.x
Posted by Ramkumar R <ra...@gmail.com>.
On Fri, Apr 24, 2009 at 3:00 PM, Mike Edwards <
mike.edwards.inglenook@gmail.com> wrote:
>
> Ram,
>
> I made a couple of fixes and changes that enables all 3 Spring modules to
> work correctly under OSGi in 2.x.
>
> Principally, the adjustments were to the manifest files, to ensure that all
> dependencies were correct. However, I also discovered that the
> SpringImplementation class was implementing an unnecessary interface and I
> removed that.
>
>
> Yours, Mike.
>
Hi Mike,
Thanks for fixes, to make it work in the OSGi environment.
I noticed that, you have made changes to SpringImplementation class which
was implementing the
org.apache.tuscany.sca.assembly.builder.ComponentPreProcessor. This one is
very much needed to map the SCA references with
spring in case of un-annotated implementation. So I believe we might need to
put them back in place.
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [2.x] Porting Spring Modules into 2.x
Posted by Mike Edwards <mi...@gmail.com>.
Ramkumar R wrote:
> Hi All,
>
> I have been working on porting the implementation.spring module in 2.x
> and have split the modules as implementation.spring,
> implementation-spring-runtime and implementation-spring-xml and have
> also ported the itest for spring in 2.x.
>
> To successfully run the spring modules with 2.x here are some changes
> which would be required... for now I have made these changes locally...
>
> - OASIS version of implementation-spring.xsd is not yet available, so I
> had to copy the OSOA version of the XSD and
> change the namespace according to OASIS specification.
>
> - Spring Modules uses some of the implementation.java introspecting
> techniques by reusing the classes available with
> implementation.java available from package
> org.apache.tuscany.sca.implementation.java.introspect.impl. This package
> was not
> exported via the OSGi manifest earlier, so I made this changes locally
> to export this package for spring.
>
> Like to know if any one have any issues in makes this changes to 2.x.
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
Ram,
I made a couple of fixes and changes that enables all 3 Spring modules to work correctly under OSGi
in 2.x.
Principally, the adjustments were to the manifest files, to ensure that all dependencies were
correct. However, I also discovered that the SpringImplementation class was implementing an
unnecessary interface and I removed that.
Yours, Mike.
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
>
Re: [2.x] Porting Spring Modules into 2.x
Posted by Raymond Feng <en...@gmail.com>.
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 Ramkumar R <ra...@gmail.com>.
On Fri, Apr 24, 2009 at 3:04 PM, Mike Edwards <
mike.edwards.inglenook@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>.
Luciano Resende wrote:
> On Tue, Apr 21, 2009 at 11:57 PM, ant elder <an...@apache.org> wrote:
>>> Hi Ant,
>>>
>>> I always thought having xxxx-xml module as a good approach, in terms of
>>> spring I see this module as independent module without any dependencies from
>>> spring binaries. Are we following any nomenclature to split the modules? may
>>> be I am not aware.
>>>
>
> +1, embedders and tolling guys such as Eclipse STP can use our modules
> without any extra dependencies which is a good thing....
>
>> I think we did decide to change to the two module approach, there is no real
>> benefit for keeping them separate, I'll go attempt to find an email where
>> this was decided, (not sure how successful that will be as it was sometime
>> ago and might be hard to find searching for -xml).
>>
>
> There is no real benefit on the app development scenarios we (tuscany
> developers) usually work on our day to day development tasks...
>
> For now, as spring is already using -xml, I'd leave like this and use
> another thread to come to a conclusion on this.
>
>
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.
Re: [2.x] Porting Spring Modules into 2.x
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Apr 21, 2009 at 11:57 PM, ant elder <an...@apache.org> wrote:
>> Hi Ant,
>>
>> I always thought having xxxx-xml module as a good approach, in terms of
>> spring I see this module as independent module without any dependencies from
>> spring binaries. Are we following any nomenclature to split the modules? may
>> be I am not aware.
>>
+1, embedders and tolling guys such as Eclipse STP can use our modules
without any extra dependencies which is a good thing....
>
> I think we did decide to change to the two module approach, there is no real
> benefit for keeping them separate, I'll go attempt to find an email where
> this was decided, (not sure how successful that will be as it was sometime
> ago and might be hard to find searching for -xml).
>
There is no real benefit on the app development scenarios we (tuscany
developers) usually work on our day to day development tasks...
For now, as spring is already using -xml, I'd leave like this and use
another thread to come to a conclusion on this.
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: [2.x] Porting Spring Modules into 2.x
Posted by ant elder <an...@apache.org>.
On Wed, Apr 22, 2009 at 7:50 AM, Ramkumar R <ra...@gmail.com> wrote:
> On Wed, Apr 22, 2009 at 12:09 PM, ant elder <an...@gmail.com> wrote:
>
>>
>> It looks good to me, i think its great to have spring working in 2.x. Add
>> it to the build!
>>
>> I'd prefer if the imlementation-spring-xml module was merged into
>> implementation-spring as thats the pattern i thought we are using now for
>> these.
>>
>> ...ant
>>
>>
>
> Hi Ant,
>
> I always thought having xxxx-xml module as a good approach, in terms of
> spring I see this module as independent module without any dependencies from
> spring binaries. Are we following any nomenclature to split the modules? may
> be I am not aware.
>
>
I think we did decide to change to the two module approach, there is no real
benefit for keeping them separate, I'll go attempt to find an email where
this was decided, (not sure how successful that will be as it was sometime
ago and might be hard to find searching for -xml).
...ant
Re: [2.x] Porting Spring Modules into 2.x
Posted by Ramkumar R <ra...@gmail.com>.
On Wed, Apr 22, 2009 at 12:09 PM, ant elder <an...@gmail.com> wrote:
>
> It looks good to me, i think its great to have spring working in 2.x. Add
> it to the build!
>
> I'd prefer if the imlementation-spring-xml module was merged into
> implementation-spring as thats the pattern i thought we are using now for
> these.
>
> ...ant
>
>
Hi Ant,
I always thought having xxxx-xml module as a good approach, in terms of
spring I see this module as independent module without any dependencies from
spring binaries. Are we following any nomenclature to split the modules? may
be I am not aware.
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [2.x] Porting Spring Modules into 2.x
Posted by ant elder <an...@gmail.com>.
On Wed, Apr 22, 2009 at 7:25 AM, Ramkumar R <ra...@gmail.com> wrote:
> Hi All,
>
> I have been working on porting the implementation.spring module in 2.x and
> have split the modules as implementation.spring,
> implementation-spring-runtime and implementation-spring-xml and have also
> ported the itest for spring in 2.x.
>
> To successfully run the spring modules with 2.x here are some changes which
> would be required... for now I have made these changes locally...
>
> - OASIS version of implementation-spring.xsd is not yet available, so I had
> to copy the OSOA version of the XSD and
> change the namespace according to OASIS specification.
>
> - Spring Modules uses some of the implementation.java introspecting
> techniques by reusing the classes available with
> implementation.java available from package
> org.apache.tuscany.sca.implementation.java.introspect.impl. This package was
> not
> exported via the OSGi manifest earlier, so I made this changes locally to
> export this package for spring.
>
> Like to know if any one have any issues in makes this changes to 2.x.
>
>
It looks good to me, i think its great to have spring working in 2.x. Add it
to the build!
I'd prefer if the imlementation-spring-xml module was merged into
implementation-spring as thats the pattern i thought we are using now for
these.
...ant