It seems like everyone that has tried to configure their Servlet based web application to use Spring has run into trouble at some point. And to compound the problem, the Annotation based approach to configuring the Spring container without using XML, all within a simple web application, is barely documented, causing great frustration when developers are trying to get a handle to their Spring IoC container from a web context.

This incredibly simple example will show you how to configure a Servlet/JSP based web application to use the Spring framework, along with demonstrating how to use the Spring 3.0 APIs to manage the HttpSession and HttpServletRequest scope of a web application. It's a super simple application, but when you're trying to figure out how things work, that's exactly what you need.

"...the Annotation based approach to configuring the Spring container without using XML is barely documented..."

There is plenty of documentation about this feature:

1. Blog post and sample application: http://blog.springsource.com/2009/12/22/configuration-simplifications-in-spring-3-0/
2. Spring Reference Documentation: http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-java

There is even a previous article on this website on how to use Annotations rather than XML: https://www.theserverside.com/tip/How-the-Java-Config-Module-Pounced-on-Spring-30

Adam FitzGerald
SpringSource

Sometimes, you've got to write a good preamble to get people excited about an article. I hope I didn't put too many backs up against the wall with that comment. :)

Still, things are a little different when using an Annotation based Application Context as opposed to an XML based context with regards to the web.xml entries. I'm not sure if there's another, easily googled, tutorial on the web that shows a fully deployable application that uses the following entry in the web module's deployment descriptor:

<context-param>
   <param-name> contextClass </param-name>
   <param-value>
   org.springframework.web.context.support.AnnotationConfigWebApplicationContext
  </param-value>
 </context-param>

 <context-param>
   <param-name> contextConfigLocation </param-name>
   <param-value> com.mcnz.spring.SimpleConfig </param-value>
 </context-param>

It actually took a bit of research and trial and error to figure out what the right setting was. As more people use annotation based configurations, more people will likely run into that issue. Of course, they'll also get it solved very quickly when they find this great little tutorial.

In fairness, to 'find out what the right setting was', the SpringSource JavaDoc and reference guide was used, so it was the online material from Spring that made it possible. Still, the reference documentation quite large. This little example will help developers focus on whats important when they're trying to get things up and running.

(Always nice to see people from SpringSource representing at TSS)

"the Annotation based approach to configuring the Spring container without using XML is barely documented"

Re-reading that, what I really meant was using the annotation based approach specifically in a web module. There aren't alot of articles that demonstrate that particular use case. I'll reword the post.

This example is not simple and not a good example use of Spring at all, specially the Spring Java configuration. It also is not a good example of a web app overall.

Use @Component annotation on ClickCounter for component scanning instead of the SimpleConfig class. Also the Spring DispatcherServlet provide all features of the RequestContextListener and more. Using the DispatcherServlet provide a application context for more easy to understand configuration than what is shown. 

Also please do not insult readers with such comments. This does not help community. 

This little application takes only a few minutes to write and test. It's perfect for demonstrating how to get a Spring/Web application working.

I'd love to see a tutorial that approaches the same problem, and provides the same functionality, but does it in an even easier way to understand. Reproduce this application and email it to me in a zip or war file, and I'll document it and we can see which one is easier to work with and understand. I'd love to have two separate approaches to this very simply program highlighted at TSS.

Email me the war file at cmckenzie at techtarget dot com and we'll get it published. 

This example is not simple and not a good example use of Spring at all, specially the Spring Java configuration. It also is not a good example of a web app overall.

Use @Component annotation on ClickCounter for component scanning instead of the SimpleConfig class. Also the Spring DispatcherServlet provide all features of the RequestContextListener and more. Using the DispatcherServlet provide a application context for more easy to understand configuration than what is shown. 

Also please do not insult readers with such comments. This does not help community. 

That's what I intended to say (not exactly every word :-) but the idea is the same). As far as I remember, the reference document gives an example of using the SimpleConfig where a smaller-scoped bean is injected into a bigger-scoped bean. But it seems to me that we don't need the SimpleConfig to do that, we can write something like[code]@Component
@Scope(value = "session", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class User {
    private String attuid;
    private String password;
    ....
}

@Controller
public class WebController {
    @Inject private User user;

    ....

}[/code]

So, the goal of this example was to keep it focussed on the Servlet API, and integrating a simple Servlet/JSP application with Spring.

Indeed, there are great benefits to Spring MVC, but the goal here isn't to introduce a brand new framework. The goal is to demonstrate how one could integrate a Spring IoC container with and standard Servlet/JSP application. So indeed, Spring MVC is great, but this example is all about integrating Spring with your web application when you don't have the luxury of rewriting your entire application in a new framework.

The plan is to publish the same application but with JSF and again using Spring MVC. If anyone would like to re-write it up, I'd love to edit it up and post it on TSS. Having the same simple application coded several different ways would be a great reference tool for other developers.

Any takers?

I have to agree with others that this is not a great example.

1. I get that you were going for 'how to integrate your existing servelet/JSP app with Spring 3.0', but shouldn't that have been the title of the article?

2. "Spring 3.0 Web Application" implies the use of SpringMVC, Otherwise it would be a "Web Application with Spring Dependency Injection"

3. Why on earth would you want to promote Java scriptlets?  Integrating with Spring MVC doens't require anyone to 're-write' their app.  If you're that inclined to keep your scriptlets, you can still use Spring MVC to simply return the name of your JSP.  But then you'd have the option of using the many features of SpringMVC going forward.

>> I get that you were going for 'how to integrate your existing servelet/JSP app with Spring 3.0', but shouldn't that have been the title of the article?

So, the article was titled "Servlet API Based" which was meant to imply that is stayed strictly with the Servlet API, which is what it does. Many people using the Spring Core get frustrated with the fact that they often feel forced to use Spring MVC, which of course, they don't. This example demonstrates that very concisely.

>>Spring 3.0 Web Application" implies the use of SpringMVC

It's Spring 3.0 as it uses the 3.0 version of the core framework. If this was intended as a SpringMVC example, Spring MVC would have been referenced somewhere and it would have been promoted as such.

>>Why on earth would you want to promote Java scriptlets?

The goal is to create a simple application that can be written quickly and demonstrate exactly how to get things working and interact between the web layer and the Spring layer. Scriptlets are certainly not being promoted as a panacea for enterprise architecture, and it would be expected that anyone reading the article would know that the purpose of the scriptlet is to get a simple application working, not to demonstrate modern web development techniques.

A big problem with learning new technologies is the fact that many tutorials try to boil the ocean. I certainly could have included a service layer, created some DAOs, demonstrated how to connect to a database, include transactional attributes, write several servlets and even map the Spring MVC Dispatcher Servlet. Would that make the example easier to understand, or more difficult? I think the answer is clear.

By using a JSP, there is no need to do a servlet config in the web.xml file, or perform a servlet mapping. That simplifies the example greatly.

Besides, if I included a Servlet, everyone would complain that nobody uses Servlets and JSPs, and that I was again promoting antiquated web development techniques.

The goal was to create a simple application that anyone could code up in ten minutes and see how the pieces work together. I think the simple scriptlet in the JSP is very much in line with that goal.

>>Integrating with Spring MVC doens't require anyone to 're-write' their app.  I

Surely it requires configuring the DispatcherServlet, mapping that servlet in the web.xml file, and then making sure that every incoming request follows the URL mapping pattern specified. Again, I'm not sure if doing that makes it easier for someone to learn the basics.

Very simple and nice lesson.

Helped me a lot.

Thanks.