Spring Security Tutorial #1 - Authentication and Authorization

Spring security is a framework that lets you add security to spring based applications. Before Spring security, developers had to rely on J2EE security to secure java applications. J2EE provides very limited function. You could secure web resources or EJB methods. But there is nothing more. Additional drawback of J2EE security is that implementations are application server specific. If you do anything more that what is in the servlet or EJB specification, it is not portable.

In addition to basic authentication and authorization, Spring Security has support for:
Remember me authentication
Session management
ACL based security
Integration with CAS, LDAP, Open ID
and many other things.

It is not possible to cover all those topics in one article. I plan to write about Spring Security as a series of tutorials. This first installment #1 will get you started with Spring Security and help you setup basic authentication and authorization.

Authentication refers to ensuring that the user is who he or she claims to be. Any application that has any security will typically force the user to present a name and a password. If they match what is stored in the system, we say the user is authenticated and allow the user to continue using the application.

Authorization refers to ensuring that an authenticated user has the necessary permissions to perform some operation or access some data. Authorization involves checking a pre-defined policy which may say that these users have permission to perform these actions on this resource.

For this tutorial, let us take the simple web application we developed in Spring MVC blog and add security to it. Springmvc.zip was renamed to Springsecurityv1 and security metadata added. You can download the sample at Springsecurityv1.zip.

For this tutorial you will also need
(1) Spring 3.0
(2) Spring Security 3.x.
(3) Eclipse is optional. I use eclipse as my IDE. But you can use other IDEs or command line tools as well.
(4) A webserver like Tomcat
(5) Some familiarity with the Spring framework.

Note that Spring Security is packaged separately and is not included in core Spring.

Step 1:
As always, spring configuration begins in applicationcontext config file. We start by adding the namespace which has the spring configuration elements. In springsecurity-servlet.xml, the security namespace http://www.springframework.org/schema/security is added.

<beans xmlns:security="http://www.springframework.org/schema/security" 
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
       xmlns="http://www.springframework.org/schema/beans" 
       xsi:schemalocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans-2.0.xsd 
       http://www.springframework.org/schema/security
       http://www.springframework.org/schema/security/spring-security-3.0.3.xsd">
</beans>

Step 2:
Add the Spring security filters to the web.xml. These filters intercept requests and force authentication and authorization

<filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>springSecurityFilterChain</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

Step 3:
Add a minimal Spring security configuration to springsecurity-servlet.xml.

<security:http auto-config="true">
    <security:intercept-url access="ROLE_manager" pattern="/**">
</security:intercept-url>
</security:http>

The http element is the element under which all web application related security configuration. The intercept-url says that for any request to any url ( pattern = "/*") , the user needs to be authenticated and a member of the role ROLE_manager.

When you try to access any URL in this application, Spring will redirect you to a page where you need to enter a username and password. The login page is generated by Spring.

But who are the valid users ? And which of them are part of role ROLE_manager.
Step 4:
A really simple way is to define the users in springsecurity-servlet.xml using the authentication-provider
element.

<security:authentication-manager>
    <security:authentication-provider>
      <security:user-service>
        <security:user authorities="ROLE_manager" name="tony" password="tony12">
        <security:user authorities="" name="raul" password="raul12">
        </security:user>
      </security:user>
    </security:user-service>
  </security:authentication-provider>
</security:authentication-manager>

In this authentication provider, 2 users tony and raul are defined in the configuration. Tony has the authority ROLE_manager.

For a production application, You will want define users, password and roles in database (or LDAP). see step 7 for database configuration.
Step 5:
From eclipse, export the war file (or use the provided war file).
Deploy the war file to tomcat.

Point your browser to http://localhost:8080/springsecurityv1/test.htm. You will be shown the login screen below.

Type in user tony and password tony12. Login will be successful and you will be served the web page below

Step 6:
Restart the browser. Clear cookies and sessions. Type the same URL.
You will be prompted for username/pwd. This time type in abc / abc12. The login will fail as abc is not a valid user.

Repeat with user raul /raul12. With raul the login succeeds. But access will be denied because raul does not have the ROLE_manager authority.
Step 7:
As mentioned earlier, you would normally not keep username/passwords in the spring configuration file. Spring provides the jdbc-user-service that lets you authenticate with users defined in a database.

