Sunday, December 9, 2012

Spring MVC (Security): custom authentication manager and login page

In the previous post, we've implemented basic authentication and authorization features, mainly relying on the login page that Spring security generates. However, most of the time, we'll want to have our own login page as well as a custom authentication manager (having all the usernames, passwords, and roles hardcoded in the  web.xml file is definitely not a good solution!). Let's see how we could achieve that. As we use the project from this previous post as starting point, feel free to check out it source code here.


Tools and libraries
  • Eclipse Indigo
  • Spring-core 3.1.1
  • Spring-security 3.1.0
  • Tomcat 7
  • Maven 3
STEP 1 - Creating the custom login page

In our example, we'll create a login page, named "myLoginPage.jsp"  that is actually quite similar to the one that Spring Security generates   except that we'll add a logout button:

<%@ taglib prefix="s" uri="http://www.springframework.org/tags"%>
<%@ taglib prefix="security"
 uri="http://www.springframework.org/security/tags"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
<%@ taglib prefix="sf" uri="http://www.springframework.org/tags/form"%>
<div id="loginPannel">
 <security:authorize access="!isAuthenticated()">
  <h1>This is my custom login page</h1>
  
  <c:if test="${loginFailed}">
   <div style="color: red">Could not sign in, please check your login/password...</div>
  </c:if>  

  <form method="post" class="signin" action="j_spring_security_check">
   <table>
    <tr>
     <th><label for="username_or_email">Username/email</label></th>
     <td><input id="username_or_email" name="j_username" type="text" /></td>
    </tr>
    <tr>
     <th><label for="password">Password</label></th>
     <td><input id="password" name="j_password" type="password" /></td>
    </tr>
    <tr>
     <th></th>
     <td><input name="commit" type="submit" value="Sign In" /></td>
    </tr>
   </table>
  </form>
 </security:authorize>
</div>

Note the following line in our JSP page: <security:authorize access="!isAuthenticated()">
It specifies that this page is restricted to user that aren't authenticated. Access rules can be defined using expressions which correspond to the methods (such as, hasRole( ), hasAnyRole( ), ...) from the "SecurityExpressionRoot" provided by Spring.

STEP 2 - Customizing login page

In this step, we edit the Spring configuration file "MyDispatcherServlet-servlet.xml", to override some behavior of Spring default security configuration:

 <security:http auto-config="true" use-expressions="true"> 
  <security:form-login login-page="/login.go" default-target-url="/home.go" authentication-failure-url="/login.go?errorLogin"/> 
  <security:intercept-url pattern="/home.go" access="hasRole('ADMIN')" /> 
  <security:logout logout-success-url="/home.go" />
 </security:http>


  • use-expression="true": allows us to use expression such as hasRole(...), hasAnyRole(...), isAuthenticated( ), and so on, to define access rules
  • login-page="/login.go": defines the URL at which the login page is located
  • default-target-url="/home.go": defines the URL toward which the user will be redirected once he successfully logged in
  • authentication-failure-url="/login.go?errorLogin": defines the URL toward which the user will be redirected when the login fails. In our example, we redirect the user to the login page with an additional "errorLogin" parameter in the URL. This existence of this parameter will be checked in a Spring Controller class. If it exists, an attribute will be added to the model before returning the view to be displayed. Within the JSP page, we check this model attribute to eventually display an error message. 
  • <security:intercept-url pattern="/home.go" access="hasRole('ADMIN')" />: indicates that the "/home.go" URL is subject to access rules.
  • <security:logout logout-success-url="/home.go" />: defines the URL at which the user is redirected after he logged out.
STEP 3 - Defining a custom authentication provider

In most cases, we'll store user credentials and roles in a DB, LDAP, you name it, and consequently, we'll want authentication and authorization to be performed against that user repository. In this example, we'll configure an authentication provider as if we were storing the user credentials in a DB.

