Testing Database Code Using JUnit

This post outlines the basic setup that you may need to use HSQL in JUnit, Spring, Maven environment to test database code when you are using JdbcTemplate directly instead of Hibernate.

Step 1: Include the maven dependencies in your pom:

<dependency>
    <groupId>hsqldb</groupId>
    <artifactId>hsqldb</artifactId>
    <version>1.8.0.7</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>commons-collections</groupId>
    <artifactId>commons-collections</artifactId>
    <version>3.2</version>
</dependency>
<dependency>
    <groupId>commons-dbcp</groupId>
    <artifactId>commons-dbcp</artifactId>
    <version>1.2.2</version>
</dependency>

Step 2: Setup bean config that will be used by our test (save as database.xml and put it in the resources folder):

<bean id="dataSource"
        class="org.apache.commons.dbcp.BasicDataSource">
    <property name="driverClassName" 
        value="org.hsqldb.jdbcDriver"/>
    <property name="url" 
        value="jdbc:hsqldb:mem:aname"/>
    <property name="username" value="sa"/>
    <property name="password" value=""/>
    <property name="defaultAutoCommit" value="false"/>
</bean>
<bean id="jdbcTemplate" 
        class="org.springframework.jdbc.core.JdbcTemplate">
    <property name="dataSource" ref="dataSource"/>
</bean>

Step 3: Write the test case(s)

You may find the HSQL documentation (supported data types in chapter 9) and the api doc on JdbcTemplate useful as well.

Of course things will not be that simple due to one simple reason: HSQL will most probably not support all the data types used by your DB (e.g. "bytea" , an array of bytes, is supported by PostGreSQL DB but not by HSQL). But it definitely a headstart and a good way to test your DB.

A Simple Cache That Works

In our last post we saw how to make a custom multiple write-single read class. In this post we see how to use basic caching to help us process information selectively. Caching is a complex thing, ie if you go to finer details. However, we needed something simple that we can log the way we want to (and know for sure that it works). I started with some complicated AOP that caches method results to only find using a basic cache to be more efficient.

There are three basic steps to using cache in the spring environment:

1. Configure the ehcache.xml and put it in your resources folder
EHCache Config

2. Put the required spring configuration, injecting the cache in the required bean
Spring Cache Config

3. Use the cache in the bean as you deem fit:
The multiple write, single read bean that uses caching
A helper bean that stores data being passed around

And, of course, you would need the ehcache and spring cache dependencies if you are using maven:

<dependency>
    <groupId>net.sf.ehcache</groupId>
    <artifactId>ehcache</artifactId>
    <version>1.5.0</version>
    <scope>compile</scope>
</dependency>
<dependency>
    <groupId>spring-cache</groupId>
    <artifactId>spring-cache</artifactId>
    <version>2.4.1</version>
</dependency>

Caching Method Invocation Results

Worked on setting up a cache for a method invocation fetching results from a webservice using Spring Cache AOP and EHCache in a Spring-Maven environment.Long live sourceforge! The spring cache java doc is pretty helpful and this article by Pieter Coucke expands on what you read in the java doc. You can also have a look at my complete configuration (which works) and is based on the article and the java doc.

And if you are using Maven, you would need to add dependencies for ehcache and spring cache.

<dependency>
    <groupId>net.sf.ehcache</groupId>
    <artifactId>ehcache</artifactId>
    <version>1.5.0</version>
</dependency>
<dependency>
    <groupId>spring-cache</groupId>
    <artifactId>spring-cache</artifactId>
    <version>2.4.1</version>
</dependency>

Another Way of Starting ActiveMQ Broker in Spring

I had posted a blog about running an ActiveMQ broker in Spring. Recently, I found an alternative way to start an ActiveMQ message broker in spring environment by injecting a bean based on org.apache.activemq.xbean.XBeanBrokerService:

<bean id="broker" class="org.apache.activemq.xbean.XBeanBrokerService">
   <property name="useJmx" value="true"/>
   <!-- this tells it to create a filesystem store -->
   <property name="persistent" value="true"/>
   <property name="brokerName" value="mySpringBroker"/>
   <!--the queues/topics that this broker starts with-->
   <property name="destinations">
       <list>
           <ref bean="destination1"/>
           <ref bean="destination2"/>
       </list>
   </property>
   <property name="transportConnectors">
       <list>
          <!-- an in vm connector which is nice and fast -->
          <bean class="org.apache.activemq.broker.TransportConnector">
             <property name="uri" value="vm://localhost"/>
          </bean>
          <!-- a connection for external clients specifying the IP of machine deploying the broker, something like tcp://10.10.10.10:61636. Here read from a properties file but can be hard-coded as well-->
          <bean class="org.apache.activemq.broker.TransportConnector">
             <property name="uri" value="${broker.transportExternalConnectorUri}"/>
          </bean>
       </list>
   </property>
</bean>

<bean id="destination1" class="org.apache.activemq.command.ActiveMQQueue">
    <constructor-arg value="com.saveenkumar.myQueue1"/>
</bean>

<bean id="destination2" class="org.apache.activemq.command.ActiveMQQueue">
    <constructor-arg value="com.saveenkumar.myQueue2"/>
</bean>

In fact,the package org.apache.activemq.xbean provides various options (beans) to start the broker in a spring environment.

The Wierd Persistent Quartz Job

