HSQL on Tomcat

•January 28, 2009 • Leave a Comment

Ever wanted to know how to make an instance of HSQL start up and stop with Tomcat? Look no further…

It gives you a free way to have a database server and app server integrated together.

I had a requirement for this a while back and I figured that I’d better share the code:

package com.company.cso.hsql;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

import org.hsqldb.Server;

public class HSQLDBUtility {

private static String PORT = "8675";

public static void start() {
final String database = "c:\\path-to-save\\database-files";
final String port = PORT;
if (database != null) {
Thread server = new Thread() {
public void run() {
System.out.println("Starting HSQLDB");
String[] args = {
"-database", database,
"-port", port,
"-no_system_exit", "true" };

public static void stop() {
try {
System.out.println("Stopping HSQLDB");
final Connection con = DriverManager.getConnection("jdbc:hsqldb://localhost:"+ PORT);
} catch (SQLException e) {
System.out.println("ERROR shutting down HSQLDB");


package com.company.cso.hsql;

import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.LifecycleListener;

public class TomcatHSQLDBPlugin implements LifecycleListener {
   public void lifecycleEvent(LifecycleEvent event) {
      if (event.getType().equals(Lifecycle.START_EVENT)) {
      else if (event.getType().equals(Lifecycle.STOP_EVENT)) {
      else {
         System.out.println(getClass().getName()+": Not handling LifecycleEvent: "+event.getType());


The first class takes care of the setup of the db server. The second class implements the LifecycleListener interface that plugs into the tomcat server.xml.


Economic Downturn

•January 19, 2009 • Leave a Comment

Time Magazine, 1974With all the news lately about the “economic downturn”, etc… I had been quick to point out to my colleagues and friends that I haven’t really been affected by anything directly (indirectly I have — prices, deals, etc…). I don’t work on wall street, or consider the financial sector a big cog in the wheel of the CMS business. Conversely, I think with all the cuts that business make during times like these are usually in more traditional ‘expensive’ media such as print or tv. Electronic marketing has become essentially the genre in which marketers consider that they can get the most bang for the buck as it would seem. CMS vendors typically play right into this thinking if they have strong tools for empowering their users to create rich, engaging content. It would seem that I should have no fears during this recession. But wait…

Last week I had my first taste of bad news. I found out that a small group of friends had been terminated due to the competitive nature of the economic climate. These were smart, intelligent people which made it finally hit home: nobody is completely immune to this problem. The economy has forced even the most well positioned companies to make tough decisions.

I suppose that there was always a part of me that knew that eventually I was going to encounter some bad news, but fortunately it didn’t directly involve me in any way. It also made me conscious of the fact that even in such trying times for people, there are always silver linings.

JCR API – java content repository (JSR 170)

•January 5, 2009 • Leave a Comment

I’ve been following, with an optimistic interest, in the maturity of the JCR API and its various implementations. The expert group lists the usual suspects in the xCM space (with some interesting ones present and some notable ones missing). A workable api (a bunch of Java interfaces) was the result and then we waited for the flood of implementation to surface.

Outside of the usual apache (jackrabbit) implementation, we waited… waited some more…

In the proptrietary ECM space, I’m not sure there is a delivered option for interfacing with the JCR API. Out of the original listing of SMEs, only a handful have created their own JCR connector/implementation — and most are concerned with the open source route. To me, it seems like there was alot of interest in creating this standard, but no financial or business requirement to actually implement it into a product. I can imagine that there a many implementations of jackrabbit (and exo, etc.) built into applications that will never see the light of day.

This leads me to think that federation might be a better approach to creating a standard interface. With the REST paradigm becoming popular, it might be time to look at projects such as jboss’ DNA. This type of repository federation is still in its infancy, but it could provide the type of compatibility we’re looking for without having the ECM vendor alter the products themselves.