In this app, springsecurity2-servlet.xml is second configuration that uses jdbc-user-service. The configuration is

<security:authentication-manager>
    <security:authentication-provider>
      <security:jdbc-user-service data-source-ref="securityDataSource"/>
    </security:authentication-provider>
  </security:authentication-manager>
  
   <bean id="securityDataSource"
       class="org.springframework.jdbc.datasource.DriverManagerDataSource">
       <property name="driverClassName" value="org.apache.derby.jdbc.EmbeddedDriver" />
       <property name="url" value="jdbc:derby:/home/mks/mkprojects/database/springusers" />
   </bean>

For this to work, you need to create database tables required by Spring. See Spring documentation for database table schema.

In summary, getting started with Spring Security is quite easy. In a few simple steps, by adding some configuration metadata, we have enabled authentication and authorization for our web application.

When to use the Java volatile keyword ?

In the Java programming world, there is some misunderstanding around the volatile keyword. Most programmers never use it and you rarely see code that has it. In this article I try to remove the mystery surrounding volatile.

Section 8.3.1.4 of the Java language specification has this definition: A field may be declared volatile, in which case the Java memory model (§17) ensures that all threads see a consistent value for the variable.

Consider the class below:

public class SomeValue {
    private static long value = 0  ;
    public static void setValue(int i) {
        value = i ;
    }
    public static void getValue() {
        return i ;
    }
}

At time time1, thread t1 calls SomeValue.setvalue(3).
At time time2, thread t2 calls SomeValue.getValue().
Thanks to the java memory model, there is no guarantee that thread t2 see the value 3.

One way to fix the problem is the make the methods getValue and setValue synchronized. Declaring the member variable value volatile is another way to do the same.

So which approach is better ? To answer the question, there are 2 concepts that need to be examined.

1. Locking:
With synchronized, locking is involved. To execute code within a synchronized block, a lock must first be acquired. The lock is held until the block is exit. If another thread tries to execute the same code block, it will block until it can acquire the lock.

With volatile, no locking is involved. Whenever possible, avoiding locking is better because locking can make the application less scalable.

2. Atomicity:
An atomic operation is one that is indivisible.

public void setX(boolean val) {
    x = val ;
}

setX is an atomic operation. Every thread that calls setX concurrently can setX and expect it to behave correctly. Timing does not affect the result.

But consider the method

public void increase(long x) {
    value = value + x ;
}

It really consists of 3 operations: get the value, add x to it, store the value.
If two threads call increase, the result depends on timing.

Let us say at time1 , value is 3
At time2, thread t1 calls increase(4). It sees the current value at 3. But before it can update the value,
At time3, thread t2 calls increase(5). It sees the current value as 3 as well.
At time4, thread t1 updates the value to 3+4 = 7.
At time5, thread t2 updates the value to 3+5 = 8. This is known as a race condition. Depending on timing of event, you can get different results.

Synchronization makes the code within the synchronized block atomic. If you make the method synchronized,

public synchronized void increase(long x) {
    value = value + x ;
}

the increase method is atomic. Only one thread is able to increase the value at a time. When the method completes, every other thread will see the value. With synchronized, in the above example, the final value would be 3+4+5 which is 12 which is correct.

By just declaring value as volatile, this atomicity is not there. It two threads call increase at the same time, we cannot predict what the result is.

Back to the question we started with. When to use volatile ?

The volatile keyword can help when you know that your access to the field whether read or write is atomic. The benefit of volatile is that the changes to the field are published to other threads without the use of locking. When you are sure that operations are atomic, declaring a field as volatile is simpler that wrapping code in synchronized blocks.

An additional point to remember is that volatile is not necessary for fields that immutable or declared final. The Java memory model guarantees that final fields are visible to other threads without synchronization or volatile.

The classic use case of volatile is a boolean flag that is used to stop a long running thread.

public class LongRunningTask extend Thread {
    private volatile boolean stop = false ;
    public void run() {
       while(!stop) {
         doWork() ;
       }
    }
    public void stopTask() {
       stop = true ;
    }
}

