Comparsion: Struts 2 vs Spring 3 MVC

Apache Struts 2 and Spring MVC are two of the most popular Java web frameworks today. I’ve used both APIs extensively and wanted to share a quick comparison.

In Struts, the object that handles a request and routes it for processing is called an Action. In Spring MVC, that object is referred to as a Controller. Actions and Controllers are pretty much the same thing – they take input, process it, and return some sort of response.

The one major design difference is that by default, Struts 2 Actions are newly instantiated every time a request is made, whereas in Spring MVC the default behavior is to act as a Singleton. Spring MVC Controllers are created once and held in memory/shared across all requests. Note, you can change this behavior (scope) to request or session but we’ll talk about that later. This is a major difference to keep in mind when designing applications that need to be thread-safe, database oriented, or other share-able transactions.

Struts 2 Actions:
The basic Struts 2 Action looks very similar to any normal Pojo but with an execute method:

public class TestAction{
   public String execute() {
       return "success";

This method just returns the name of the result as defined in the struts.xml configuration file.
The struts framework will check the XML for the configured return path and handle forwarding to the proper view (usually a JSP page).

Spring MVC Controllers:
The basic Spring MVC controller only requires that you tag it with the @Controller annotation. Then you should use the @RequestMapping annotation to specify what URL patterns the controller will respond to. You can use this annotation at the class level or method level or a combination to achieve your needs.

@Controller	// Controllers are singletons by default
@RequestMapping(value = "/actions")
//@Scope("request")	// This will make spring instantiate a new object for every request
public class ControllerTest {
  @RequestMapping(value="/index", method=RequestMethod.GET)
  public ModelAndView index(ModelMap model) {
    ModelAndView mv = new ModelAndView("index", "model", model);

The above example shows the index method that would respond to a GET request in this URL Format: /actions/index. We could easily change the RequestMethod to POST and it would ONLY respond to POST requests.

Struts 2 Configs:
As you can see, the MVC concept is pretty similar between both frameworks. Now, lets compare the configurations required.

Struts 2 only requires a single ‘struts.xml’ config file to configure the framework. A typical action/result routing configuration looks like this:

<action name="TestAction" class="com.TestAction">  
            <result name="success">/pages/success.jsp</result>
            <result name="input">/pages/input.jsp</result>
            <result name="fail">/pages/failure.jsp</result>

In the example above, we returned the “success” result. So this Struts 2 would forward us to success.jsp as the view.

Spring MVC Config:
Spring MVC requires a ‘servlet-context.xml’ file. As seen above, the actual result routing/configuration is entirely completed within the Controller classes via annotations. Here’s snippetts from the file:

<!-- Configures the @Controller and annotation programming model -->
	<mvc:annotation-driven />

<!-- Forwards requests to the "/" resource to the "welcome" view. Use this to setup a default action -->
	<mvc:view-controller path="/" view-name="welcome"/>

<!-- Resolves view names to protected .jsp resources within the /WEB-INF/views directory -->
	<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
		<property name="prefix" value="/WEB-INF/views/"/>
		<property name="suffix" value=".jsp"/>

The last bean entry is the most important. In our above example we returned the “index” model and view. Spring will automatically prefix and suffix the view resulting in “/WEB-INF/views/index.jsp” as the JSP that handles the request. Of course, you can configure the path to whatever you desire.

You can find a fully working servlet-context file anywhere on the internet or you can contact me and I am happy to provide you an example.

Note, most development teams will then choose to deploy the full Spring architecture and have the Core Application Context enabled as well. For example, this would be necessary if you wanted to have Spring manage your Data Layer via JPA / EntityManager. Or if you wanted to have Spring manage and inject your Beans across your application.


Either framework is a good choice. I suggest reviewing the exact needs of your application before choosing a Framework. I’m available to help if there is any need!

Thanks for reading.


Forrester Says Java is a Dead-End – Um, what??

I just read a post by Mike on Forrester’s Blog titled “Java Is A Dead-End For Enterprise App Development”.  While some of his points are valid, I disagree with his reasons. Here’s why:

  1. Mike says “Java was at the right place at the right time.”
    • I don’t see how this leads to dead ends. Having the right product at the right time is how successful businesses are made.
  2. Then he goes on to point out various deficiencies in the Java platform and why the industry should “move forward”
    • Java is a 20 year old language based on C++” – I fail to see how this is relevant to his argument.  Java has evolved through 6 major revisions, approaching 7 very soon.  Its true the focus has moved all over the place but I think most people will agree that the API is in the best state yet. Think about  Spanish and French, which are hundreds of years old, based on Latin. Does that make them obsolete? Additionally, his facts aren’t correct. Java was released in 1995 making it 15 years old.
  3. “Java frameworks prove complexity” – Mike says that popular frameworks (Hibernate, Spring, etc) cause complexity. 3rd party APIs do add complexity – thats true for any language. But take a look at the purpose of these frameworks. They solve problems that are common to all n-tiered projects by providing a common framework. The community has proven and accepted them and developers can use the same framework across projects. Imagine if these frameworks didn’t exist. Should Oracle buy out these technologies and bundle them into the JDK – Thats another discussion.

Don’t get me wrong- Java is not a perfect language/platform and I do agree with this point:

  1. “Java bungled the presentation layer” – I don’t think its so much as bungled, but Java never really focused on providing pretty presentation. I agree that the desktop APIs have really sucked. But on the web, Java provides a way to send data to the presentation and leaves the actual pretty stuff up to 3rd party tools.

Its pretty clear to me that Mike wants Java to be one big bundled PRODUCT. Why? Because thats what Forrester does – they review products. They compare Java to BPM and other COTS products. That’s not even a valid comparison.

They want the Java platform to do everything and be a one stop shop for development. On the contrary, that’s not what Java is about. The Java concept is: Openness and Flexibility for framework choice.   Not everyone needs or wants to be tied into an entire platform when they only need a small piece of it …