Steven Haines

This week on InformIT.com I start a new series that demonstrates how to integrate Hypersonic DB into your client applications.

Where this started was that I have been using an online project management application called Nozbe as an implementation of David Allen’s Getting Things Done. I have my personal projects and tasks there, but I wanted to add my business projects. Unfortunately I am currently working on a project under several NDAs, so I do not feel comfortable storing information about this project in Nozbe’s cloud. My idea, therefore, was to build a portable client application that lives on my external hard drive (so that it can run at work, at home, or where ever) that does the same thing. The challenge I faced was that as the number of projects grows, the performance will degrade and the required memory will increase if I add all of the features that I want. As soon as I designed XML documents to host each project and then built indexes to be able to search them I realized that I needed a database. But in order to stay portable I do not want to install a database.

The answer: Hypersonic Database (HSQLDB). The neat thing about HSQLDB is that it can run in-memory, populated by a script, and created when you create a JDBC connection to it. In other words, you can start it when your application starts and shut it down when your application shuts down. I could not find any “great” articles that described how to do this so I started a series on InformIT.com. In the this, the first article, I describe the problem and help my readers setup an HSQLDB environment using Maven. Next week I’ll build out the framework for a simple application that uses HSQLDB in this manner. The follow up to this tries to bring more formality to integrating database access into client applications by (1) defining a service layer using Spring and a proper Object-Relation Mapping (ORM) solution using Hibernate. I think that while we focus on separation of concerns and formality in web applications, when it comes to client applications we fall back to that cowboy mentality and throw proper design to the wind. My hope is that this third article brings home that we should properly develop client applications if we ever want any maintainability. Depending on how far I get building my Getting Things Done (GTD), or in my case “Geeking Things Done”, I’ll conclude the series with sample source code from the application that shows how it can be used in real live.

Take a look at the article (it posted on Friday) and let me know what you think. I’m always looking for good constructive feedback!

I took a break from some of my deeper article postings about Byte-Code Instrumentation to publish a couple articles on design patterns. Specifically, I posted an article about the visitor pattern last week and the factory method pattern this week.

The visitor pattern, which has some known limitations, provides a mechanism to iterate over an objects hierarchy and apply some kind of processing logic to that object hierarchy. In this article I provide an explanation of the visitor pattern and an example (8 code listings) demonstrating how it works.

The factory method pattern is probably one that you have already used, but in case you haven’t I wanted to include it in the Java Reference Guide. In short, the GoF defines the factory method pattern as follows: “Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses.” If you’ve ever used a DAO pattern through which you’ve loaded your DAO via a factory then you have used the factory method pattern. This article tries to formalize it a bit and provide an example to illustrate how to use it. And maybe one day I’ll move away from the car examples, but I guess I have a thing for cars (in this example the factory method provides you with an engine depending on your budget.)

In case you want to refresh your mind about design patterns, I’ve covered 21 of the GoF’s 23 patterns in the Java Reference Guide. I foresee two more design patterns coming up within the next month!

Anyone have any requests or suggestions for future articles?

Byte Code Instrumentation (BCI) is the process of modifying the byte code, and hence the behavior, of Java classes either at build time or at runtime. Most typical BCI implementations use either the native agent API or the Java agent API to hook into the JVM’s classloader and modify the byte code for a class as they are loaded from disk into memory.

Over the past few weeks I have been posting a series of articles about byte code instrumentation on InformIT.com. The series begins with an overview describing what byte code instrumentation is and then provides a list of byte code instrumentation library providers. The series is focusing on performance tracing, so the next two articles diverge into describing how to use ThreadLocal to create thread-specific traces and then demonstrate how to manually instrument method starts and ends using the tracing API that I developed. Next I review Java Agents and describe how to create a Java agent, from building the agent with a premain() method, building the class file transformer class, and configuring a MANIFEST.MF file that identifies the agent and grants it permissions to manipulate class byte code. Next week I will describe the Javassist library and show how to use it to instrument classes with the tracing API as they are loaded by the class loader.

Here are a couple interesting things to note about what I just described:

1. The difference between a Java agent and a native agent is that the Java agent is written in Java and started using the -javaagent:<path-to-jar> command line argument while the native agent is typically written using C or C++ and used through the -agentlib:libname command line argument. This is to say that if you are a hardcore Java programmer (as I am – and I mostly forget the C/C++ that I wrote 10 years ago) then byte code instrumentation is still within your reach
2. Javassist is kind of a unique BCI library because it has a mini-compiler that allows you to write Java-like code (it’s really Java code, but there are some special notations for handling method parameters.) This is to say that you can instrument byte code without fully understanding byte code.

Understanding how byte code works and how it is generated from Java source code is a worthwhile exercise, but building a Java agent with Javassist alleviates you from native code as well as byte code.