If one thread calls stopTask, the main thread can immediately see the value and stop. stopTask is atomic.

However when you have operations that are non atomic such as the increase method, you need synchronization. JDK5 introduced atomic variable classes such AtomicInteger, AtomicLong etc in the package java.util.concurrent.atomic. These classes extend the volatile concept to compound operations such as read-modify-write. These can be used in place of volatile. A more detailed discussion of atomic classes is topic for another blog.

Spring AOP made simple

Certain types of code like logging, monitoring, security access checks, transaction boundary management etc apply to all methods in the application. These are known as cross cutting concerns. The poor programmers way of implementing cross cutting concerns is to the implement them in every method. Every method would begin with a checkAccess call, a fire call that fires a monitoring event, a call that starts a new transaction. When you implement a new method, you need to copy this common code to the new method.

Aspect oriented programming is a style and mechanism where common code factored out and is inserted before, after or around the real application code using either proxies or other techniques like code injection. Before we proceed any further, let us describe some AOP terminology.

An Aspect is a piece of common code that can be applied repeatedly to various places in the application. An example is code that may start a transaction or complete the transaction.

A join point is a point in the program, such as a method.

Advice is code that is part of the aspect and that is applied to a join point. Some different types of advice are before advice,after advice, around advice. Before advice is executed before the method. After advice is executed after the method is executed. In Around advice, part of the advice executes before the method and the other part after the method.

A pointcut is a set of join points to which advice may be applied. Generally some syntax or expression is used to match or determine the join points.

Enough threory. Let us get down to a real sample.Let us write a simple Spring application that prints a greeting. Then we will use Spring AOP to add a security check to the method by creating an Aspect with a before advice. Lastly we will add transaction support to the method by creating an Aspect with an around advice. Note that we will not be writing any real security or transaction code. The sample will just print a message where as in a real application you would have real code. You may download the complete source code at springaop.zip

For this tutorial you will also need
(1) Spring 3.0
(2) Eclipse is optional. I use eclipse as my IDE. But you can use other IDEs or command line tools as well. springaop.zip can be imported into eclipse.
(3) Some familiarity with the Spring framework.

Step 1: Code a simple Spring application

public interface Greeting {
    public String message(String target) ;
}

public class NewYearGreeting implements Greeting {
    public String message(String target) {
        System.out.println("From SpringAOP::" + target) ;
        return target ;
    }
    public static void main(String[] args) {
        ApplicationContext context =
        new ClassPathXmlApplicationContext("springaop.xml");
        Greeting sprg = (Greeting) context.getBean("greetbean");
        sprg.message("Happy new year 2011") ;
   }
} 

Add the bean definition in springaop.xml:
<bean id="greetbean" class="com.mj.spring.aop.NewYearGreeting"/>
Run the above application. The following line is output:
From SpringAOP::HappyNewYear

Step 2: Add @AspectJ support by adding the following line to springaop.xml. @Aspectj is a style where aspects are declared by adding annotations to java classes. This style was developed by the AspectJ project. We use these annotations in steps 3 and 4.
<aop:aspectj-autoproxy/>

Step 3: Create a security Aspect as shown below. It is an ordinary java class with the annotation @Aspect. The checkAccess method is anotated as @Before and it is a before Advice. It applies to the pointcut execution(public * com.mj.spring.aop.*.*(..)). You can find more detailed explanation of this syntax in the Spring or AspectJ documentation.But you might have guessed that it means - execute the before advice before every public method of every class in the package com.mj.spring.aop.

@Aspect
public class SecurityAspect {
 @Before("execution(public * com.mj.spring.aop.*.*(..))")
 public boolean checkAccess() {
  System.out.println("Checking access before method invoke") ;
  return true ;
 }
}

Step 4: Create a transactions aspect as shown below. As in step 3, the class is annotated @Aspect.

@Aspect 
public class TransactionAspect {
 
 @Pointcut("execution(public * com.mj.spring.aop.*.*(..))")
 public void greetingmethod() {} 
 