To do so, we edit the Spring configuration file "MyDispatcherServlet-servlet.xml" and define a custom Spring service (here, it's named "myUserDetailService") as authentication provider:

 <security:authentication-manager>
  <security:authentication-provider
   user-service-ref="myUserDetailService">
  </security:authentication-provider>
 </security:authentication-manager>

STEP4 - Implementing the custom authentication provider


  • First, we have to create a class that implements the GrantedAuthority interface from Spring. This interface will have us implement a getAuthority( ) method that returns a role name.
Ex:

package service.security;

import org.springframework.security.core.GrantedAuthority;

public class GrantedAuthorityImpl implements GrantedAuthority{
 private static final long serialVersionUID = 1029928088340565343L;

 private String rolename;
 
 public GrantedAuthorityImpl(String rolename){
  this.rolename = rolename;
 }
 
 public String getAuthority() {
  return this.rolename;
 }

}


  • Then, we create a class that implements the UserDetails interface from Spring. This class will hold all the account-related info such as the user credentials and the associated roles.
package service.security;

import java.util.Collection;
import java.util.HashSet;

import org.springframework.security.core.GrantedAuthority;
import org.springframework.security.core.userdetails.UserDetails;

public class UserDetailsImpl implements UserDetails{
 private static final long serialVersionUID = -6509897037222767090L;
 
 private Collection authorities = new HashSet();
 private String password;
 private String username;
 
 public UserDetailsImpl(String username, String password, Collection authorities){
  this.username = username; 
  this.password = password;
  this.authorities = authorities;
 }

 public Collection getAuthorities() {
  return this.authorities;
 }

 public String getPassword() {
  return this.password;
 }

 public String getUsername() {
  return this.username;
 }

 public boolean isAccountNonExpired() {
  return true;
 }

 public boolean isAccountNonLocked() {
  return true;
 }

 public boolean isCredentialsNonExpired() {
  return true;
 }

 public boolean isEnabled() {
  return true;
 }

}

  • Finally, we create a class that implements the UserDetailsService interface from Spring. This interface contains only one method: UserDetails loadUserByUsername(String username). In our example, we emulate a DB user repository by defining a Map whose keys are usernames, and values are UserDetails objects. Pay attention to the static initialization block in which we populate this map with 3 users.
Remark:

If we actually had user credentials stored in DB, we would just have to implement a repository class, and inject it into this class.
package service.security;

import java.util.HashMap;
import java.util.HashSet;
import java.util.Map;
import java.util.Set;

import org.springframework.security.core.GrantedAuthority;
import org.springframework.security.core.userdetails.UserDetails;
import org.springframework.security.core.userdetails.UserDetailsService;
import org.springframework.security.core.userdetails.UsernameNotFoundException;
import org.springframework.stereotype.Service;

@Service("myUserDetailService")
public class UserDetailsServiceImpl implements UserDetailsService{
 
 // just to emulate user data and credentials retrieval from a DB, or whatsoever authentication service
 private static Map<String, UserDetails> userRepository = new HashMap<String, UserDetails>();
 
 static{
  GrantedAuthority authorityAdmin = new GrantedAuthorityImpl("ADMIN");
  GrantedAuthority authorityGuest = new GrantedAuthorityImpl("GUEST");
  
  /* user1/password1 --> ADMIN */
  Set<GrantedAuthority> authorities1 = new HashSet<GrantedAuthority>();
  authorities1.add(authorityAdmin);
  UserDetails user1 = new UserDetailsImpl("user1", "password1", authorities1);
  userRepository.put("user1", user1);
  
  /* user2/password2 --> GUEST */
  Set<GrantedAuthority> authorities2 = new HashSet<GrantedAuthority>();
  authorities2.add(authorityGuest);
  UserDetails user2 = new UserDetailsImpl("user2", "password2", authorities2);
  userRepository.put("user2", user2);
  
  /* user3/password3 --> ADMIN + GUEST */
  Set<GrantedAuthority> authorities3 = new HashSet<GrantedAuthority>();
  authorities3.add(authorityAdmin);
  authorities3.add(authorityGuest);
  UserDetails user3 = new UserDetailsImpl("user3", "password3", authorities3);
  userRepository.put("user3", user3);
 }
 
 public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
  UserDetails matchingUser = userRepository.get(username);
  
  if(matchingUser == null){
   throw new UsernameNotFoundException("Wrong username or password");
  }
  
  return matchingUser;
 }

}


  • In the Controller class, we add the two following URL mapping. As as result, GET requests for /login URL will display the custom login page, while requests for the same URL with the "errorLogin" parameter will display the same custom login page with an additional "loginFailed" model attribute. This attribute is checked in the JSP page, to display an error message, if neccessary.
 @RequestMapping(method=RequestMethod.GET, value="/login")
 public String displayLoginPage(){
  return "myLoginPage";
 }
 
 @RequestMapping(value="/login", params="errorLogin")
 public String directToLoginPageWithError(Model model){
  // Adding an attribute to flag that an error happened at login
  model.addAttribute("loginFailed", true);

  return "myLoginPage";
 }

Testing the application

  • Custom login page:
  • Login with bad credentials


  • Login with user1/password1
  • Login with user2/password2

In this last case, user2 is authenticated but not authorized to access the home.go page. In the Spring configuration "MyDispatcherServlet-servlet.xml" file, we specified that the home.go page is restricted to user with role ADMIN with the following configuration element:

<security:intercept-url pattern="/home.go" access="hasRole('ADMIN')" /> 

Source code

The source code of this example application can be checked out here.

Sunday, December 2, 2012

Spring MVC: implementing authentication and authorization using Spring security

In this post, we'll go through the few steps that will allow you to implement both authentication and authorization security features in a Spring MVC application.

