i'm at my new job and the projects at work are in spring 2.5 (some portlets). how hard is it to migrate to spring 3 ?
there is a customized portal 1.0 (don't know if this is relevant) and i was wondering if i could just ask to develop in spring 3.
never used spring before and want to learn some, but it would be nice if i could just go for the latest version. got spring in action 3rd edition and would like to make use of that
It principle, it should be a drop-in replacement. There's a bunch of stuff that was deprecated in Spring 3, and huge amount of new stuff added, but nothing was removed.
However, there were a bunch of minor bug fixes, and your code may be unwittingly relying on the buggy behaviour, so some minor adjustments may be necessary, but nothing any worse than that.
Other than that, the big difference is that Spring 3 requires Java5+. I'm assuming you're not stuck on 1.4 :)
Related
why I have spend some extra effort to migrate my application if I'm not using new features of latest version
You don't have to upgrade, but I'd say it's worth it for 2 reasons:
Performance and security upgrades of Spring and other dependencies is always a worthwhile effort in my opinion. By skipping upgrades you could be using vulnerable packages.
What happens in a year if you do need a new feature or need to migrate to JDK 11 and beyond? It's typically easier to do the incremental updates multiple times per year rather than a big-bang upgrade every couple of years.
I know the title may seem like apples & oranges, but hear me out... :)
I'm building the architecture of an MVC app and considering what to use for the core of the controller / services. This stack will also serve as a RESTful API which will be equally as important as the UI.
I'm narrowing down my stack to be built with either Grails or JAX-RS (at this point I've ruled out other options and am not super interested in expanding this list). Either way I'll be using Groovy, and my model and views will be virtually unaffected by this choice, so that further levels some of the differences between the two. Here are the pros/cons that I've been pondering and was wondering if anyone had any other inputs or caveat experiences.
Grails
I am not going to use a ton of the built-in Grails features (GSP/SiteMesh, Hibernate, nearly all plugins), so I'm concerned that Grails might be a bit heavy for my purposes
I'm concerned that I won't have enough control over my ability to handle the REST API since it is very view-centric
I've seen inconsistencies in the quality of plugins to the point where I'm not sure I consider them much of a 'pro'
I love the convention-over-configuration & edit-and-refresh, to the point where I'd probably want to wire up something similar if I go with JAX-RS
I like the grails command line for everything it streamlines, but I'm concerned that it might get in my way since I'm not using as much of the stack
I like the scaffolding but since I'm not using Hibernate or GSP/SiteMesh it might not mesh well
JAX-RS
JAX-RS is made for REST. This will make my RESTful API really a snap to implement as I have complete control
Groovy is an important part of what makes Grails shine, so I'll benefit from that even in JAX-RS
I love how JAX-RS doesn't automatically pull in a bunch of other things so I can have more control of what components are in/out
unfortunately since it doesn't pull in everything else anything that I end up needing will require more work, whereas Grails might have a plugin
the grails command line and scaffolding will be missed; perhaps Maven can fill some gaps
It seems like the capabilities of each for creating actions and routing are pretty similar (although the implementation styles are different). In fact there are other SO questions wish touch upon this so I'm not too concerned.
I wrote a small REST service prototype in several frameworks last year (namely Grails, Play!, Spring MVC, Jersey, Restlet). My feeling about Grails in this concern was that although Grails supports REST style architecture, it isn't really made for it. I don't want to get religious here, so if you only want to map resources to URLs and HTTP verbs your fine, but if you want to dig deeper into REST with tight control over return codes, location headers, etc. you might still be able to do it with Grails, but it is probably better supported in a pure REST framework.
Grails also comes with a lot of dependencies, which might not be a problem if you're starting on a green field, but can cause problems when you have to integrate it with existing legacy components or frameworks.
From the two used REST frameworks, I liked Jersey more, as it just worked in my case and the documentation was good (although a bit focused on Maven and Netbeans).
Yeah, it does seem heavy to build on a MVC framework when you're not going to use the model or the view. While the autowiring and simplified configuration is super nice, Grails would still be providing a lot of extra stuff that you don't need.
I'd personally take the lighter approach and leave Grails out, using any standalone libraries or writing custom code which provide the features that you do want. There's a number of container projects listed on the Groovy site, perhaps Spring or one of the alternatives would add some value to your architecture.
I'm learning Java EE 6. I've seen how much progress it has achieved in this release of the umbrella specification. EJBs 3.1 are far easier and more lightweight than previous versions, and CDI is amazing.
I'm not familiar with Spring, but I often read that it offered some neat features that the Java EE stack didn't. Yet I also read now that Java EE has caught up, and can now fully compete with Spring.
I know that choosing from both depends on many factors, but if we only focus on features, say the latest trends etc. Which one has the leading edge? Can Spring 3 offer some assets The Java EE 6 stack can't?
Also, what about Seam framework? From what I read it's like Java EE 6 but with some additions?
Over time, JavaEE indeed caught up in terms of features.
But one factor, that I've stumbled upon many times, is the main reason I've been preferring spring for a long time - JavaEE servers and implementations are buggy and developer-unfriendly. This may sound like a rant, but even the best of JavaEE 6 - CDI (Weld impl) has cryptic exception messages and is giving developers a hard time (see here). Not to mention application servers - full of really ugly bugs (I managed to find around 5 bugs for 3 hours working with JBoss 5)
Another thing that makes spring more attractive for me is that features can be added in small timeframes. As I noted in my comment, unified cache abstraction, and conversation handling will be added in the next release of spring, which is a couple of months after the previous version. In JavaEE you'd have to wait a lot of time (for a standard solution at least)
But it's not that black with JavaEE. Many of the problems have workarounds or get fixed in a timely manner. And ultimately, it's a matter of personal preference.
By the way, spring's portfolio was filled with side-projects in the meantime, which add a lot of specific features/features sets. Note that many of them can be used with JavaEE as well, but are designed to fit perfectly with spring:
spring security - declarative security
spring roo - a tool for quick bootstrapping projects
spring web flow - framework ontop of MVC to handle wizard-likes journeyes
spring data - still new, aimed at unifying access to NoSQL stores
spring mobile - bringing spring to mobile platforms
spring social - a set of tools for interacting with social networks
This is just extras, and JavaEE also has extras, but they are more general-purpose (as far as I see the picture), apart from Seam, which is specifically targeted at providing what CDI misses.
One very important note to conclude with. Comparing spring to JavaEE is incorrect. I'd prefer to compare Spring to CDI+EJB+Application server. The rest of JavaEE can be used together with spring, and it often is. JAX-WS, JAXB, even JSF fit nicely with spring and are often used.
I am just starting to learn about spring and was looking at the difference between Spring 3.0 and Spring 2.5.
Initially i was following this tutorial http://static.springsource.org/docs/Spring-MVC-step-by-step/index.html which is a step by step guide to developing a Spring MVC application. It is based on Spring 2.5 and i notice there are quite a few differences with Spring 3.0. I tried to find the equivalent tutorial that is based on 3.0 but couldnt find it.
The difference i notice with 3.0 is that there is a lot of use of annotations and a lot of things is done for you in the background. I am sure this is a good thing but i am wondering for the purpose of learning the framework should i continue with 2.5 so that i can understand what goes on behind the scenes before i use spring 3.0?
Please also if you can recommend a spring book that is suitable for a beginner i would appreciate it.
Thanks
I'd recommend to always use the latest version of a framework. Especially if you're starting on a new project. There are always (well usually) tons of improvements, and simplifications, and migrating to the latest version later may be a pain.
Spring has a great user manual (see http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/), and IMHO a book doesn't have an added value in this case. I found the Spring user manual always easy to read and understand, so don't get intimidated. I think this is definitely the best starting for beginners as well. You don't have to read it all. Only the sections of interest!
Note that Spring 3.x contains many other improvements such as SpEL (Spring Expression Language), improved web support (you already saw that), REST support, and more.
... should i continue with 2.5 so that i can understand what goes on behind the scenes before i use spring 3.0?
That's really up to you to decide, but if you are going down the Spring 3.x annotation-based route, it is not clear that you >>need<< to understand what is happening behind the scenes. Especially for run-of-the-mill applications.
I was not aware of the purchase of Spring by VMware. Do you think this might affect the open source aspect of Spring in that it might not be open source anymore?
First, the SpringFramework guys are thoroughly committed to open source (from what I can see). So a change would probably entail lots of developers leaving.
Second, most of the people who use Spring do so because it is open source, so a change would risk a major migration of (paying) customers away.
Third, turning Spring into a closed source product would be a politically awful move for VMware, and would likely have fallout for other VMware product lines.
Finally, and most importantly for people committed to using Spring: there is no way that the VMware could legally "undo" the open sourcing of current Spring releases. The best they could do would be say that Spring 4.0 etc was closed source. Anyone who wanted to would be free to continue distributing and using SpringFramework 1.0.x, 2.0.x, 2.5.x, 3.0.x and all associated open sourced technologies. And anyone would be free to create a "fork" of any of them to continue Spring open source development. The only possible issue would be the use of trademarks, and that is easily worked around.
Add that all up, and (IMO) there is nothing to worry about.
"Spring in Action", "Pro Spring", and "Spring Recipes" are the three that I'd recommend to anyone.
If you've never used Spring, I'd say that learning either one will suit your purposes. The majority of Spring 2.5 carries over to 3.0, so it's not wasted.
The books and tutorials haven't kept up with Spring 3.0. Another change between versions was the purchase of Spring by VMWare. They've separated paid support from open source, so it's hard to tell what the future will be for non-paying customers.
Spring roo is new framework and I found it very interesting. I have been working on web application for last 3-4 years and Always found JSPs are hard to maintain across teams if everyone is not disciplined enough about separation of markup and serverside logic. I have used JackBe/BackBase in last projects and I enjoyed xml templates working as views. This was much better than JSPs. But I couldnt automate webtests through selenium for backbase.
I would be surely using Spring MVC (-view), Hibernate on the backend. I found Wicket as good alternative. Have you used wicket along with Spring and what was your experience?
First, Spring Roo is a code generator tool (similar to Grails commands system):
(source: springsource.com)
Second, Spring Roo applications currently use Spring Web Flow for the view and Spring for the glue.
So, while you can compare (Spring Web Flow + Spring) and (Wicket + Spring), the later combo doesn't offer anything comparable to Roo out of the box (maybe AppFuse or AppFuse Light but you didn't mention them and they are third-party projects).
In other words, I don't think that "Spring Roo vs (Wicket and Spring)" makes sense.
Our current project uses Spring and Wicket, we have always used Spring but switched to Wicket a year ago. Few advices:
Get the "Wicket in Action" book.
The user mailing list is very helpful.
Make sure you understand Wicket's programming model especially the session serialization related stuff (the book does not help enough in this area IMHO).
Wicket is good at building stateful pages, it requires more work to build stateless pages.
There are some good UI widgets available like inmethod DataGrid.
It's easy to inject your Spring beans in your pages or components.
Spring Roo is still in beta (1.0 M2), so it may be a little early.
We also considered Tapestry 5 but we thought it was a bit young a year ago.
Spring Roo 1.0.0 (GA) has now been released, complete with around 100 pages of documentation.
If you're wondering about what Roo is and why use it, I recommend you take a read of the introductory chapter of the reference guide. It covers this and more.
#Antony, GWT support is a major priority for Roo and something I am currently working on. Expect to see some interesting integration in the very near future.
I was at the SpringOne conference in Amsterdam earlier this year when they announced Roo. My impression (and that of my colleague who was there) was that Roo was good if you were generating a web-based CRUD application every few weeks - they pitched it as the pure Java version of Grails (which is RoR for Java).
Didn't look interesting for anyone else - but that's just an opinion.
I've seen a demo of Roo a few months ago. It looks a lot like Grails (another spring technology), except that instead of creating artifacts for the Groovy language, you create them for Java.
Still it enforces good practice and makes you apply the MVC pattern in a clean way.
Personally, the demo didn't make me change my preferred toolkit (Grails), but that's because I can achieve faster results with Groovy (parsing xml for example is much more "painful" in Java than in Groovy). Also, with Grails I can see the changes I make instantly without having to recompile my entire project and relaunch the application each time I want to see the results.
Last but not least, in Grails you have tons of plugins to make fancy Ajax websites (ZK for example, if you want to avoid Javascript, but there are plugins for GWT, Yahoo, Dojo, etc...).
So, if you don't want to learn Groovy (which is not too difficult if you already know Java), Roo is the way to go to build clean web projects with all the power of Hibernate and Spring.
I hope this helps...
Why use Roo when one can build something w/ GWT and end up w/ a far richer better outcome and without the constraints of Roo and its architecture. Spring Web Flow is yesterdays technology.
It completely depends on what your requirements are. If it's a small site then Component Oriented frameworks like GWT or Wicket are a must as they make things really easy.
How soon with Roo support GWT? I think that the use of GWT by Roo makes it a huge win for GWT and Roo!
Roo and GWT are available today in pre-release form. In my opinion, definitely not ready for prime time.