I recently faced a problem with getting quartz to persist the jobs in case of a scheduler shut down. Penning down how it got solved (with Ben's help). 

My initial scheduler config looked like this.

Also, when I configured my stateful job, I set volatility and request recovery to true besides putting in job class, name and group. Sadly, the job never-ever persisted when the system re-started. 

Miraculously, this started working fine when config was replaced by this configuration (only scheduler config is different).

Plus when I configured the stateful job, I set durability to true and always put in job class, name and group. Of course you can add what you want to the data map (as long as it is Serializable). 

What I don't understand is that even when I have not set either volatility or request recovery to true, how setting only durability to true takes care of persisting the Job between shutdowns and startups. Whatever it takes to make it work... Quirky but may be helpful to you if you face a similar problem. Cheers.

Database Connection Pooling in Hibernate

I was looking for a way to control connection pooling in Hibernate inside a Spring environment. God bless Apache foundation for their amazing code helps, as I found the answers in DBCP. Which-ever hibernate session factory you use, use the following data source bean in your configuration xml to control connection pooling:

    <bean id="internalDataSource" class="org.apache.commons.dbcp.BasicDataSource">
        <property name="driverClassName" value="org.postgresql.Driver"/>
        <property name="url" value="jdbc:postgresql://127.0.0.1/myDatabase"/>
        <property name="username" value="root"/>
        <property name="password" value="abc123"/>
        <property name="maxIdle" value="5"/>
        <property name="maxActive" value="25"/>
        <property name="minIdle" value="5"/>
        <property name="initialSize" value="5"/>
    </bean>

For all options and details, refer the API for BasicDataSource. And, if you are a maven user, don't forget to include the dependency:

        <dependency>
            <groupId>commons-dbcp</groupId>
            <artifactId>commons-dbcp</artifactId>
            <version>1.2.2</version>
        </dependency>

 

Using Log4J in Spring: Effective Logging

Spring supports logging in its usual plug and use format. To use Apache's log4j in a Spring-Maven environments:

1. Add the log4j dependency to the pom
2. In web.xml of the application define spring listener for log4j and its config location
3. In the config location put in the appropriate properties file defining your loggers

Log4J Config

The log4j.properties at the above link is fully commented to help you(and me) understand how to use a properties file to split your logs at a finer level.

I have realized that in order to utilize the full power of log4j it is important to understand and use log4j.properties. This can help you to isolate logs from different part of of your application- something that can be really handy when you are trying to pin-point the source of trouble in a large system. The bigger and more distributed your system becomes, more important and useful logging appears.

As usual, I have focussed only on the practical aspects. For knowing more about log4j, see:

Log4J Website @ Apache

Log4J on Wiki

Log4J API 

Using JAXB in a Spring-Maven Environment for WebServices

In a Spring application you can consume a webservice using JaxRpcPortProxyFactorybean or XFireClientFactoryBean (in conjunction with XFire). However, there is another way which can prove to be extremely useful and convenient if you are using Spring and Maven: by using Spring and Maven in conjunction with JAXB. As usual, I will focus on using JAXB and not about JAXB. To learn more about JAXB see:

JAXB Reference at Sun

In this article we will cover

1. Setting up JAXB in Spring environment to generate stubs for the webservice

2. Using it in an external project or the same project.

As per the default maven build structure, you need to make a package called "wsdl" under src/main and place a copy of wsdl of the webservice you wish to use. Then configure your pom file with the right dependencies:

POM config for JAXB

Two things that you should notice in the pom besides JAXB dependencies are the build plugins maven-source-plugin and maven-jaxb2-plugin. They will generate stubs for your webservice in the "target" directory under "generated-sources" when you compile the project/ generate resources using maven. After that your webservice should be ready to used. Almost :D.

The generated source will contain stubs that correspond to exposed functions, responses and the various objects used. The name of the stubs will correspond to name in wsdl. In the same project you can use it by importing stubs from the package specified in com.saveenkumar.myApp.someWebService.types.  For an external project, you just need to import the project as a dependency.

Let us now see how to use these stubs. You will be able to use the webservice in your Spring app with the help of org.springframework.ws.client.core.WebServiceTemplate. You can see the bean config that you can use to inject it here:

WebServiceTemplate config as a spring bean

Note that the "contextPaths" property of the JAXB marshaller is same as the  property above. If you want to dig still deeper, have a look about using WebServiceTemplate  at:

WebServiceTemplate Reference

and

WebServiceTemplate API

It may be a good idea to hide the WebServiceTemplate behind a nice interface to abstract away the user from the generated JAXB classes.

The generated classes will always have a class called "ObjectFactory". There will also be objects corresponding to every operation, every response and every object used in these transactions. Let us say our webservice exposes the following operations:

List getAllStockInfo();

List getStocksByVolatilityRange(float low, float high);

StockInfo getStockInfo(String ticker);

May generate following objects:

ObjectFactory

ArrayOfStockInfo

StockInfo

GetAllStockInfo

GetAllStockInfoResponse

GetStockInfo

GetStockInfoResponse

GetStocksByVolatilityRange

GetStocksByVolatilityRangeResponse

Let us say we want to use GetStockInfo. The code would look something like:

Sample JAXB Usage

I would also recommend using SoapUI to test your webservices. 

@Resource and @Autowired

In September I wrote an article on using @Autowired for testing RMI services in Spring. Recently when trying to test a webservice consumer, I ran into trouble with @Autowired. Instead using @Resource (javax.annotation.Resource in Java 1.6) seemed to work fine. Digging I found this article in Spring forum:

Spring Forum Article on @Resource and @Autowired

which pointed to this in spring reference:

Spring Reference to Using @Autowired

Seems the two are pretty similar. Using @Qualifier (org.springframework.beans.factory.annotation.Qualifier) with @Autowired solved the problem and in the end I could use either. 

Retreiving Stored Objects Using Hibernate

This one is relatively simple. 

1. Use org.springframework.orm.hibernate3.support.HibernateDaoSupport to manage data (add or retrieve)
   
2. Refer to the official hibernate documentation to see how you can use Criteria to narrow your result set by clicking here
   
3. use getSession() from HibernateDaoSupport to get the hibernate session and fire away using what you learned in step 2

Persisting A List of Custom Objects Using Hibernate in a Spring Env.

The prospect of persisting an object using hibernate into a database and then reading it back did not seem challenging with good old hibernate taking care of most things. 

Piece of cake? Not quite actually as I discovered while trying to do it for a List of custom objects. Let us see what were the challenges and how I found the solutions. Let us assume I wish to persist an object that contains the current situation of all stocks trading in the market. Our simplistic object has an id and a list of stocks: 

StockInfoHolder POJO

The list of stocks is made of a custom object:

StockInfo POJO

And since we refuse to live without spring, we need some bean config:

Spring Bean Config

With spring so near how can we forget maven and the pom dependencies:

POM Dependencies

Phew! Sometimes I forget how much these XML config make our lives easier (?).  Now, had it been my own custom object, I would have used @Embedded. But what do I do with a java collection. I was tempted to mark it with @Lob and it compiled fine. But when I actually tried to persist it, it gave me one big, fat ClassCastException: java.util.ArrayList cannot be cast to java.sql.Blob. OK, so objects don't turn into byte arrays overnight and that attempt was dumb and desperate. 

Then what? Referring "Java Persistence with Hibernate" (Bauer and King,2006) and official hibernate docs helped my to make my classes look like this:

Hibernate Ready StockInfoHolder

Hibernate Ready StockInfo

Now this works like a charm: at least the part about starting your app, seeing your tables created perfectly and storing your objects at the right place with some class like:

HibernateDao 

In our next post we will see how we read this information back and use it if I face any difficulty with it as well!

ActiveMQ Message Consumer in Spring

In the last blog we saw how to configure an ActiveMQ broker to run in a Spring environment. In this blog we will see how to configure a message consumer. Again, I am not trying to explain how consumers work but just sharing code and config to make it work in Spring :p

Since we have the luxury of Spring , we will use a message listener container provided by the framework: SimpleMessageListenerContainer (org.springframework.jms.listener.SimpleMessageListenerContainer ). My needs were simple and non-transactional so this container suffices

The basic reason is the desire to be message driven i.e. I want my app to take some actions as and when it receives messages. The container bean definition should look like:

    <bean id="jmsContainer" class="org.springframework.jms.listener.SimpleMessageListenerContainer">

        <property name="autoStartup" value="true"/>

        <property name="connectionFactory" ref="myConnectionFactory"/>

        <property name="destination" ref="myDestination"/>

        <property name="messageListener" ref="myMessageListener"/>

        <property name="acceptMessagesWhileStopping" value="true"/>

    </bean>

This config makes the container start when the bean gets loaded and makes sure no messages are lost even if it is down. Further we need to specify the connection factory to use to connect to broker, the destination at broker from which we wish to hear and the message listener that ultimately handles the message. The config for these three will look like:

 <bean id="myDestination" class="org.apache.activemq.command.ActiveMQQueue">

        <constructor-arg value="myPackage.myQueue"/>

    </bean>

 <bean id="myConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">

        <property name="brokerURL" value="tcp://localhost:61636"/>

   </bean>

<bean id="myMessageListener" class="myPackage.MyMessageListener">       

    <property name="appName" value="My Application"/>

</bean>

Destination takes the name for destination in order to identify it at broker. the producer would refer it by the same name. JNDI can be used for more sophisticated look-ups which we may see some other time. Connection factory just needs url for a running broker. Message Listener is just our custom bean to handle messages. MyMessageListener would look like:

package myPackage;

import javax.jms.*;

public class MyMessageListener implements MessageListener {

    private String appName;

    public void setAppName(String appName){

        this.appName = appName;    

    }

    public void onMessage(Message message) {

        //do your stuff

    }

}

Finally, don't forget the POM dependencies included in last blog if you are using Maven. You should be good to go.

Running ActiveMQ Broker in Spring

ActiveMQ can run as an independent JMS server. This may be desirable if we want to run it independently of our spring application. However it is also possible that we may want to deploy a message broker within a spring environment. This may be simply because we need to do some unit testing or because our webapp is too small to break across several machines. Whatever be the reason. Let us make a note of basic steps to do it:

1. Put in your activemq.xml under the WEB-INF folder. Your ActiveMQ distribution(5.1.0 at time of this article) has this config file under the "conf" folder. We will not discuss configuring it here. Go here to read about configuring

2. The lib folder of the distribution has all possible jars that JMS may ever need in its lifetime. If you are not using Maven, you may need to copy the jars to your classpath. If you are using Maven, these dependencies should generally suffice for basic use.

        <dependency>
           <groupId>org.springframework</groupId>
           <artifactId>spring-jms</artifactId>
           <version>2.5.5</version>
       </dependency>

       <dependency>
           <groupId>org.apache.derby</groupId>
           <artifactId>derby</artifactId>
           <version>10.3.1.4</version>
       </dependency>

       <dependency>
           <groupId>org.apache.activemq</groupId>
           <artifactId>activemq-all</artifactId>
           <version>5.1.0</version>
       </dependency>

       <dependency>
           <groupId>org.apache.activemq</groupId>
           <artifactId>activemq-web</artifactId>
           <version>5.1.0</version>
       </dependency>

Go here if you wish to simply run ActiveMQ using Maven

3. Put this bean definition in your spring conf:

<bean id="broker" class="org.apache.activemq.xbean.BrokerFactoryBean">
   <property name="config" value="/WEB-INF/activemq.xml"/>
   <property name="start" value="true"/>
</bean>

You should be good to go. Bringing up your Spring application will start the broker at tcp://localhost:61636

Understanding JMS with a Spring Perspective

Making some notes from the official JMS tutorial.

Why Messaging?
Messaging enables distributed communication that is loosely coupled. Messaging is used for communication between software applications or software components.

What is NOT Messaging?
Messaging is different from RMI, RPC or email

What is JMS?
The Java Message Service is a Java API to help you with your messaging needs

When to use JMS/ Messaging?
Use JMS if

• you do not want to depend on any information about other components’ interfaces( so they are easily replaceable)
• you want your app to run whether or not all components are up and running simultaneously
• you want an app design that allows a component to send information to another and to continue to operate without receiving an immediate response
• you want a guaranteed delivery, not necessarily immediately
  

What is the support for JMS in J2EE?

• Message driven beans support JMS
• JMS messages can participate in distributed transactions

Where can I get an open-source implementation for JMS API?
ActiveMQ from Apache is a great open source implementation. You can see others at java-source.net


What is a Messaging Domain?
Messaging domain denotes the style of messaging. There are basically two types of messaging domains: Point-to-Point(PTP) and Publish/Subscribe(pub/sub)

How is PTP different for pub/sub?
PTP style of messaging has following features:
• Each message has only one consumer.
• A sender and a receiver of a message have no timing dependencies. The receiver can fetch the message whether or not it was running when the client sent the message.
• The receiver acknowledges the successful processing of a message.

Use PTP messaging when every message you send must be processed successfully
by one consumer.

pub/sub is characterized by:
• Each message may have multiple consumers
• Publishers and subscribers have a timing dependency. A client that subscribes to a topic can consume only messages published after the client has created a subscription, and the subscriber must continue to be active in order for it to consume messages.

Use pub/sub messaging when each message can be processed by zero, one, or many consumers.

What does JMS support out of these two?
JMS supports both. In fact it even provides something called durable subscriptions which allow you to combine flexibility and reliability of queues of PTP with the ability to allow clients to send messages to many recipients of pub/sub

Using JMS will the messages be consumed asynchronously or synchronously?
JMS supports both. However the biggest advantages of JMS arise out of asynchronous communication

What are the main parts of a JMS application?

• Administred Objects (connection factories, destinations)
• Connections
• Sessions
• Message producers
• Message consumers
• Messages

A connection factory is used to create a connection. A connection is used to create a session. A session can create a producer, consumer or a message. Producer send messages to a destination while consumers receive messages from the destination.

Does Spring support JMS?
Absolutely. You can read it here. If you are using ActiveMQ, you may want to see this too.

Why should I use spring to manage interactions with JMS?
For pretty much the same reason you would use spring to manage your database, cache etc. etc. : it makes your life easier. Seriously. Helps you cut down the "boiler-plate" code and gives you more specific exceptions besides the regular dependency injection benefits.

Setting up Quartz in a Spring-MySQL Environment

If you are using a persistent JobStore in Quartz, you will have to back your spring application with a DB. MySQL can be pretty convenient for local unit testing. Besides the regular spring DataSource config, you need a few more things here and there. I did not find any comprehensive "todo" checklist for MySQL online. So summing up what worked for me.

Using SchedularFactoryBean you can specify a MySQL DataSource and fine-tune it using quartz properties. You can see this in a config file I had published earlier:

XML Config

Besides this, you need to have the following dependencies for sure in your pom if you are using Maven:

POM dependencies

If you are not using maven, the corresponding jars should be in the classpath.

Finally, don't forget to run the SQL script to create tables in your database provided by quartz:

Creating DB Tables for Quartz

The Mysterious Ways of SchedulerFactoryBean

Using Spring framework and Quartz, I wanted to make some dynamic Jobs and triggers. After banging my head and some accidents I finally understood how to use it. The API docs say:

"For dynamic registration of jobs at runtime, use a bean reference to this SchedulerFactoryBean to get direct access to the Quartz Scheduler (org.quartz.Scheduler). This allows you to create new jobs and triggers, and also to control and monitor the entire Scheduler."

What the hell that means, I couldn't figure. Hunting for some examples on the web didn't help either. In one of my posts I have given a link to fine tune SchedulerFactoryBean for static jobs. Picking from there, let us assume you have a Stocks Alert Manager to which you wish to give a spring managed scheduler using your very own SchedulerFactoryBean . Let us assume your stockAlertsManager looks like this:

A Sample StocksAlertManager

Then your bean config should look something like this:

Bean Config to use SchedulerFactoryBean dynamically

If you have not noticed, the scheduler property of StockAlertsManager is of type org.quartz.impl.StdScheduler but in the bean config I have set it to the reference of our all-powerful SchedulerFactoryBean. Despite of the mismatch in types your spring application will not complain and initialize the scheduler property nicely. Even when SchedulerFactoryBean does not in any way extend StdScheduler or implement Scheduler . Wierd, counter-intuitive but works. Re-visiting the API doc:

"For dynamic registration of jobs at runtime, use a bean reference to this SchedulerFactoryBean to get direct access to the Quartz Scheduler (org.quartz.Scheduler). This allows you to create new jobs and triggers, and also to control and monitor the entire Scheduler."

Well, they literally meant it! Who would have thought?!

Using Autowiring for Testing RMI Services in Spring

Scehduling can be a common requirement in many applications. However testing such an application that used RMI with JUnit and JMock in a Spring-Maven environment turned out to be a little tricky for me. Thanks to the help of a colleague (thanks Mudassir!) and some head banging, I was able to find a way: Autowiring.

Generally my basic JUnit test cases have the following features:
1. The whole class annotated by @RunWith(JMock.class) - org.junit.runner.RunWith;
2. A set up method (the init method) annotated with @Before - org.junit.Before
3. The test cases annotated @Test - org.junit.Test
4. JUnit4Mockery used to mock relevant interfaces - org.jmock.integration.junit4.JUnit4Mockery
5. The usual expectatons and assertions
6. Spring adds punch with ability to mock request, response, sessions - org.springframework.mock.web.*

A Simple Test Case

Works fine for most things. Now picture this: you are developing application that needs to check stock prices every five minutes and send alerts to registered users if need be. Lets say there are three modules being developed for it: the user interface using which a user may register for an alert for stock price, the scheduler that keeps track of these alerts and the workflow engine that takes care of the alerts once fired. A classic MVC approach so far.

The controller accepts alerts from user interface and schedules Jobs that forward all information to the workflow. Let us assume these three modules are being developed by three different teams sitting in three corners of the world (ok, may be three corners of the office or just three different/independent machines/servers).

Now, when you are making the controller, you are essentially dependent on view for input and on the model for feedback (if any) for your input. We can provide access to our controller using any RMI strategy. For our example, we consider Spring's HttpInvoker. We intend to write a a test case to test the controller module.

Our controller has a remote service running in a spring environment. If it had been a simple servlet listening to ordinary post/get requests, writing a test case with MockHttpRequest would be a piece of cake. However when it is an RMI service, what mock up to use? An answer can be a test class looking something like this:

A Test Case For RMI Service


The answer lies in using SpringJUnit4ClassRunner and then auto-wiring the HttpInvokerService. ContextConfiguration points to the locations for the config xml. In the current case you should put it in "myPackage. If you are using Maven, the resources folder would be the right place to put it. The config file may look like:

Autowiring Config


If you are using Maven, don't forget to add the following dependencies:

Maven Dependencies

A few tweaks may be needed to suit your case but this should give you a general idea about using autowiring for your test cases in JUnit, JMock, Spring, Maven environment.

Quartz and Spring

For scheduling purposes one can use Quartz with Spring. The basic usage can be learnt by going through the quartz tutorial and spring documentation on scheduling .

However when it came to using advanced usage like configuring job stores, I had a little difficulty finding stuff. A particular entry in the spring forum was really useful. These three resources were able to take care of my reasonably complex needs for scheduling. Hope they are of some use to you too.

The Beginning

There are a million people writing on Java. Why write more? Mainly to chronicle my learnings for personal and public use.

Java is vast. And when I say Java, I include J2EE, designing applications using Java and following things related to it. So where to begin? I will be mainly writing on multi-threading, spring, hibernate, junit, jmock and design patterns. It is not really meant to be a tutorial (not yet). Just sharing my learning and chronicling the same over time.

I will begin with spring.

The best place to start learning is the spring website at: http://www.springframework.org/documentation . I absolutely adore this light-weight, non-intrusive, well-designed framework. The reasons I will leave you to discover for converting you to a spring believer is not my intention. The framework consists of several modules which can be used independently. Again, I am not listing them but will mention as I write about them. This should not affect any article as various spring modules can be used independently.

I also refer Spring in Action by Craig Wells with Ryan Breidenbach. Lets see where we end up!