We'll use the Spring MVC demo application we've developed in a previous post as starting point. Feel free to take a look at it   first (here's the post), if you want to follow the steps below one at a time.

You'd rather get down to business right away? Here are the sources of this application (pick the master branch).

Tools and libraries
  • Eclipse Indigo
  • Spring-core 3.1.1
  • Spring-security 3.1.0
  • Tomcat 7
  • Maven 3

STEP 1 - Adding necessary Maven dependencies

In order to use Spring Security, we'll need to add the following dependencies in our pom.xml configuration:
  • spring-security-taglibs
  • spring-security-config
  • standard
  • jstl
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>Spring-MVC-Tutorial</groupId>
 <artifactId>Spring-MVC-Tutorial</artifactId>
 <packaging>war</packaging>
 <version>0.0.1-SNAPSHOT</version>

 <properties>
  <spring-version>3.1.1.RELEASE</spring-version>
  <spring-security-version>3.1.0.RELEASE</spring-security-version>
 </properties>

 <build>
  <plugins>
   <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-war-plugin</artifactId>
    <version>2.2</version>
    <configuration>
     <!-- specifiy which directory within the project hierarchy will be considered 
      as the root directory from the generated war file -->
     <warSourceDirectory>WebContent</warSourceDirectory>
    </configuration>
   </plugin>
  </plugins>
 </build>

 <dependencies>
  <!-- Spring Core -->
  <dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-core</artifactId>
   <version>${spring-version}</version>
  </dependency>
  <dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-context</artifactId>
   <version>${spring-version}</version>
  </dependency>
  <dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-webmvc</artifactId>
   <version>${spring-version}</version>
  </dependency>
  <!-- Spring security -->
  <dependency>
   <groupId>org.springframework.security</groupId>
   <artifactId>spring-security-taglibs</artifactId>
   <version>${spring-security-version}</version>
  </dependency>
  <dependency>
   <groupId>org.springframework.security</groupId>
   <artifactId>spring-security-config</artifactId>
   <version>${spring-security-version}</version>
  </dependency>
  <!-- standard.jar -->
  <dependency>
   <groupId>taglibs</groupId>
   <artifactId>standard</artifactId>
   <version>1.1.2</version>
  </dependency>
  <!-- JSTL -->
  <dependency>
   <groupId>javax.servlet</groupId>
   <artifactId>jstl</artifactId>
   <version>1.2</version>
  </dependency>
 </dependencies>
</project>

STEP 2 - Enabling Spring Security in the web application configuration

  • Once we add Spring Security features, unlike basic Spring MVC applications (in which, by default, the DispatcherServlet initialization will look for a file named [servlet-name]-servlet.xml in the WEB-INF directory), we'll need to explicitly define a ContextLoaderListener listener as well as a context parameter named contextConfigLocation whose value is the relative path to your Spring configuration file, in the web.xml file.
Here's the added part:

 <listener>
  <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
 </listener>

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


  • Then, yet in the web.xml file, we'll add Spring security filter definition so that requests that are sent to our dispatcher servlet will first be intercepted by this security filter so that authentication/authorization can be checked against the request content, origin, and so on. At the same time, we'll define an URL mapping to this security filter to specify which requests we want to have the security filter intercept and process.
Here's the added part:
 
  springSecurityFilterChain
  org.springframework.web.filter.DelegatingFilterProxy
 

 
  springSecurityFilterChain
  /*
 
We are now done with the web.xml file and it looks like this:


 Spring MVC tutorial

 
  org.springframework.web.context.ContextLoaderListener
 

 
  contextConfigLocation
  
      /WEB-INF/MyDispatcherServlet-servlet.xml
  
 

 
  MyDispatcherServlet
  org.springframework.web.servlet.DispatcherServlet
 

 
  MyDispatcherServlet
  *.go
 

 
  springSecurityFilterChain
  org.springframework.web.filter.DelegatingFilterProxy
 

 
  springSecurityFilterChain
  /*
 

STEP 3 - Configuring Spring Security


In this step, we'll edit our Spring configuration file (that we've defined as being the MyDispatcherServlet-servlet.xml file back at the step 2), and configure the security features we want to use, that is, we'll configure authentication through a login page, and authentication through access right that the user must have in order to access a certain page.
Starting from the MyDispatcherServlet-servlet.xml file we created in the basic Spring MVC application tutorial, here are the added parts:

 <security:http auto-config="true">
  <security:intercept-url pattern="/home.go" access="ROLE_REGISTERED_USER"/> 
  <security:logout logout-success-url="/home.go"/>
 </security:http>
 
 <security:authentication-manager>
  <security:authentication-provider>  
   <security:user-service>
    <security:user name="user1" password="demo" authorities="ROLE_REGISTERED_USER" />
    <security:user name="user2" password="demo" authorities="ROLE_FREE_USER" />
   </security:user-service>
  </security:authentication-provider>
 </security:authentication-manager>

  • By defining the auto-config attribute value to true in the <security:http> element, we are using the default security features that are provided by Spring Security libraries, that is, it provides us, among others, a default login page and access rights checking
  • In the <security:intercept-url> element, we specify the URLs whose access should be restricted to users with the role(s) that we specify in the access attribute. In this example, we are basically saying that a user should be authenticated (he must log in through the default login page) and hold the ROLE_REGISTERED_USER role in order to access the "home.go" page.
  • With the <security:authentication-manager> element, we can specify how (directly querying a DB, providing a custom authentication/authorization service, through LDAP, ...)
    • username and password are retrieved to perform authentication checking
    • roles are retrieved to perform authorization checking
    In this example, we simply hard coded the usernames, their associated password and roles directly in the Spring configuration file.
Here's the whole Spring configuration file:


 
 
 

 
 

 
  
   
   
 
 
 
   
  
 
 
 
    
   
    
    
   
  
 


STEP 4 - Testing
Remark: in order to make the resulting application easier to test, we'll add a logout button to the page to be displayed, as follows:


<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
 pageEncoding="ISO-8859-1"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>




Spring-MVC-Tutorial


 Welcome my Spring-MVC-Tutorial homepage
 "> Logout


Case 1 - Unauthenticated user

Once the application is deployed, try to access the home.go page and you'll be redirected to the default login page.



Case 2 - Wrong credentials

Try to login with wrong credentials: you'll be redirected to the login page but take a closer look to the address bar. See the  "spring_security_login?login_error"? This is the default behavior of Spring security when relying on its generated login page, to redirect the user to the login page and the login_error parameter is used to detect that the previous login attempt failed, so an error message must be displayed.



Case 3 - Authenticated and authorized user


On the login page, log in using the following credentials user1/demo. As the "user1" user has the ROLE_REGISTERED_USER role that is required to access the home.go page (remember the roles we've defined at step 3?), you'll be successfully directed to the required home.go page.


Case 4 - Authenticated but unauthorized user

From the previous page, click on the logout link to get back to the login page, then log in with the credentials user2/demo. As user2 only has the ROLE_FREE_USER role, we'll get an HTTP 403 ERROR page indicating that the user is not authorized to access the required page.


Sources

The source code of this example project is accessible here.

Thursday, July 12, 2012

Spring MVC + Hibernate: testing the persistence layer (DAOs) with TestNg

Whenever you're working on a Spring MVC project, you might want to unit tests each single layer of your application. In this post, we'll see how we can perform unit testing on the persistence layer, using TestNg. More specifically, we'll go through unit testing a persistence layer that is built upon a DAO pattern, implemented using Hibernate.

DAO classes
The DAO classes that we are going to test in this example are structured like this:


As general CRUD methods are implemented in the GenericDaoImpl abstract class, we'll consider that our UserDaoImpl class is empty, in order to keep things simple:

@Repository
public class UserDaoImpl extends GenericDaoImpl<user, long=""> implements UserDao {
 // methods specific to this concrete DAO
}



As you can see, this class is annotated with @Repository, which registers it as a "Repository" type Spring bean.

Spring configuration

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:tx="http://www.springframework.org/schema/tx"
 xmlns:context="http://www.springframework.org/schema/context"
 xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
  http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.1.xsd
  http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd">

 <context:component-scan base-package="be.glimmo">
 
 <!-- Enabling annotation-driven transaction management -->
 <tx:annotation-driven />

 <!-- Hibernate SessionFactory -->
 <bean id="sessionFactory"
  class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
  <property name="dataSource" ref="dataSource" />
  <property name="hibernateProperties">
   <props>
    <!-- Use the C3P0 connection pool provider -->
    <prop key="hibernate.c3p0.min_size">5</prop>
    <prop key="hibernate.c3p0.max_size">20</prop>
    <prop key="hibernate.c3p0.timeout">1800</prop>
    <prop key="hibernate.c3p0.max_statements">50</prop>
    <prop key="hibernate.c3p0.idle_test_period">300</prop>
    <prop key="hibernate.dialect">org.hibernate.dialect.DerbyDialect</prop>
    <prop key="hibernate.hbm2ddl.auto">create-drop</prop>

    <!-- Show and print nice SQL on stdout -->
    <prop key="show_sql">true</prop>
    <prop key="format_sql">true</prop>
   </props>
  </property>
  <property name="packagesToScan" value="be.glimmo.domain" />
 </bean>

 <!-- Defining a transaction manager bean (used for annotation-driven transaction 
  management -->
 <bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
  <property name="sessionFactory" ref="sessionFactory" />
  <property name="dataSource" ref="dataSource" />
 </bean>

 <!-- Defining the Datasource bean -->
 <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
  <property name="driverClassName" value="org.apache.derby.jdbc.ClientDriver" />
  <property name="url" value="jdbc:derby://localhost:1527/glimmo-testdb" />
  <property name="username" value="glimmo" />
  <property name="password" value="password" />
  <property name="minIdle" value="5" />
  <property name="maxActive" value="10" />
  <property name="defaultAutoCommit" value="false" />
 </bean>
</beans>

An important thing here: make sure you specify a "dataSource" bean. Although we would usually declare a bean with the ID "dataSource", when working with Spring, just know that it is also possible to have Spring properly configured without this kind of bean. Nevertheless, configuring unit testing with TestNg simply requires us to declare this bean. More (we'll see why, later).

TestNg test class
Now, let's take a look at an example of test class that will allow us to test each single method of our DAO:


@Test
@ContextConfiguration(locations={"classpath:Glimmo-context-test-configuration.xml", "classpath:Glimmo-persistence-test-configuration.xml"})
public class TestUserDaoDummy extends AbstractTransactionalTestNGSpringContextTests{
 
 // TestNg Data Providers
 Object[][] users = new Object[][]{
   new Object []{"user1", "user1@test.com", "user_firstname", "user_lastname", 
     UserGrade.ADMIN, "password", null}
 };
 
 @DataProvider(name="usersProvider")
 public Object[][] provideUsersForCreation(){
  return users;
 }
 
 @Autowired
 private UserDao userDao;
 
 @Test(dataProvider="usersProvider")
 @Rollback(false)
 public void testUserCreation(String username, String email, String firstName, String lastName, UserGrade userGrade, String password, Date gradeEnd) {
  User newUser = new User(username, email, firstName, lastName);
  newUser.setGrade(userGrade);
  newUser.setPassword(password);
  userDao.save(newUser);
  
  Assert.assertNotEquals(super.countRowsInTable("USERS"), 0);
 }
}



There are 2 important things to pay attention to, here:

  • Have the test class extends AbstractTransactionalTestNGSpringContextTests
The AbstractTransactionalTestNGSpringContextTests class helps you manage the transactional aspects when testing the methods from the DAO class (as a matter of fact, it sets the @Transactional annotation at class level, so that you don't need to worry about transactions when writing your test methods). It also provide convenience methods (based upon the underlying SimpleJdbcTemplate instance...) to query the DB, such as executeSqlScript(...) and countRowsInTable(...). This class expects a bean with the ID "dataSource". That's the reason why I said on the previous section that our Spring configuration has to specify such a bean.



  • Annotate your test class with @ContextConfiguration
This annotation is provided by Spring for test purposes and allows you to load Spring configuration file. This annotation supports several ways to specify which configuration to load but its "locations" attribute is likely the easiest and most used one: we just have to provide a comma separated list of String values. Each of them , referring to a Spring XML configuration file that needs to be loaded in order to initialize the Spring application context. In the example, I prefixed each reference with "classpath:" meaning that the configuration files will be retrieved from the classpath of my project (since I'm working on a Maven based project, I simply put them in the src/test/resources directory).

Now, you're able to wire the DAO classes (as long as they're registered as Spring beans) into you test class, and test every single of their methods. VoilĂ !

Tuesday, May 29, 2012

A quick tutorial to Spring-MVC with Maven

In this post, we'll see how to get started with a Spring MVC project in a few steps.

Tools

  • Maven 3
  • Tomcat 6
  • Eclipse Helios/+
    • m2eclipse plugin
    • Spring IDE plugin

1 Creating the web project

First, let's create a Dynamic Web Project : 


Name it Spring-MVC-Tutorial and specify Tomcat 6 as the web server on which the application will be deployed:


And click on FINISH.

Now, in order to enable Maven support, create the following directories under the src directory : 
  • main/java
  • main/resources
  • test/java
  • test/resources
As the src directory actually is a source directory, once you've created the mentioned sub directories, these will look like packages, at first:


Then, right-click on the project and choose Maven -> Enable dependency management. This will open a Wizard in which you'll be able to configure Maven related information such as the group ID, the artifact ID, and so on. Following this tutorial, simply keep the default values and click on FINISH.

Now, our project has become a Maven-based project, which looks like this : 


2 Adding Spring Maven dependencies

In the pom.xml file, add the following dependencies, so that Maven retrieves the libraries necessary to a Spring-MVC project : 
  • spring-core
  • spring-context
  • spring-webmvc
As soon as you've added these dependencies, you could see that Maven has automatically downloaded the related libraries and added them to the project's classpath : 


Here's what our Maven configuration file looks like :

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <groupId>Spring-MVC-Tutorial</groupId>
 <artifactId>Spring-MVC-Tutorial</artifactId>
 <packaging>war</packaging>
 <version>0.0.1-SNAPSHOT</version>

 <properties>
  <spring-version>3.1.1.RELEASE</spring-version>
 </properties>

 <build>
  <plugins>
   <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-war-plugin</artifactId>
    <version>2.2</version>
    <configuration>
     <!-- specifiy which directory within the project hierarchy will be considered 
      as the root directory from the generated war file -->
     <warSourceDirectory>WebContent</warSourceDirectory>
    </configuration>
   </plugin>
  </plugins>
 </build>  

 <dependencies>
  <dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-core</artifactId>
   <version>${spring-version}</version>
  </dependency>
  <dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-context</artifactId>
   <version>${spring-version}</version>
  </dependency>
  <dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-webmvc</artifactId>
   <version>${spring-version}</version>
  </dependency>
 </dependencies>
</project>

Note that we have added the "maven-war-plugin" to specify that at the WAR file generation, the "WebContent" directory should be considered as being the web application root directory.

3 Configuring the DispatcherServlet

A Spring-MVC project follows the "Front controller" pattern : we'll define a servlet based on Spring's DispatcherServlet class. This servlet serves as "front controller" and will handle incoming requests. It will then dispatch them to the appropriate controller classes, based on each request's URL.

Let's define the servlet : in the web.xml file (which is located in WebContent/WEB-INF):


<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
 id="WebApp_ID" version="2.5">
 <display-name>Spring MVC tutorial</display-name>
  
 <servlet>
  <servlet-name>MyDispatcherServlet</servlet-name>
  <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
 </servlet>
 
 <servlet-mapping>
  <servlet-name>MyDispatcherServlet</servlet-name>
  <url-pattern>*.go</url-pattern>
 </servlet-mapping>
</web-app>

As you can see, in our example, we've mapped all incoming requests with the ".do" extension to be handled by the servlet named "MyDispatcherServlet", which is the front controller to our application.

4 Spring context configuration

Now, we'll create the Spring configuration XML file : under the WEB-INF directory, create a new Spring configuration file. As we've installed the Spring IDE plugin, (this plugin is very handy when it comes to Spring configuration as it provides, among other things, some auto-completion and validation), right-click -> New -> Other -> Spring -> Spring Bean configuration file

By default, with a Spring-MVC project, Spring will look for a Spring configuration file that is named as follows : [DispatcherServlet's name]-servlet.xml
So in our case, we'll name our Spring configuration file : MyDispatcherServlet-servlet.xml

Here's the content of our Spring configuration file : 


<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:context="http://www.springframework.org/schema/context"
 xmlns:mvc="http://www.springframework.org/schema/mvc"
 xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
  http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd
  http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc-3.1.xsd">
 
 <!-- Enabling Spring beans auto-discovery -->
 <context:component-scan base-package="controller" />

 <!-- Enabling Spring MVC configuration through annotations -->
 <mvc:annotation-driven />

 <!-- Defining which view resolver to use -->
 <bean class= "org.springframework.web.servlet.view.InternalResourceViewResolver" > 
  <property name="prefix" value="/WEB-INF/views/" /> 
  <property name="suffix" value=".jsp" /> 
 </bean>
</beans>

  • We have enabled Spring beans auto-discovery by adding <context:component-scan base-package="controller" />
  • Spring-MVC related configuration will be defined through annotations as we have added <mvc:annotation-driven />
  • We will be using the InternalResourceViewResolver to define which view should be rendered to the user, once the controller class has handled incoming requests. More on this below... For now, just try to remember that we gave its "prefix" property the value "/WEB-INF/views/", and its "suffix" property the vlaue ".jsp".

5 Implementing the controller

Create a package named "controller". This package name is not arbitrary. It should match the package name that we've specified in the <context:component-scan> element in the Spring configuration file. 

Then, create a class as follows. You may choose another the name as it is not significant : due to our Spring configuration, Spring will scan the "controller" package and look for classes with Spring annotations (such as @Component, @Controller, @Service, and @Repository).


package controller;

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;

@Controller
public class MyController {
 
 @RequestMapping(method=RequestMethod.GET, value="/home")
 public String handleRequest(){
  return "welcome";
 }
}




  • The @Controller annotation indicates that our class is a Spring registered bean
  • The @RequestMapping annotation marks the handleRequest( ) method as a method that will be executed to handle GET method requests with /home URI.
Basically, whenever an incoming request is handled by the handleRequest( ) method, as it returns unconditionally "welcome",  the view resolver from type InternalResourceViewResolver will concatenate the defined prefix, to this value, and then to the defined suffix.

So, in our case, the view to be rendered would be : /WEB-INF/views/welcome.jsp

6 Create the sample view file (JSP)

  1. First, create a directory named "views" under WEB-INF
  2. In the "views" directory, create a JSP page named "welcome.jsp" as follows : 

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
    pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Spring-MVC-Tutorial</title>
</head>
<body>
Welcome my Spring-MVC-Tutorial homepage
</body>
</html>


7 WAR file generation and deployment

With the M2Eclipse plugin, simply run the project as "Maven package". Then copy the generated WAR file from the "target" directory into the "webapps" directory from Tomcat.

8 Testing the application

Open a browser, type the following URL : 
  • http://localhost/Spring-MVC-Tutorial-0.0.1-SNAPSHOT/home.go
And you will get to the following page : 

9 Source code

The project we went through step by step, may be downloaded/checked out (github repository) here. Just make sure you get the master branch of the Spring-MVC-Tutorials repository.

Friday, May 18, 2012

TestNG for starters : running a same test method several times with different parameter values

When using TestNg to write unit tests, one of the most common mistake I see people make is writing a test method in which they make several assertions in order to test giving different values as input to the method to be tested.

To illustrate this common mistake, let's assume we have a class named StringConcatener, which provides a static method to concatenate 2 given String objects :

public class StringConcatener {
 
 public static String concatStrings(String s1, String s2){
  if(s1 == null){
   s1 = "null";
  }
  
  return s1 + s2;
 }
}

Now, we are going to write a test class in which we will implement a method that will check the behavior of our concatStrings( ) method against different input values. To do this, new TestNg users often tend to stuff lots of assertions inside a same test method, just like this : 


public class TestStringConcatener {

 @Test
 public void testConcatener() {
  Assert.assertEquals(StringConcatener.concatStrings("null", "null"), "nullnull");
  Assert.assertEquals(StringConcatener.concatStrings(null, null), "nullnull");
  Assert.assertEquals(StringConcatener.concatStrings("StringA", "StringB"), "StringAStringB");
  Assert.assertEquals(StringConcatener.concatStrings("StringA", null), "StringAnull");
  // and many other assertions...
 }
}

This test method works fine but only if every assertions get the expected result. Suppose the 1st assertion does not get the expected result. Then, none of the assertions that follows it will be tested. That, obviously, is not how you want your test class to behave.

Solution


  1. Write a test method with 3 arguments : the 2 String objects to be concatenated + the expected result
  2. Marked this test method with @Test(dataProvider="EqualsAssertionsProvider") : this method is a test method which expects input from the DataProvider named "EqualsAssertionsProvider"
  3. Write the method that will provide the set of input values to the test method, and mark it with @DataProvider(name="EqualsAssertionsProvider"). The name attribute in the @DataProvider annotation specifies its name. 

public class TestStringConcatener {
 
 @DataProvider(name="EqualsAssertionsProvider")
 public Object[][] createConcatenationAssertionSet(){
  return new Object[][]{
    new Object []{"null", "null", "nullnull"},
    new Object []{null, null, "nullnull"},
    new Object []{"StringA", "StringB", "StringAStringB"},
    new Object []{"StringA", null, "StringAnull"},
  };
 }
 
 @Test(dataProvider="EqualsAssertionsProvider")
 public void testConcatener(String s1, String s2, String expectedResult){
  Assert.assertEquals(StringConcatener.concatStrings(s1, s2), expectedResult);
 }
}

As you can see, in the example above, the createConcatenationAssertionSet( ) method returns a 2 dimensional Object array :

  • the first dimension determines how many input sets the DataProvider holds (that is, how many times our test method will run)
  • the second dimension holds Object arrays that contains the values for each argument from our test method. As there are 3 arguments in our test method, each of these Object arrays contains 3 values.
Now that you're working with a DataProvider, should one of your assertions fail, the following ones will still be tested. To illustrate that, let's modify the expected result of the third input set from our DataProvider : 

new Object []{"StringA", "StringB", "StringAStringB"}

becomes

new Object []{"StringA", "StringB", "StringAStringX"}
Let's run our TestClass and see what are the results :


As you can see, the third assertions failed (the exact reason is shown on the right column), but the 4th assertions has still been checked. VoilĂ !

Look out!

As strange as it may look, DataProvider methods can only have 2 type of returns : Object[ ][ ] or Iterator<Object>[ ]. Maybe that would change in the future but at the time I wrote this post, I was using the latest available version of TestNg (6.3.1)

Sunday, April 8, 2012

Jamon : a quick and easy way to monitor Java web applications' performances

In this post, I would like to introduce a very handy way to monitor a Java web application's performance, using Jamon (click on the link to get to the Jamon project homepage). 


There are numerous ways to monitor the performances from a Java web application, but how easy it is set up and what kind of information you need in return, will determine the solution you'll choose. This could go from printing out (or logging) execution time, which has been explicitly calculated (stop time - start time), on the standard exit, to AOP using Spring Aspect or AspectJ.


The most interesting feature Jamon provides, is a web application showing you the monitoring's result.

Tools

  • Apache Tomcat 6.0.32
  • Jamon 2.73

How to use it (basic usage)

  1. Download Jamon distribution file
  2. Copy the jamon-2.73.jar library into the classpath of the project for which you want to enable monitoring.

    Remark
    Actually, you would rather copy this library to the directory from you web server, that contains the libraries that are shared across all the deployed applications. In my case, as I deployed a sample application on a Tomcat server, I copied the jamon-2.73.jar library into the %TOMCAT_HOME%/lib directory. Also, if you intend to use the provided monitoring console, you should definitely shared the library across all the applications.
  3. Deploy the provided monitoring console by copying the jamon.war file from the Jamon distribution to the %TOMCAT_HOME%/webapps directory.
  4. Add monitoring instructions to the code section you want to watch. As an example, here's some code to illustrate a practical use of Jamon : 

package org.blog.khy;

import java.io.IOException;
import java.util.Random;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import com.jamonapi.Monitor;
import com.jamonapi.MonitorFactory;

/**
 * Servlet implementation class JamonDemoServlet
 */
public class JamonDemoServlet extends HttpServlet {
 private static final long serialVersionUID = 1L;
 private static final Random RANDOM = new Random();
 
 @Override
 protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
  doGet(req, resp);
 }

 @Override
 protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
  String action = req.getParameter("action");

  if (action.equalsIgnoreCase("LOGIN")) {
   login(req, resp);
  } else if (action.equals("CHECKOUT")) {
   checkoutCart(req, resp);
  }
 }

 private void login(HttpServletRequest req, HttpServletResponse resp) throws IOException {
  Monitor mon = MonitorFactory.start("login");

  // simulating login process
  long randomProcessTime = (long) (RANDOM.nextDouble() * 1000.0);
  resp.getWriter().print("PROCESSED LOGIN REQUEST");
  
  try {
   Thread.sleep(randomProcessTime);
  } catch (InterruptedException e) {
   e.printStackTrace();
  }

  mon.stop();
 }

 private void checkoutCart(HttpServletRequest req, HttpServletResponse resp) throws IOException {
  Monitor mon = MonitorFactory.start("checkout");

  // simulating cart checkout process
  long randomProcessTime = (long) (RANDOM.nextDouble() * 3000.0);
  resp.getWriter().print("PROCESSED CHECKOUT REQUEST");
  
  try {
   Thread.sleep(randomProcessTime);
  } catch (InterruptedException e) {
   e.printStackTrace();
  }

  mon.stop();
 }
}


