Categories
Programming languages RS Library

The Importance of Unit Tests

I am not a close friend of unit tests. In fact, as a programmer I regard them as annoying. However, when I started to write unit tests for my RS Library classes, I discovered many bugs that I didn’t see before. Those bugs never occurred in production yet mainly because the code was used in a slightly different way and bypassed the buggy parts. Some of the bugs are very stupid so that I wondered how they could ever get into a release.

The experience shows me now that it is important to write unit tests for all classes and their non-trivial methods. This is the only way to write better code. The self-confidence that I have in my own code is not enough. So there will be a lot of unit testing effort within the next weeks. And the next RS library code is most-likely the best-tested code ever.

Nobody is perfect. 😉

Categories
Java RS Library

RS Library 1.2.1 released

A major milestone of RS Library version 1.2 is out. I already discovered a critical bug in 1.2.0. That’s why the latest version is 1.2.1 now. The most important changes are:

However, I already discovered a minor bug in V1.2.1: RSLIBS-37 describes an incorrect behaviour of SoftMapCache.containsValue(Object) and WeakMapCache.containsValue(Object) methods which will be fixed in next version. V1.2.1 does not use this methods anywhere, so you would need to work-around this function in case you require it.

I also added more documentation now so you will be able to understand and use the libraries. It can be found either through Javadocs or the appropriate module homepages:

The Maven coordinates are:

   <dependency>
      <groupid>eu.ralph-schuster</groupid>
      <artifactid>baselib</artifactid>
      <version>1.2.1</version>
   </dependency>
 
   <dependency>
      <groupid>eu.ralph-schuster</groupid>
      <artifactid>data</artifactid>
      <version>1.2.1</version>
   </dependency>
 
   <dependency>
      <groupid>eu.ralph-schuster</groupid>
      <artifactid>data-file</artifactid>
      <version>1.2.1</version>
   </dependency>
 
   <dependency>
      <groupid>eu.ralph-schuster</groupid>
      <artifactid>data-hibernate</artifactid>
      <version>1.2.1</version>
   </dependency>
 
   <dependency>
      <groupid>eu.ralph-schuster</groupid>
      <artifactid>templating</artifactid>
      <version>1.2.1</version>
   </dependency>
Categories
Java

Eclipse/E4: Problem with Key Bindings

I recently updated one of my E4 applications from Juno to Kepler (V4.3) release. Beside a few things (e.g. adding the HandlerProcessingAddOn to e4xmi configuration) I suddenly lost my customized key bindings. Unfortunately, there was not even a slight hint anywhere in the net why this happened. Most of the web sites were just referring to the afore mentioned add-on. But this didn’t bring back the missing key bindings.

So the only solution was to debug the bootstrap of RCP/E4 and find out where the key bindings disappeared. I noticed very early that my Binding Table was read but didn’t contain the correct key bindings. Although, an earlier breakpoint revealed that they have been read correctly. However, somehow they were removed and replaced by other ones.

Debugging in Eclipse/E4 is quite exhausting escpecially when you try to trace a problem in the bootstrap mechanism. But finally I saw an extension point (a “processor” to be precise) as root cause. This extension just threw away my key bindings. It eventually turned out to be the org.eclipse.ui.workbench plugin which I required in my application. This plugin defines a BindingToModelProcessor that simply throws away all key bindings within the org.eclipse.ui.contexts.dialogAndWindow Binding Context except those tagged with type:user.

That’s the solution. Simple as that. I added the tag to all my key bindings and they were not removed and working again. So be aware when adding org.eclipse.ui.workbench as a dependency plugin to your E4 application. 😉

Categories
Java

Hibernate 4 with JTA Transactions

The following problem occurred when I was migrating from Hibernate 3 to Hibernate 4.2.3. Scrollable result sets were suddenly throwing exceptions:

org.hibernate.exception.GenericJDBCException: could not advance using next()
	at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:54)
	at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:125)
	at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:110)
	at org.hibernate.internal.ScrollableResultsImpl.next(ScrollableResultsImpl.java:121)
...
Caused by: java.sql.SQLException: Operation not allowed after ResultSet closed
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1078)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:989)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:975)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:920)
	at com.mysql.jdbc.ResultSetImpl.checkClosed(ResultSetImpl.java:804)
	at com.mysql.jdbc.ResultSetImpl.next(ResultSetImpl.java:6986)
	at org.hibernate.internal.ScrollableResultsImpl.next(ScrollableResultsImpl.java:116)

It turned out after 3 hours of debugging and research that Hibernate’s 4 JTA implementation relies on having a transaction started not via JTA User Transaction but through Hibernate’s own Session object. The correct configuration in such cases is simply to use CMTTransactionFactory as transaction factory class:

1
2
3
4
5
6
7
8
9
10
11
12
13
<hibernate-configuration>
   <session-factory>
      <!-- How to find the Transaction -->
      <property name="hibernate.transaction.factory_class">org.hibernate.engine.transaction.internal.jta.CMTTransactionFactory</property>
 
      <!-- How to produce transaction -->
      <property name="hibernate.transaction.jta.platform">org.hibernate.service.jta.platform.internal.JOTMJtaPlatform</property>
 
      <!-- Session context with JTA -->
      <property name="current_session_context_class">jta</property>
      ...
   </session-factory>
</hibernate-configuration>

As explanation: The error is primarily caused by a bug in JTA implementation within Hibernate (it does not synchronize Hibernate’s with JTA’s transaction object). It occurs mainly when you use the Entity Manager. In above’s exception, a second retrieval was executed within object iteration which caused Hibernate to think that there is no active transaction and hence, close any previous statements. That’s why the Scrollable Result loses its session.

The solution was published first by Koen Serneels. Many thanks!