 @Around("greetingmethod()") 
 public Object doTran(ProceedingJoinPoint pjp) throws Throwable {
  System.out.println("Starting a transaction Before calling the method") ;
  Object output = pjp.proceed();
  System.out.println("Completing the transaction After calling the method") ;
  return output ;
 }
}

The doTran method is the method that implements the around advice. The first parameter of the method that implements the around advice has to be of type ProceedingJoinPoint, which delegates the call to the actual target. Within the method you call the target by calling the proceed method. So the transaction is started before the proceed call which leads to target method invocation. The transaction is completed after the proceed() call - that is after the target method invocation. I have also made the pointcut generic so it can be applied to other methods if necessary. To define a pointcut that can be reused, create an empty method like greetingmethod() {} and add the @pointcut annotation to it. The @Around annotation on doTran uses this pointcut.

Step 5: Add the bean definitions for the aspects created in 3 & 4 to springaop.xml, so that the spring container knows about the aspects. This is an often forgotten step that can lead to unnecessary grief because the aspects will not get called.
<bean id="TransactionAspect" class="com.mj.spring.aop.TransactionAspect"/>
<bean id="SecurityAspect" class="com.mj.spring.aop.SecurityAspect"/>

Step 6: run the application. You will see the output:
Checking access before method invoke
Starting a transaction Before calling the method
in the method - From SpringAOP::Happy new year 2011
Commiting the transaction After calling the method

Using the techniques shown above, you can add sophisticated function to your application that is generally available only in complex containers like the EJB container or the SCA container. These containers typically use java dynamic proxies. SpringAOP is implemented using java dynamic proxies as well. But more importantly it makes it really easy to add cross cutting concerns to your application with need intrusive or repetetive code changes.

Designing Java Classes For Inheritance

In Object oriented programming, inheritance is concept that lets programmers re-use code as well specialize existing code. In Java, a class, the sub class can extend another class, the super class and there by inherit the attributes and behaviour (methods) of the super class. Specializing behavior is really a related concept called polymorphism. However you cannot specialize without inheriting.

Popular belief is that inheritance is always a good thing. However when used inappropriately, it can lead to code with bugs. The problems have been well documented in several books and articles. Yet very often we come across code with a complex inheritance hierarchy that looks cute, but is difficult to use and more often than not broken. Below I recap a few key points to remember when using inheritance in Java.

Consider the class MemberStore which is used to persist Members to a database

public class MemberStore {
  public void insert(Member m) {
    // insert into database
  } 
  public void insertAll(List<member> c) {
    // insert all members into the database
    // by calling the insert(m) for each Member
    Iterator i = c.iterator() ;
    while(i.hasNext()) {
      insert((Member)c.next()) ;

    }
  }
}

Let us say there is a need for a class that not only stores Members, but also keeps count of recently stored members. The wrong way to do it would be to
extend the above class

public class MemberStoreWithCounter extends MemberStore {
  private int counter = 0 ;
  public void insert(Member m) {
    counter++ ;
    super.insert(m) ;
  } 
  public void insertAll(Collection<member> c) {
    counter = counter + c.size() ;
    super.insertAll(c) ;
  }
  public int getCount() {
    return counter ;
  }
}

Let us try to use the new class

List<Member> list = new ArrayList<Member>() ;
list.add(new  Member(......)) ;
List.add(new  Member(......)) ;
MemberStorewithCounter m  = new .... ;
m.insertAll(list) ;
System.out.println(a.getCount());

What do you suppose the last line prints ? You were probably expecting 2. But it will print 4. The problem is that the insertAll method is implemented by calling the insert method. So the counter is incremented twice for each Member. This is the classic wrong use of inheritance.

The problem is that inheritance breaks encapsulation. Inheritance requires the programmer implementing the subclass class to know the implementation details of the super class. So generally it is safe to use inheritance only when the subclass and the superclass are under the ownership of the same programmer or team of programmers.

If you are designing your class so that other programmers may extend it, then it is preferable that the implemented methods of your class not call other overridable methods as was done by insertAll. If they do, then the javadocs must clearly document it. In the above example, the javadocs should say that insertAll calls insert. But this is not sufficient.

The javadocs for methods that can be safely overridden should say under what conditions and for what behavior the method should be overridden.