As you can see,  it's very simple to use Jamon : first, you'll retrieve and start a Monitor object by executing MonitorFactory.start(String label). The "label" argument designates the name under which the code section to monitor will be identified within the monitoring console. 


At the end of the code section that you're monitoring, just call the stop( ) method on the Monitor object. 


And voilĂ ...


I've deployed this sample servlet and had it process a few requests (some with the "action" parameter = LOGIN, some otheres with the value CHECKOUT. 


Monitoring console

Finally, open the Jamon monitoring console which is deployed at the following address : http://localhost:8080/jamon

Click on the "JAMon Admin Page" link and you'll be brought to the page from which you could access all the monitoring info : 




Among all the infos, you'll have the number of times your monitored code has been executed, the average execution time, the longest/shortest execution time, and so on.

Remarks

You might think that Jamon is only useful during development but from my personal experience, you could deploy it along with your application into production : 
  • its footprint is practically non significative
  • you can disable/enable monitoring in one click, from the administration console
  • you can filter the monitor that you want to display in the list
That was just a slight overview of Jamon's features, you should definitely take a look at its documentation, as it provides some other monitoring functionalities.

Tuesday, March 13, 2012

Remote debugging with Tomcat with Eclipse

Lately, as I was handing over some projects to a new colleague, I realized that remotely debugging a Java application which is deployed on a Tomcat instance, isn't actually trivial to every developer. 
That being said, I guess it is legitimate for a Java developer not to know that nice feature since most of us will probably work through embedding an instance of Tomcat within Eclipse.

