Tuesday, October 24, 2006

PuTTY with Cygwin

PuTTYCyg allows you to use PuTTY as your Cygwin console instead of the regular old shoddy windows console.

It's really great, but I was kind of confused about how to set it up at first. Apparently, you have to make a new session with hostname "-" (without the quotes) and choose "cygwin" as the protocol, then you save it as yourusername@localhost. Load that session and enjoy.

Sunday, October 22, 2006

Configuring EhCache with Spring

There is a tricky point to configuring EhCache with Spring, which I discovered earlier last week. Usually you configure EhCache with by overriding the default ehcache.xml, defining the disk store location, cache name, and various other cache properties. However, if you use Spring's EhCacheFactoryBean and/or EhCacheManagerFactoryBean to build your cache, you will be in for a surprise.

If you use the EhCacheManagerFactoryBean and specify an ehcache.xml file, the only property that will be used is the diskStorePath property; the rest of the cache properties specified in your xml configuration file will be ignored. You must use setter injection to set these properties via a EhCacheFactoryBean . However, there is no way to set the diskStorePath property using setter injection. You can try, but the property you inject will not be used.

<bean id="myCacheBean"
class="org.springframework.cache.ehcache.EhCacheFactoryBean">
<!-- This property is totally ignored! -->
<property name="diskStorePath"
value="java.io.tmpdir/myCacheName"/>
</bean>


This is because the CacheManager will automatically override any diskStorePath you have set when you add a new cache to the manager:

// Code snippet from Cache.java in the EhCache project:
/**
* @param diskStorePath this parameter is ignored. CacheManager
* sets it using setter injection.
*/


The solution? Unfortunately, I don't know of any except to use both an ehcache.xml configuration file and setter injection in spring to override the defaults.

Friday, October 20, 2006

JDBC PreparedStatement Logging for Java

The JDBC PreparedStatement interface doesn't provide a reliable way to log your SQL queries. While you can always log the statement that's being prepared, more often than not, you need more information than INSERT INTO SOMETABLE VALUES(?, ?, ?, ?, ?). You need to be able to see how data is being sent to the database, and PreparedStatement, on its own, gives you no reliable way to do that.

An article by IBM shows you have to implement a PreparedStatement interface that wraps around a real statement so that you can capture parameters for logging. However, when I tried the example code, it didn't compile under Java 5.0 (presumably because of the new features for PreparedStatement - though better query logging was mysteriously missing as a feature).

Example

From IBM's article:

String sql = "select foo, bar from foobar where foo < ? "
+ "and bar = ?";
long fooValue = 99;
String barValue = "christmas";

Connection conn = dataSource.getConnection();
PreparedStatement pstmt;

if(logEnabled) // use a switch to toggle logging.
pstmt = new LoggableStatement(conn,sql);
else
pstmt = conn.prepareStatement(sql);

pstmt.setLong(1,fooValue);
pstmt.setString(2,barValue);

if(logEnabled)
System.out.println("Executing query: "+
((LoggableStatement)pstmt).getQueryString());

ResultSet rs = pstmt.executeQuery();


Update

The link to loggable statement is gone, I know. Wait, why are you still using straight JDBC?