Classes that are not meant to be extended and methods that should not be overridden should be marked final so that programmers cannot extend them.

Constructors should never invoke overridable methods.

Lastly, in Java inheritance implies an "generalization/specialization" or "is a" relationship. Even if you do not intend to specialize, if you add a method to the subclass with the same signature of a method in the subclass, the method in the subclass overrides the method in the superclass. If there is no "is a" relationship, it is never a good idea to use inheritance.

The better way to add a counter to MemberStore is to write a wrapper around MemberStore that has MemberStore as a private member and delegates to it. This is otherwise known as composition.

public class BetterMemberStoreWithCounter {
  private MemberStore ms = new MemberStore() ;
  private int count = 0 ;
  public insert(Member m) {
     ms.insert(m) ;
     count++ ;
  }
  public insertAll(Collection<member> c) {
     count = count.size() ;
     ms.insertAll(c) ;
  }

}

Performance tip #1 - Java Strings

The java.lang.String class is a very convenient class for handling text or character data. It is used extensively in java programs. Sometimes excessively to the point that it degrades performance.

The String class is immutable. It cannot be changed. It has concatenation and substring methods that give the appearance of changing the string. In realilty, the jvm copies data and creates new strings.

// code 1 Inappropriate

String item ;
String[] listofitems ;
for (int i = 0 ; i < numitems ; i++)
item = item + listofitems[i] ;

// code 2 Much better
StringBuffer item ;
for (int i = 0 ; i < numitems ; i++)
item.append(listofitems[i]) ;

java.lang.StringBuffer is the mutable counterpart of String, that should be used for manipulating Strings. StringBuffer is threadsafe. java.lang.StringBuilder provides methods similar to StringBuffer, but the methods are not synchronized. StringBuilder can used when thread safety is not an issue.

In 1 ,a new String is created for every iteration of the loop and the contents of the previous iteration are copied into it. For n items, this is going to perform O(n square). Code 2 scales linearly O(n). For large values of n, the difference is significant.

There are a number of methods such as substring, trim, toLowerCase, toUpperCase that have this problem.

However there is one instance where concatenation is better. If the String can be resolved at compile time as in

// code 4
String greeting = "hello" + " new world" ;

At compile time , this gets compiled to
String greeting = "hello new world" ;

The alternative is
// code 5
String greeting = (new StringBuffer()).append("hello").append(" new world").toString() ;

Code 4 is more efficient as it avoid the temporary StringBuffer as well as the additional method calls.

Processing character arrays as is done in the C programming language is generally the fastest. But almost all public java libraries use String in their interfaces. So most of the time the programmer has no choice. So proper care needs to be take to ensure acceptable performance.

Lastly, converting Strings to numbers whether it is int, long, double or float can be expensive. Many programmers make the mistake of starting with String and then converting to a number type when they need to do a numerical computation. As a general rule, Strings should be used when processing text. For example, if you know that data being read from a file is of type int or float, read it into the correct type and avoid unnecessary conversion.

Database isolation

When multiple threads are accessing data from the same table or tables in a relational database, care needs to be taken that updates from one thread or transaction do not interfere with others. Isolation is a property of database transactions that determine when changes made by one transaction are visible to other concurrent transactions.

Relational databases support different isolation levels. Isolation is typically achieved either by locking data or by serializing access to data, both of which lead to loss in concurrency ( and thus performance). It is thus important to pick the correct isolation level so you have optimal performance without loss in correctness.

To understand isolation levels, it is useful to first talk about the type of queries than can happen.

1. Dirty reads
A dirty read is one that reads uncommitted data.This is dangerous for obvious reason. The data you just read may get rolled back and never exist in the database in the future.

2. Non repeatable read
A non repeatable read reads committed data. But if you do the read again, you will see the effect of any changes to the data that were committed by other transaction.

At time a1, say a transaction t1 executes query:

select quantity from Order
where orderid = 1

It returns 2.

At time a2, transaction t2 updates the quantity to 3.

At time a3, t1 executes the same query which returns 3.

3. Phantom reads
A phantom read reads committed data as well. But a subsequent read in the same
transaction may see new data added and committed by another transaction.

At time a1, a transaction t1 does

