Gurkan Nisanci’s Weblog

We use CruiseControl at work for managing the build operations. Whenever a build fails, an email is sent to the project owners by CruiseControl for the notification of problem. Since this email is sent to the relevant parties, others, monitoring CruiseControl for their projects is mostly unaware of these build problems.

While I was surfing, I come up with an extension to my Firefox browser, BuildMonitor, which stays on your browser’s status bar and gives information about the overall status of CruiseControl’s continuous build process results. My browser is mostly open and with BuildMonitor I have the updated info about all CruiseControl builds. The only pitfall is it only works on Gecko-based browsers and doesn’t support IE.

At work, I am currently building a small framework which behaves like a bridge that carries the requests and their responses between the client and our system. The client sends his requests through a web service call. This request is sent to our bridge framework named, Response Handler,  over RMI. Response Handler takes this request and puts into a JMS queue for processing by the application listening this queue. After the request is processed, the response is put into another JMS queue which Response Handler is polling periodically. Response Handler gets the response from this queue and sends back to web service. The following diagram shows the flow of work:

In order to test Response Handler, I wrote a tiny client which sends requests over RMI similar to the ones that the web service will send in the real environment and also a transaction schedular simulator, that fetches the requests from JMS queue and puts their response back. The web service-Response Handler integration over RMI can be done in the same VM with out any problem. Also since the Weblogic was always up at work, there also no problem with JMS integration. However, if I go to home, my tests for Response Handler was not running since, it requires a running Weblogic server. I didn’t want to be bound to Weblogic, so I installed OpenJMS to my laptop. Everything was fine and my tests were running without any problem on my laptop. When I deployed my application to the CruiseControl, tests were getting failed. There were no OpenJMS instance on Unix ! So I started to look for an alternative. I checked out Mockrunner. I need some integration tests which sends a requests to a JMS queue and listens a queue for a response. I discovered that Mockrunner does not simulate that behavior and directly returns something when it has to wait for a message in a queue. So I looked for an alternative and come up with Somnifugi. It works inside a single JVM and JMS Messages are send between Threads. So, in order to make my tests pass on any machine, all I did was to run each component(web service client, Response Handler, Transaction Scheduler, JMS-Somnifugi) in a seperate thread in the same JVM. I really liked it so my dependcy to Weblogic JMS server is broken and my tests can now work on any machine without requiring a JMS server for run.

I like in memory server solutions, like HSQLDB. Whenever you have a tight coupling to a heavy resource, they come up for rescue to make your tests run without any problem. The only lacking point I would like to state about Somnifugi is its scarce documentation. I come up accidentally how to use it from my application while checking Javadocs. It would be better if the author prepare a  seperate how-to doc for it. 

I see similar code repetitions at work in projects. One of the things which I come up frequently nowadays is while using log4j logger:

void insertEmployee(Employee employee) {
// code …

if (logger.isDebugEnabled()) {
logger.debug(“Some log message”);
}

// code …

}

These lines are written to many places in code which makes the reading of it harder for the outcomer. Extract Method refactoring fits very good for such cases. The above lines can be moved to a method:

void writeLog(String logMessage) {
if (logger.isDebugEnabled()) {
logger.debug(logMessage);
}
}

and whenever a log meesage is needed, our new method can be called which will help the readers understand the code more easily and also keep it clean.

void insertEmployee(Employee employee) {
// code …

writeLog(“Some log message”);

// code …

}

In future if a need rise to change the log level, it can be easily done by updating our new method instead of searching and replacing every piece of code doing a logging.