iBatis Unit Test with Lazy Loading [Archive]

telcontar4

Aug 18th, 2004, 02:26 PM

I have seen a lot of good discussion around unit testing Hibernate-based DAOs when using lazy loading (for example: http://sourceforge.net/forum/forum.php?thread_id=1030706&forum_id=250340). I wondered if anyone had encountered the same issues when using iBatis and has a similar solution?

DETAILS
----------

Spring 1.0.2, iBatis 2.0.5

I have a class that extends Spring's SqlMapClientDaoSupport and has the following method:

public Order loadOrder(String orderId) throws DataAccessException {
return (Order) getSqlMapClientTemplate().queryForObject("loadOrder", orderId);
}

The Order class includes a java.util.List property for line items. The relevant extracts from the SQL Map file are as follows:

<sqlMap>
<resultMap id="orderMap" class="domain.Order">
<result property="id" column="row_id"/>
...lots of other scalar fields...
<result property="lineItems" column="row_id" select="findLineItemsByOrderId"/>
</resultMap>
<resultMap id="orderItemMap" class="domain.OrderLineItem">
<result property="id" column="row_id"/>
...lots of other scalar fields...
</resultMap>

<select id="loadOrder" resultMap="orderMap">
SELECT
row_id,
...other columns...
FROM
order
WHERE
row_id = #value#
</select>
<select id="findLineItemsByOrderId" parameterClass="java.lang.String"
resultMap="orderItemMap">
SELECT
row_id,
...other columns...
FROM
order_item
WHERE
order_id = #value#
</select>
</sqlMap>

Now, this all works fine when I run the web application: I see all Order and Line Item fields. In my JUnit class, I have the following code (DbUnit stuff omitted):

protected DriverManagerDataSource m_dataSource; //Actually initialized in superclass
protected SqlMapClient m_sqlMapClient; // Actually initialized in superclass
private OrderDao m_dao;

protected void setUp() throws Exception {
m_dataSource = new SingleConnectionDataSource();
m_dataSource.setDriverClassName("org.hsqldb.jdbcDriver");
m_dataSource.setUrl("jdbc:hsqldb:db-location");
m_dataSource.setUsername("sa");
m_dataSource.setPassword("");

m_sqlMapClient = SqlMapClientBuilder.buildSqlMapClient(...);

m_dao = new SqlMapOrderDao();
m_dao.setDataSource(m_dataSource);
m_dao.setSqlMapClient(m_sqlMapClient);
}

public void testLoadOrder() {
Order order = m_dao.loadOrder(orderId);
System.out.println(order); // Exception is thrown here!
...assertions omitted for brevity...
}

When I first attempt to read the value of the line items List property, I get the following stack trace:

java.lang.NullPointerException
at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelega te.endTransaction(SqlMapExecutorDelegate.java:465)
at com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.en dTransaction(SqlMapSessionImpl.java:134)
at com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.end Transaction(SqlMapClientImpl.java:107)
at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelega te.autoEndTransaction(SqlMapExecutorDelegate.java: 515)
at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelega te.queryForList(SqlMapExecutorDelegate.java:381)
at com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelega te.queryForList(SqlMapExecutorDelegate.java:359)
at com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.qu eryForList(SqlMapSessionImpl.java:90)
at com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.que ryForList(SqlMapClientImpl.java:65)
at com.ibatis.sqlmap.engine.mapping.result.loader.Res ultLoader.getResult(ResultLoader.java:65)
at com.ibatis.sqlmap.engine.mapping.result.loader.Laz yResultLoader.loadObject(LazyResultLoader.java:94)
at com.ibatis.sqlmap.engine.mapping.result.loader.Laz yResultLoader.invoke(LazyResultLoader.java:77)
at $Proxy0.hashCode(Unknown Source)
at java.util.HashMap.hash(HashMap.java:261)
at java.util.HashMap.containsKey(HashMap.java:339)
at java.util.HashSet.contains(HashSet.java:180)
at org.apache.commons.lang.builder.ReflectionToString Builder.isRegistered(ReflectionToStringBuilder.jav a:141)
at org.apache.commons.lang.builder.ToStringStyle.appe ndInternal(ToStringStyle.java:340)
at org.apache.commons.lang.builder.ToStringStyle.appe nd(ToStringStyle.java:314)
at org.apache.commons.lang.builder.ToStringBuilder.ap pend(ToStringBuilder.java:872)
at domain.Order.toString(Order.java:361)
...etc. etc....

If I disable lazy-loading, the unit test runs just fine.

Colin Sampaleanu

Aug 18th, 2004, 03:35 PM

In my DAO tests, I usually do programmatic transactions (as opposed to the declarative transactions used for the normal app itself), using TransactionTemplate. This is very simple, and allows all the operations to be grouped together, and have lazy loading work.

Regards,

telcontar4

Aug 18th, 2004, 04:24 PM

Colin,

Are you saying that you use TransactionTemplate in your unit test class to wrap the DAO calls? Or that you use it in your DAO methods (even the load*, find* ones) and inject the TransactionManager programatically in your unit tests (as opposed to declaratively in the as-deployed app)? I have tried both approaches, without any success. Could you please provide a snippet of sample code to illustrate your approach?

Colin Sampaleanu

Aug 18th, 2004, 04:37 PM

In the test case itself, I just wrap the entire sequence of related calls to the DAO in a transaction template.

Here's a sample class. Note that it's using a junit extension helper library so it only has to load the app contexts for the test once per testsuite, not on every test method. I would normally use one testcase like this for testing all daos for an entire module, but anything that works for you is ok.

/**
* Test which checks that basic Mapper persistence is working.
*
* Note that this test should not be considered the right way to use mapper objects in
* a real app, since this test is concerned with persistence only. The same mapper
* classes in real life would normally be used by service objects wrapped with
* declarative transactions.
*
* @author Colin Sampaleanu
*/
public class BasicMappedPersistenceTest extends TestCase {

public static final String CONTEXT = ClassUtils.classPackageAsResourcePath(BasicMappedP ersistenceTest.class)
+ "/BasicMappedPersistenceTestContext.xml";

// ids for storing contexts as quasi singletons between individual tests. Hibernate SessionFactory
// setup would kill us otherwise
public static final String APP_CONTEXT_ID = "BasicMappedPersistenceTest.appContext";
public static final String APP_CONTEXT2_ID = "BasicMappedPersistenceTest.appContext2";

// --- attributes
// per-TestSuite specific vars, via ResourceManager!
ApplicationContext appContext;

ApplicationContext appContext2;

// normal vars
// --- methods
// --- attributes
public static Test suite() {
return new TestSetup(new TestSuite(BasicMappedPersistenceTest.class)) {

protected void setUp() throws Exception {
try {
ApplicationContext appContext;
appContext = new ClassPathXmlApplicationContext(new String[] {CONTEXT});
ResourceManager.addResource(APP_CONTEXT_ID, appContext);
ApplicationContext appContext2;
appContext2 = new ClassPathXmlApplicationContext(new String[] {CONTEXT});
ResourceManager.addResource(APP_CONTEXT2_ID, appContext2);
}
catch (RuntimeException t) {
// just for debugging since Eclipse swallows these
throw t;
}
catch (Error e) {
// just for debugging since Eclipse swallows these
throw e;
}
}

protected void tearDown() throws Exception {
ResourceManager.removeResource(APP_CONTEXT_ID);
}
};
}

/*
* (non-Javadoc)
*
* @see junit.framework.TestCase#setUp()
*/
protected void setUp() throws Exception {
appContext = (ApplicationContext) ResourceManager.getResource(APP_CONTEXT_ID);
appContext2 = (ApplicationContext) ResourceManager.getResource(APP_CONTEXT2_ID);
}

/**
* A basic test to ensure object creation, saving, and cascading is working
* Note that this test doesn't use transactions in a typical fashion, that is
* normally, you would probably only use one transaction per method, but here
* we actually want to force out all our changes to the db so that the db
* would give an exception on any constraint violations. Note that short of
* getting a whole new sesion though, the subsequent read-back is still going
* to give us data from the session cache.
*
* @throws Exception
*/
public void testBasicCreationSaveAndCascade() throws Exception {

final Mapper mapper = (Mapper) appContext.getBean("root-mapper");
PlatformTransactionManager tm = (PlatformTransactionManager) appContext
.getBean("myTransactionManager");

TransactionTemplate transactionTemplate = new TransactionTemplate(tm);

final User1[] savedUser1 = {null};
final HashMap objMap = new HashMap();

transactionTemplate.execute(new TransactionCallback() {

public Object doInTransaction(TransactionStatus status) {

User1 user1 = new User1(null, "user1", "pass1");
mapper.save(user1);
savedUser1[0] = user1;

return null;
}
});

// now ensure the objects can be read back ok
final Mapper mapper2 = (Mapper) appContext2.getBean("root-mapper");
final MapperFactory mapperFactory2 = mapper2.getMapperFactory();
PlatformTransactionManager tm2 = (PlatformTransactionManager) appContext2
.getBean("myTransactionManager");

TransactionTemplate transactionTemplate2 = new TransactionTemplate(tm2);

transactionTemplate2.execute(new TransactionCallback() {

public Object doInTransaction(TransactionStatus status) {

// User1
User1 user1 = (User1) mapper2.load(User1.class, savedUser1[0].getId());
assertNotNull(user1);

return null;
}
});
}
}

Regards,

telcontar4

Aug 19th, 2004, 10:22 AM

The basic difference between Colin's unit tests and mine are that his use a Spring application context to access the DAO and TransactionManager objects, whereas (in this current project) I use standalone POJOs. Since I haven't got to the transactional part of my app yet, I have not yet defined any TransactionManager beans. Evidently, when using Spring's wrapper for the iBatis SqlMapClient class, the absence of an explicit TransactionManager in the configuration is handled gracefully and lazy loading works as expected when running the web app. However, testing the DAO in isolation is a problem.

The solution was simply to create a test version of the sql-map-config.xml file for my DAO unit tests and add the appropriate <transactionManager> element. Now I have to decide whether or not to switch back to using Spring application contexts in my unit tests...

Thanks, Colin, for your help.