However, there are situations in which you would definitely have to debug remotely. That's the reason why I think this topic is worth writing a post...

Configuration
As stated in the Apache Tomcat documentation, in order to enable remote debugging support, you'll need to pass the following argument to the JVM used by Tomcat, when it starts : 

-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n

Since Apache has already announced that they'll stop supporting Tomcat 5 soon, therefore I won't address this version of Tomcat's configuration. 

Regarding Tomcat 6 (and later), it already provides all the required configuration in the catalina.bat file : the default transport type is already set to "dt_socket" (the other supported transport type is "shared memory" but this one is not commonly used - actually, I haven't used it so far so I won't be able to tell you what it is about precisely) and the default port is set to 8000. In case the port number 8000 is already in use in your environment, you can simply change it by editing the catalina.bat file. 

Here's the section from the catalina.bat file that would interest you :

if not ""%1"" == ""jpda"" goto noJpda
set JPDA=jpda
if not "%JPDA_TRANSPORT%" == "" goto gotJpdaTransport
set JPDA_TRANSPORT=dt_socket
:gotJpdaTransport
if not "%JPDA_ADDRESS%" == "" goto gotJpdaAddress
set JPDA_ADDRESS=8000
:gotJpdaAddress
if not "%JPDA_SUSPEND%" == "" goto gotJpdaSuspend
set JPDA_SUSPEND=n
:gotJpdaSuspend
if not "%JPDA_OPTS%" == "" goto gotJpdaOpts
set JPDA_OPTS=-agentlib:jdwp=transport=%JPDA_TRANSPORT%,address=%JPDA_ADDRESS%,server=y,suspend=%JPDA_SUSPEND%
:gotJpdaOpts
shift
:noJpda

Suppose you need to change the default port, you'll, then, set another value to the JPDA_ADDRESS variable.

Running Tomcat with remote debugging enabled
  • deploy the application you need to debug as usually
  • start Tomcat by executing the catalina.bat script and providing the "jpda" argument 
(ex.: D:\Develtools\apache-tomcat-7.0.26\bin>catalina jpda start)

Then, all you need to do is to create a remote Java application in Eclipse through these few steps : 

1° Open the debug configurations 
2° Create a new Remote Java application : 


3° Specify the project you're debugging (in my example, I've configured remote debugging for one on my sample projects, named "Blog - Remote Tomcat debugging")
4° Specify the host on which the application to debug is deployed
5° Specify the port that is opened for debugging purpose (same as the one configured as JPDA_ADDRESS in the catalina.bat file from Tomcat)
6° Launch the Remote application by clicking on "Debug" 

At this point, you could set breakpoints wherever you want in the project's source code and if the code marked with your breakpoints is executed, the running thread will be suspended and you'll be able to watch variables' value, execute expression, and so on.