View Full Version : Choosing between SI-1.0.x and 2.0
Nov 29th, 2009, 04:31 AM
I have to decide which version to use for a new project. It is going to be in production in a half year from now. On one hand, the released version of SI is 1.0.3 and it has everything I need for a project. On the other I'd prefer to use Spring 3.0 from the beginning. Can SI-1.0.3 be used with Spring 3.0? How stable is SI-2.0 M1? Do you think SI-2.0 GA can be released before May?
Nov 29th, 2009, 07:19 AM
Yes, we are planning to release 2.0 before May.
SI 1.0.3 was tested with Spring 3.0 as well. At the time it was a milestone build, but should work.
Nov 29th, 2009, 10:19 AM
Also, after 3.0 Final is released, we'll test with 1.0.3 again, and if there are any issues, we'll get 1.0.4 out pretty quickly.
Nov 29th, 2009, 10:24 AM
So I understand that the recommendation is to use SI 1.0.3 and core 3.0. Right?
Nov 29th, 2009, 11:40 AM
I wouldn't go as far as saying that this is "recommendation", but the obvious fact is:
1.0.3 is GA Release, while 2.0 is in its milestones and things obviously could change, however we are planning to include a lot of cool features (e.g., use of SPEL for configuring routers, filters etc... as well as enhanced OSGi support) you might want to start using.
So it depends on how much risk are you willing to take. . .
What I would say is that 1.0.3 is a safer approach ;)
Nov 29th, 2009, 11:44 AM
It's funny I was just about to post my reply below when Oleg's response appeared. I think we are saying similar things....
Of course there are also reasons to consider 2.0 since several new features will be available there - especially those which take full advantage of Spring 3.0 *within* Spring Integration. In other words, rather than just being "compatible" with a 3.0 dependency, SI 2.0 will provide a lot of opportunities for using Spring 3. 0 features (SpEL, REST support, new Task scheduling abstraction, etc.).
On one hand, you might have a slightly bumpier ride since changes in the milestone phases are not always restrained by 100% backwards compatibility. That gives us flexibility to innovate. On the other hand, that price might we worth paying if you would like to help influence that innovation through your feedback as a user. As you know, we're very receptive to such feedback.
So, it probably sounds like I'm avoiding a strong recommendation either way ;) That's because there are tradeoffs. If possible, it would be nice to have a simple flag in your build (e.g. spring-integration.version in maven properties) so that you could easily switch between the two. Of course, that would make it difficult to take advantage of new features, but maybe you could stay on the conservative side at first knowing that it will be easy to switch when we get to a later milestone or release-candidate.
Hope that helps a bit.
Nov 29th, 2009, 01:20 PM
Thank you for the insights!
Nov 30th, 2009, 12:11 AM
About Spring 3.0 - Spring-Int 1.0.3 compatibility: I'm using Spring-Int 1.0.3 and without any problems I've changed dependency from Spring 2.5.6 to 3.0.0.M3 (then RC1 and then RC2) in rather critical project working in production environment. Everything that had to be changed was some Jdbc and Transaction Templates to get rid of warnings connected with generics.
Plus when all you need, Spring-Int 1.0.3 offers I recommend this (my) combination. When Spring-Int 2.0.0 is released you'll sure have no problems migrating.
I've done this many times with Spring - one project was created with Spring 1.0.x and now is working with Spring 3.0.0.RC2 - the only change was the way classes are defined in ResourceBundleViewResolver.
Feb 1st, 2010, 09:42 AM
I am currently investigating this for an important system in our infrastructure. Spring Integration is perfect for our needs (thanks!).
We have a lot of REST calls going out from multiple endpoints and I'd really like to use the REST support from Spring 3.0 to save having to rewrite it down the line. Is Spring Integration 2.0 likely to be stable enough in the next few months to use in a production system?
I will probably have to be conservative as I would guess you don't want to give any guarantees, in which case do you think it would be possible to use SI 1.0.3 with Spring Core 3.0 and write our own endpoints for Spring 3.0 REST support?
Feb 1st, 2010, 09:51 AM
There will be a release of SI 2.0 in the next 2 month, probably earlier. There is not much of a change to the existing functionality, minor improvements to the existing code. Most of what is going on are new features(e.g., use of SpEL) and adapters (e.g., TCP/UDP) and more, so I am pretty sure that it will be as stable as 1.0.3, but then again everything in this world is relative ;)
Feb 1st, 2010, 10:19 AM
Oleg is pretty optimistic ;) ... but to be a bit more conservative, I'd say we'll be reaching 2.0 GA within the first half of 2010.
Can you describe your REST code in a bit more detail? The reason I ask is that if you're using Spring Integration's HTTP endpoints, it will handle inbound as well as outbound REST. Spring Integration 2.0 is being refactored internally to use the Spring 3.0 REST support (and underlying HTTP client code).
Feb 1st, 2010, 11:04 AM
Hi Mark thanks for your very quick responses.
In one of our workflows we will be calling 4 different systems after having consumed a JMS message from a queue. All of these systems require standard REST calls to a different REST API.
We also have other workflows that will call the same systems but call different methods in the same REST APIs.
Another workflow will require us to define a REST API as an input channel which will then route to multiple endpoints (including other REST calls and JMS queues).
I was thinking that the latter scenario (the REST input) would be most easily created by being able to use the Spring 3.0 MVC style REST support.
Maybe I need to RTFM a little better, but I couldn't really see how to use the HTTP endpoints to achieve this.
Feb 1st, 2010, 11:32 AM
As far as the inbound REST API, it really depends on the granularity. Spring Integration would be an option if you simply want to expose a given URL as an inbound "endpoint" and then connect it directly to a router. The idea in 2.0 would be to allow configuration of a Spring 3.0 HttpMessageConverter for that endpoint, and then pass the result to the next channel (which might be the input for a router, etc.).
Does that make sense?
Feb 1st, 2010, 12:00 PM
This is exactly what I would want to do really. We will likely use a RecipientListRouter (or something very similar) and this URL will be a RESTful input for the router. Can you point me to an example of this? The only thing I can think we might want to do before the router is persist for resilience which we will be doing all the way along the chain.
The HttpMessageConverter plan for 2.0 sounds good. Is this implemented in the current milestone?
Powered by vBulletin® Version 4.2.1 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.