Select OrderId from Order
where itemid = '23'

The querry returns

1
2

At time a2 , another transaction t2 inserts a new order for the same item id.

At time a3, transaction t1 executes the same query and it might return

1
2
3

Now that we understand the types of reads, let us look at the isolation levels. There are 4 isolation levels defined by ANSI

1. READ UNCOMMITTED
This is the least stringent isolation level. At this level, dirty reads are allowed. You are reading data that may or may not be committed and it is unreliable.

2. READ COMMITTED
This isolation level ensures that only committed data is read. Dirty reads are thus not allowed. But Non repeatable reads or phantom reads are possible. This isolation level is sufficient if you just want to get a snapshot of the data at a particular time and do not care that might be updated.

3. REPEATABLE READ
This isolation level ensures that rows read within a transaction will not be updated by another transaction. New rows might added, but ones already read will not change. The reads are thus repeatable. Non repeatable read is not possible, but phantom reads are possible.

4. SERIALIZABLE
This is the most stringent isolation level. Access to data is serialized. This is very expensive but none of the problem reads are possible.

The default isolation level in SQL Server, Oracle and DB2 is Read Committed. Most the time this is sufficient. Read Uncommitted is too dangerous and serializable can lead to unacceptable performance.

Repeatable Read is necessary when you say read rows from a database and based on the value, do an update or delete within the same transaction. You need repeatable read because within the transaction, the conditions that lead to update following the read ,should not change.

The default isolation level is sufficient for most routine database applications. However problems due to isolation generally show up in large scale environments where thousands of transaction are hitting the same database tables at the same time. By choosing the right isolation levels, you can ensure the performance stays acceptable while avoiding difficult to troubleshoot problems.

Developing web applications with Spring

Spring MVC enables easy web application development with a framework based on the Model View Controller architecture (MVC) pattern. The MVC architectural pattern requires the separation of the user interface (View), the data being processed (Model) and the Controller which manages the interactions between the view and the model.

At the core of Spring MVC is a servlet, the DispatcherServlet, that handles every request. The DispatcherServlet routes the HTTP request to a Controller class authored by the application developer. The controller class handles the request and decides which view should be displayed to the user as part of the response.

Let us develop a simple web application that takes a request and sends some data back to the user. Before you proceed any further, I recommend you download the source code at springmvc.zip

For this tutorial you will also need

(1) A webserver like Tomcat
(2) Spring 3.0
(3) Eclipse is optional. I use eclipse as my IDE. Eclipse lets you export the war that can be deployed to Tomcat. But you can use other IDEs or command line tools as well.
(4) Some familiarity with JSPs and Servlets is required.

Step 1: If you were to develop a web application in J2EE, typically you do it by developing servlets or JSPs, that are packaged in .war file. Also necessary is a deployment descriptor web.xml that contains configuration metadata. The war is deployed to a web server like tomcat.

With Spring, the first thing to do is to wire Spring to this J2EE web infrastructure by defining org.springframework.web.servlet.DispatcherServlet as the servlet class for this application. You also need to define org.springframework.web.context.ContextLoaderListener as a listener. ContextLoaderListener is responsible for loading the spring specific application context which has Spring metadata.

The web.xml setup ensures that every request to the application is routed by the servlet engine to DipatcherServlet. The updated to web.xml is shown below:

<listener>
    <listener-class>
        org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>
<servlet>
    <servlet-name>springmvc</servlet-name>
    <servlet-class>
        org.springframework.web.servlet.DispatcherServlet
    </servlet-class>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>springmvc</servlet-name>
    <url-pattern>*.htm</url-pattern>
</servlet-mapping>

Step 2: The heavy lifting in this web application is done by a controller class. This is an ordinary java class or bean that extends org.springframework.web.servlet.mvc.AbstractController. We override the handleRequestInternal method. In this method, you would do the things necessary to handle the request which may include for example reading from a database.

The method returns a org.springframework.web.servlet.ModelAndView object which encapsulates the name of the view and any data (model) that needs to be displayed by the view. ModelAndView holds data as name value pairs.This data is later made available to the view. If the view is a jsp, then you can access the data using either jstl techniques or by directly querying the Request object. The code for our controller is shown below:

