Testing HTTPS Secured Actions with StrutsTestCase

If you have secured some Struts actions using SSLEXT's Struts plugin (org.apache.struts.action.SecurePlugIn) you will have to invoke the action over https, else SSLEXT will redirect to the configured HTTPS port.

So in order to test secured actions using MockStruts test cases you need to inform SecurePlugIn that the request came over https. This is quite easy as the HttpServletRequestSimulator class that's used by MockStruts has a setScheme method. All you have to do is set the scheme to HTTPS in the inherited request object before calling the actionPerform method in the test class.

e.g.

public class LoginTest extends MockStrutsTestCase { public void testlogin() { setConfigFile("/WEB-INF/struts-config.xml"); setRequestPathInfo("/login"); addRequestParameter("username", "test"); addRequestParameter("password", "test1234"); //set the request's scheme to HTTPS request.setScheme("HTTPS"); //invoke action actionPerform(); verifyNoActionErrors(); verifyForward("success"); } }

Speed up MockStruts Test Execution by Caching Spring Context

If you are using MockStruts to test your Struts/Spring application most of your test execution time would be spent on initializing or trying to initialize the Spring context for each test method.

This is true if you use Spring's ContextLoaderPlugIn, where it tries to initialize a custom spring context using the parent context.

Spring will look for the parent context in the ServletContext object where it store it. Since MockStruts will create a new ServletContext for each test method Spring will try to create the context each time. This results in addition of about 4 second per test method (on my workstation).

Note: I'm using MappingDispatchAction with multiple actions in a single Action class, therefore I have mutiple test methods in a single test class too.

The above 4 second penalty per test method can be removed by simply caching and storing the Spring context in ServletContext object before each test execution. This reduced the execution time of the whole test suite drastically in the application I was working on.

In order to achieve the above I used a base class extending MockStrutsTestCase as shown below and used it as the parent class for all the Struts test cases

import org.springframework.context.ApplicationContext; import org.springframework.web.context.ContextLoader; import org.springframework.web.context.WebApplicationContext; import servletunit.struts.MockStrutsTestCase; public abstract class BaseStrutsTestCase extends MockStrutsTestCase { /** Spring context */ private static ApplicationContext applicationContext; /** * Setup Spring context * * @throws Exception * exception */ protected void setUp() throws Exception { super.setUp(); if (applicationContext == null) { // this is the first time. Initialize the Spring context. applicationContext = (new ContextLoader()).initWebApplicationContext(getRequest().getSession() .getServletContext()); } else { // Spring context is already initialized. Set it in servlet context // so that Spring's ContextLoaderPlugIn will not initialize it again getRequest().getSession().getServletContext().setAttribute( WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, applicationContext); } } /** * Returns the Spring application context * * @return initialized Spring application context */ public ApplicationContext getApplicationContext() { return applicationContext; } }

Also remember to set forkMode to perBatch or once in ants junit task as shown below if you have set the fork attribute to true.

<junit fork="true" forkmode="once" haltonfailure="">
...

</junit>

Unit Testing with Junit, Spring and Hibernate - Part 2

This is a continuation from my previous post on Spring and MockStrutsTestCase and focus on testing Hibernate DAO's. As I mentioned in the previous post, Spring framework provides a nifty base class (AbstractTransactionalDataSourceSpringContextTests) that provides automatic transaction rollback, exposing a JDBC template to interact with the DB and auto wiring of beans.

Lets take a simple DAO class that save a User object to the database:

public class UserDaoImpl extends HibernateDaoSupport implements UserDao { public void save(User user) { getHibernateTemplate().save(user); } }

Now in order to test this you would write a test class as below extending from AbstractTransactionalDataSourceSpringContextTests class.

public class UserDaoTest extends AbstractTransactionalDataSourceSpringContextTests { private UserDao userDao; private SessionFactory sessionFactory = null; protected String[] getConfigLocations() { return new String[]{"test-spring-config.xml"}; } /** * Spring will automatically inject UserDao object on startup * @param userDao */ public void setUserDao(UserDao userDao) { this.userDao = userDao; } /** * Spring will automatically inject the Hibernate session factory on startup * @param sessionFactory */ public void setSessionFactory(SessionFactory sessionFactory) { this.sessionFactory = sessionFactory; } /** * Test the save method * */ public void testSave(){ String query = "select count(*) from user where first_name = 'Firstname'"; int count = jdbcTemplate.queryForInt(query); assertEquals("A user already exists in the DB", 0, count); User user = new User(); user.setFirstName("Firstname"); userDao.saveUser(user); // flush the session so we can get the record using JDBC template SessionFactoryUtils.getSession(sessionFactory, false).flush(); count = jdbcTemplate.queryForInt(query); assertEquals("User was not found in the DB", 1, count); } }

The test class has to implement the protected String[] getConfigLocations() method from the base class and return a String array of Spring config files which will be used to initialize the Spring context.

UserDao and SessionFactory properties are defined with the setter methods and the base class will take care of injecting them automatically from the Spring context. Auto wiring will not work if there are multiple objects implementing the same interface. In such a case you can remove the setter method and retrieve the object using the exposed applicationContext as below.

/** * Overridden method from base class which gets called automatically */ protected void onSetUpBeforeTransaction() throws Exception { super.onSetUpBeforeTransaction(); userDao = (UserDao) applicationContext.getBean("userDao"); }

The base class also exposes a JDBC template object (jdbcTemplate) that can be used to query data or setup test data in the database. Note that you need to have a data source and a transaction manager defined in your Spring config in order to use the AbstractTransactionalDataSourceSpringContextTests base class. The data source defined in the config file will be bound to the exposed JDBC template.

In the testSave method first we verify there is no record in the User table where first name equals to 'Firstname' using the jdbc template object. Then we call the save method on the UserDao passing it a User object.

Now we simple verify there is a record in the table where first name equals to 'Firstname'. Before running the query we flush the current Hibernate session to make sure jdbcTemplate can see the newly added record.

Thats it and when the testSave method exits the current transaction will be rolled back and the record inserted to the User table will not be saved. This is great as your test database will always be at a know state at the start and end of a test method.

The spring config file will like below (test-spring-config.xml) :

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd"> <beans> <bean name="userDao" class="com.dao.UserDaoImpl"> <property name="sessionFactory"> <ref bean="sessionFactory"/> </property> </bean> <bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean"> <property name="dataSource"> <ref bean="dataSource"/> </property> <property name="mappingResources"> <list> <value>hibernates/User.hbm.xml</value> </list> </property> <property name="hibernateProperties"> <props> <prop key="hibernate.query.factory_class">org.hibernate.hql.classic.ClassicQueryTranslatorFactory</prop> <prop key="hibernate.dialect">org.hibernate.dialect.OracleDialect</prop> </props> </property> </bean> <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName" value="oracle.jdbc.driver.OracleDriver"/> <property name="url" value="jdbc:oracle:thin:@localhost:1521:ORCL" /> <property name="username" value="test" /> <property name="password" value="test" /> </bean> <bean id="txManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager"> <property name="sessionFactory"><ref local="sessionFactory"/></property> </bean> </beans>

Achieve Automatic Transaction Rollback with MockStrutsTestCase and Spring

Spring provides a convenience base class (AbstractTransactionalDataSourceSpringContextTests which extends the TestCase class from Junit) to automatically rollback any updates made to the database at the end of a test method. This works great when integration testing Service and DAO beans but it wont help when integration testing the Struts layer with MockStrutsTestCase.

Spring does not provide a class such as AbstractTransactionalDataSourceSpringContextTests that extends from the MockStrutsTestCase. This might be due to practical issues with the way Spring context initialization works when using MockStrutsTestCase. I tried achieving the transaction rollback in the same way as was done in the AbstractTransactionalDataSourceSpringContextTests class but it didn't work out as the application code started a new transaction and commited as usual without using the transaction I started in my own subclass of MockStrutsTestCase.

Another option left for me was to go down to the Transaction Manager level and achieve the rollbacks there. The application uses Hibernate at the DAO level and it was using HibernateTransactionManager as the transaction manager implementation when running test cases . Therefore I had to write a new class extending from HibernateTransactionManager which overrides the doCommit() method. The overridden method will call doRollback() method in the super class. This would rollback the current running transaction even if the declarative transaction handling code in Spring calls doCommit on the transaction manager.

package com.xyz.txn;

import org.springframework.orm.hibernate3.HibernateTransactionManager;

public class HibernateRollbackTxnManager extends HibernateTransactionManager {

 /*
  * doCommit method that calls the doRollback method of the super class.
  *
  */
 protected void doCommit(DefaultTransactionStatus txnStatus) {
     super.doRollback(txnStatus);
 }
}

Finally override the default transaction manager in your test spring bean configuration with the rollback only implementation.

  <bean id="txnManager" class="com.com.xyz.txn.HibernateRollbackTxnManager">
      <property name="sessionFactory"><ref local="sessionFactory"></property>
  </bean>

The same strategy would work with other transaction managers such as DataSourceTransactionManager too.

Save Time Fixing Ant Errors With -verbose Switch

Resolving ant errors can be a pain sometimes because of the vague error messages you get on the console. Yesterday I was getting a "Process fork failed." error on my Junit task and all I got on the console was

BUILD FAILED
C:\work\builds\build.xml:58: Process fork failed.

I wasted a couple of hours on google looking for an answer and after failing to fix the issue with several suggested solutions, I stumbled upon one post that suggested enabling the verbose output of Ant. All you had to do was pass -verbose as a command line parameter to ant

ant -verbose <target>

That made ant display lot of details including the actual exception. In my case it was:

C:\work\build\build.xml:58: Process fork failed.
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeAsForked(JUnitTask.java:871)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:679)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitTask.java:1413)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:633)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:341)
at org.apache.tools.ant.Target.performTasks(Target.java:369)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40)
at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
at org.apache.tools.ant.Main.runBuild(Main.java:668)
at org.apache.tools.ant.Main.startAnt(Main.java:187)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
Caused by: java.io.IOException: CreateProcess: C:\bea92\jdk150_04\jre\bin\java.exe ...


I found the issue a little bit above the exception on the console and it was the massive classpath value passed into the java.exe. Obviously the Windows command line has a limitation on the length of command line arguments and the value for classpath was exceeding it.

When I checked the build file I found the error, where it was adding the files in a directory instead of the directory into the classpath. Fixed that small error and all was fine again.

Anyway glad I got to know about the verbose switch in Ant and hopefully I wouldn't have to waste a lot of time again fixing ant issues again.

Testing application generated emails with Apache James server

Most of our applications send out emails to customers, different groups of people within the organization etc... Most of these emails were in HTML and had all sorts of fancy formatting in them. It was a pain developing and testing these emails and they took too much developer time.

We needed an easy way to test them locally in developer machines without using an external SMTP server.

The plan was to run a James server in every developer machine which forwarded all the emails it receives to an email account on the same server.

Following were the steps followed to achieve this:


1. Download and Run James Server

Downloaded the latest zip bundle from apache site (ver 2.3.1). Extracted to a folder and executed run.bat in the bin directory to start the server for the first time. This will extract the james.sar file in apps directory to the apps/james directory. Now you will be able to modify the configuration file (config.xml) in apps/james/SAR-INF.


2. Create a local email account.

Open a command window and type telnet localhost 4555. When asked for the user name and password type root for both. Now you will be in the admin console and create a email account by typing adduser test test. This will create an email account named test with the password set to test.


3. Delete remote delivery mailet.

Open up the config.xml and locate the RemoteDelivery mailet section <mailet match="All" class="RemoteDelivery">...</mailet> and remove the tag including all its content.


4. Add a forward mailet to forward all mails

Insert the following mailet in the place where the RemoteDelivery mailet was.
<mailet match="All" class="Forward">
<forwardto>test@localhost</forwardto>
</mailet>


5. Save config.xml and Restart the James Server


Now all emails generated by the application (which is configured to use the SMTP server on localhost) will be handled by the James server running in the local machine and it will forward all emails to the test@localhost email account regardless of recipient addresses in email messages.

You can configure Outlook Express or any other client to read the mails sent to test@localhost.