In this article I will look at the various features which are required for a good exception handling framework and how Aspect oriented programming (AOP) will be used in the design of an Exception handling framework.
Lets Look at the key feature of an Exception handling framework
- Propagating business and technical exceptions from the server side to the client side modules in a consistent manner.
- Returning error codes into human readable error messages.
- Handling checked and unchecked exceptions in a unified way.
- Throwing checked and unchecked exceptions and creating new instances initialized with an error code picked from a predefined set.
- Implementing new exception classes in a predefined inheritance hierarchy.
Learn more about exceptions here and find out the difference between Checked and unchecked exceptions here.
By large, Exceptions are classified in two categories
(more…)
Written by Ravi Nallakukkala on November 29th, 2007 with no comments.
Read more articles on Design.
Sometimes the common problems seems to be we don’t remember the API, one such scenario I recently faced was how to convert a Array to a collection? Following seems to decent ways 
// Fixed-size list
List list = Arrays.asList(array);
// Growable list
list = new LinkedList(Arrays.asList(array));
// Duplicate elements are discarded
Set set = new HashSet(Arrays.asList(array));
Written by Ravi Nallakukkala on November 29th, 2007 with no comments.
Read more articles on Java/ J2EE.
The Spring Framework provides a good support for the integration tests for enterprise software applications and these support classes are packaged in spring-mock.jar and all these classes are JUnit test classes. org.springframework.test package provides valuable JUnit TestCase superclasses for integration testing using a Spring container and this approach is completely independent of any web/ application server.
Spring out-of-box provide the following functionality:
- Transaction management though spring container.
- Dependency Injection feature.
- Spring Ioc Container caching between execution.
On Surface, Spring Test cases can be classified into
- JUnit with Dependency Injection.
- Junit with Dependency Injection and Transactional Control.
Spring based JUnit with Dependency Injection
For JUnit Classes which need to use Dependency injection feature of spring will be required to inherit the class ‘AbstractDependencyInjectionSpringContextTests‘ and the subclass need to implement the superclass’s abstract method ‘protected abstract String[] getConfigLocations();’ the implementation of this method need to return the spring configuration XML files which are required to participate in the execution of the test case.
E.g,
public final class ExampleDaoTests extends AbstractDependencyInjectionSpringContextTests {
// this reference will be automatically injected through spring
private ExampleDao exampleDao;
// a setter method to enable DI for the Dao instance variable
public void setExampleDao(ExampleDao exampleDao) {
this.exampleDao = exampleDao;
}
public void testExample() throws Exception {
BusinessObject bo = this.exampleDao.loadBo(new Long(10));
assertNotNull(title);
}
// specifies the Spring configuration to load for this test.
protected String[] getConfigLocations() {
return new String[] { “classpath:com/foo/daos.xml†};
}
}
<< Spring Configuration file >>
<?xml version=â€1.0? encoding=â€UTF-8??>
<!DOCTYPE beans PUBLIC “-//SPRING//DTD BEAN 2.0//ENâ€
“http://www.springframework.org/dtd/http://www.springframework.org/dtd/spring-beans-2.0.dtdâ€>
<beans>
<!– this bean will be injected into the ExampleDaoTests class –>
<bean id=â€exampleDao†class=â€com.foo.dao.hibernate.ExampleDaoâ€>
<property name=â€sessionFactory†ref=â€sessionFactoryâ€/>
</bean>
<bean id=â€sessionFactory†class=â€org.springframework.orm.hibernate3.LocalSessionFactoryBeanâ€>
<!– dependencies elided for clarity –>
</bean>
</beans>
Spring based JUnit with Transaction Control/ Integration Test
One common problem in integration test is to access a database and still maintain the state of the persistence store. When using a database, changes to the database state may effect the future tests and CURD operations can’t be verified outside a transaction.
The org.springframework.test.AbstractTransactionalSpringContextTests superclass (and subclasses) exist to meet this requirement. By default, this class create and rollback a transaction for each test. From a developer/ development point of view, You simply write code that assumes the existence of a transaction.
It has to be noted that, this class extends AbstractDependencyInjectionSpringContextTests so spring dependency injection is made available for all the subclasses extending AbstractTransactionalSpringContextTests
Spring based JUnit also provides an option to commit a transaction (unusual, but occasionally useful when you want a particular test to populate the database) - you can invoke the setComplete() method inherited from AbstractTransactionalSpringContextTests. This will force the transaction to commit instead of roll back.
There is also convenient ability to end a transaction before the test case ends, through calling the endTransaction() method. This will roll back the transaction by default, and commit it only if setComplete() had previously been called. This functionality is useful if you want to test the behavior of ‘disconnected’ data objects, such as Hibernate-mapped objects that will be used in a web or remoting tier outside a transaction. Often, lazy loading errors are discovered only through UI testing; if you call endTransaction() you can ensure correct operation of the UI through your JUnit test suite.
E.g,
//as this test class extends ‘AbstractTransactionalSpringContextTests’ so all the
//test methods will be bound with a transaction.
public final class ExampleDaoTests extends AbstractTransactionalSpringContextTests {
// this reference will be automatically injected through spring
private ExampleDao exampleDao;
// a setter method to enable DI for the Dao instance variable
public void setExampleDao(ExampleDao exampleDao) {
this.exampleDao = exampleDao;
}
public void testExample() throws Exception {
BusinessObject bo = createBo(); // create the Business Objects
exampleDao.create(bo); // Business Object will be created
//now retrieve the object which was created in the database.
BusinessObject returnedObject = exampleDao.findById(bo.getId());
assertEquals(bo.getId(), returnedObject.getId());
//after the execution of the test method, data which was inse
}
// specifies the Spring configuration to load for this test.
protected String[] getConfigLocations() {
return new String[] { “classpath:com/foo/daos.xml†};
}
}
<< Spring Configuration file >>
<?xml version=â€1.0? encoding=â€UTF-8??>
<!DOCTYPE beans PUBLIC “-//SPRING//DTD BEAN 2.0//ENâ€
“http://www.springframework.org/dtd/http://www.springframework.org/dtd/spring-beans-2.0.dtdâ€>
<beans>
<!– this bean will be injected into the ExampleDaoTests class –>
<bean id=â€exampleDao†class=â€com.foo.dao.hibernate.ExampleDaoâ€>
<property name=â€sessionFactory†ref=â€sessionFactoryâ€/>
</bean>
<bean id=â€sessionFactory†class=â€org.springframework.orm.hibernate3.LocalSessionFactoryBeanâ€>
<!– dependencies elided for clarity –>
</bean>
</beans>
Written by Ravi Nallakukkala on November 29th, 2007 with no comments.
Read more articles on Design and Spring.