When the series is complete I’ll present a rather simple, but powerful, tracing library and GUI that you can use to profile your code.

This week in the InformIT Java Reference Guide I published an article on setting up Terracotta and Tomcat to use Terracotta web session clustering. Last week I reviewed the challenges that we face in session clustering and this week I get into the nuts-and-bolts of downloading and installing Terracotta, configuring Tomcat to delegate web session clustering to Terracotta, and building a Terracotta configuration file (tc-config.xml) to tell Tomcat how to connect to the Terracotta server array.

This scenario solves the general case of replacing Tomcat sessions with Terracotta clustered sessions. Next week I’ll present an example of clustering a Struts 2 application and a Wicket application. The Struts 2 application is straightforward to cluster, but with a couple caveats that the Terracotta folks warned me about. The Wicket application requires a Terracotta Integration Module (TIMs) that tells the Terracotta server array how to handle Wicket session information as well as a new session page store in your WicketApplication class that has specific knowledge of Terracotta. It took more work, but it was fairly non-invasive:

• Add a new dependency to your POM file:

<dependency>
  <groupId>org.terracotta.modules</groupId>
  <artifactId>tim-wicket-1.3</artifactId>
  <version>1.4.3</version>
</dependency>

• Add the Terracotta Maven Repository to your POM:

<repository>
  <id>terracotta-repository</id>
  <url>http://www.terracotta.org/download/reflector/maven2</url>
</repository>

• Override the newSessionStore() method on your application class to return a

public ISessionStore newSessionStore()
{
   return new SecondLevelCacheSessionStore( this, new TerracottaPageStore( 100 ) );
}

I’ll post all of the details next week, but if you find any issues with this strategy, please let me know.

I’m in the middle of my continuous integration server article series on InformIT.com, but I want to take the time to give each server enough attention. So in the interim, I decided to start a short series on High Scalability with Terracotta (will publish on InformIT.com this Friday.)  Terracotta is one of my favorite products  on the market because it allows you to achieve 100% reliability in your cluster and almost linear scalability. One of the challenges that we face when clustering a Java web application is dealing with the overhead of serialization as well as the replication strategies for proper fail over (when a server fails or is taken out of your load balancer, your users should be directed to another server in your cluster transparently, without having the re-login and without losing their work.)

In this article I review the common solutions to this problem using serialization and primary and secondary servers and then review what constitutes 100% reliability (any server can fail over to any other server) and the cost in achieving 100% reliability. Finally, I review how Terracotta achieves 100% reliability and near linear scalability through the introduction of the Terracotta Server Array (a Java process that hosts the session information for all of your web applications) and byte-code instrumentation that can intelligently bypass serialization in some cases.

At my day job I am setting up Terracotta to cluster a Struts2-based web application and a Wicket-based application, so I’ll describe my solutions for both in the article series and demonstrate how to cluster an application’s Hibernate cache using Terracotta. The introductory article will be published on Friday. Please let me know if you have any constructive feedback and, in particular, if you have experience with Terracotta’s strengths and weaknesses,

This week in the InformIT Java Reference Guide I posted an article on implementing continuous integration with Hudson. Hudson is probably my favorite continuous integration server because of its robust community and what that community has developed to extend Hudson. In this article I review some of its reporting plugins, such as those for FindBugs, PMD, and Cobertura and then demonstrate not only how Hudson integrates these reports into your build summary, but also how it shows trends for these reports so that you can better understand how well your application is being tested, is your test coverage increasing or decreasing, are you introducing more or less potential bugs, and so forth.

Last week I covered Continuous Integration with TeamCity and next week I will review CruiseControl. So if you are interested in comparing continuous integration servers and seeing them running side-by-side, this article series will hopefully be a good resource for you. As always I solicit your constructive feedback.

First off, sorry that www.stevenhaines.com went away for a few weeks – as you can see I have switched from Quick Blogcast to WordPress (or if you can’t: I switched to WordPress.)

I am starting a new series this week on InformIT.com on Continuous Integration servers. In this series I am going to present an overview of four servers:

• TeamCity
• Hudson
• CruiseControl
• Bamboo

And then provide a final article that compares and contrasts the different servers.I’ve used CruiseControl in the past, we’re currently using TeamCity at work, and I’m using Hudson at home. Bamboo is a late addition to the series, but as I was checking out Atlassian’s Getting Started for $10 offer, I noticed that they are offering 10 “plans” for $10. Because of their generosity with Bamboo, JIRA, Confluence, and others, I thought it would be a good addition to this review.

CruiseControl has an open source free edition in addition to an enterprise version, TeamCity has a free version for up to 20 build configurations, and Hudson is open source and 100% free. I wanted to keep the series to those servers that were free or nearly free for all of InformIT’s readers. If you have experience with any of the servers and would like to share that experience here, I would appreciate your input.

Thanks,
Steve