public class SpringMVCController extends AbstractController {
    protected ModelAndView handleRequestInternal(HttpServletRequest request, HttpServletResponse response) {
        ModelAndView mview = new ModelAndView("springmvc") ;
        mview.addObject("greeting", "Greetings from SpringMVC") ;
        mview.addObject("member1", new Member("Jonh","Doe", 
            "1234 Main St","Pleasanton","94588","kh@gmail.com","1234")) ;
        return mview ;
    }
}

The name of the view springmvc is passed in to the constructor of ModelAndView. The addObject methods add 2 model objects greeting and member1. Later you will see how the view can retrieve the objects and display them.

Step 3: Every Spring application needs metadata that defines the beans and their dependencies. For this application, we create a springmvc-servlet.xml. We help spring find it by specifying its location in web.xml.

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>/WEB-INF/springmvc-servlet.xml</param-value>
</context-param>

In springmvc-servlet.xml, the controller bean is defined as

<bean name="/*.htm" class="com.mj.spring.mvc.SpringMVCController"/>

Step 4: How does DispatcherServlet know which Controller should handle the request ?

Spring uses handler mappings to associate controllers with requests. 2 commonly used handler mappings are BeanNameUrlHandlerMapping and SimpleUrlHandlerMapping.

In BeanNameUrlHandlerMapping, when the request url matches the name of the bean, the class in the bean definition is the controller that will handle the request.

In our example, we use BeanNameUrlHandlerMapping as shown below. Every request url ending in .htm is handled by SpringMVCController.

<bean name="/*.htm" class="com.mj.spring.mvc.SpringMVCController"/>

In SimpleUrlHandlerMapping, the mapping is more explicit. You can specify a number of urls and each URL can be explicitly associated with a controller.

Step 5: How does the DispatcherServlet know what to return as the response ?

As mentioned earlier, the handleInternalRequest method of the controller returns a ModelandView Object.

In the controller code shown above, the name of the view "springmvc" is passed in the constructor to ModelAndView. At this point we have just given the name of the view. We have not said what file or classes or artifacts help produce the html, nor have we said whether the view technology used is JSP or velocity templates or XSLT. For this you need a ViewResolver, which provides that mapping between view name and a concrete view. Spring lets you produce a concrete view using many different technologies, but for this example we shall use JSP.

Spring provides a class InternalResourceViewResolver that supports JSPs and the declaration below in springmvc-servlet.xml tells spring that we use this resolver. The prefix and suffix get added to view name to produce the path to the jsp file that renders the view.

<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
    <property name="prefix" value="/WEB-INF/jsp/"></property>
    <property name="suffix" value=".jsp"></property>
</bean>

Step 6: In this example, the view resolves to springmvc.jsp, which uses JSTL to get the data and display it. Spring makes the model objects greeting and member1 available to the JSP as request scope objects. For educational purposes, the code below also gets the objects directly from the request.

// Using JSTL to get the model data
${greeting}
${member1.lastname
// Using java to get the model directly from the request
Map props = request.getParameterMap() ;
System.out.println("PARAMS =" + props) ;
Enumeration em = request.getAttributeNames() ;
while (em.hasMoreElements()) {
    String name = (String) em.nextElement() ;
    System.out.println("name = "+name) ;
}
System.out.println("Attrs are "+request.getAttributeNames()) ;
System.out.println("greeting is "+ request.getAttribute("greeting")) ;
Member m = (Member)request.getAttribute("member1") ;
System.out.println("member is "+m.toString()) ;

Step 7: All files we have developed so far should be packaged into a war file as you would in any web application. The war may be deployed to tomcat by copying to tomcat_install\webapps. I built a war that you can download at springmvc.war

Step 8: Point your web browser http://localhost:8080/springmvc/test.htm to run the application. The browser should display the data.

To summarize, Spring simplifies web application development by providing building blocks that you can assemble easily. We built a web application using Spring MVC. Spring provides an easy way to wire together our model, the controller SpringMVCController and the view springmvc.jsp. We did not have to explicitly code any request/response handling logic. By changing the metadata in springmvc-servlet.xml, you can switch to a different controller or a different view technology.