Apache has released an application server called Geronimo. There are many open source application servers, so what is special with Geronimo? The answer is that Geronimo can be configured easily to suit your application needs. Typically an application server contains different containers that specifically do a particular job. For example an EJB container will be responsible for EJB related requests and there could be a transaction container that is responsible for handling all the transactions. In most of the application servers these come by default and whether your application uses it or not some of them run by default. This could be an unnecessary consumption of memory and server startup time.

Geronimo’s componentized application server model can be configured to run only the containers that are required for your application. The building block of Geronimo is what is called as GBeans (Geronimo Beans). GBeans are objects that are responsible for handling specific task within the application server. Geronimo extensively uses Dependency Injection pattern, also called Inversion of Control (IoC) pattern (if you want to know more about IoC pattern an excellent starting point would be Martin Fowler’s article on “Inversion of Control Containers and the Dependency Injection pattern“) wherein a container helps in adding the individual services to the kernel and the kernel does not need to know what services it has to run when it starts.  OnJava.com has published recently an article “What is Geronimo?” that introduces Geronimo with instructions to deploy a simple application.

Unit testing is important and a developer has to create unit test code to automate the unit testing process. But it is always that the code the developer has written is dependent on code that would be written by some other developer. When that code is not be ready yet, it will be difficult for developer 1 to write his/her unit test code. To make it simple, lets say developer 1 develops code for class A and class A is dependent on class B. Class B has to be done by another developer or let’s say that the design is not ready yet to write code for class B.

So how does developer 1 create his unit tests when the dependent class is not ready? The answer is to mock the code B. The mock object is a dumb object having same method and field signatures but with a different class/program name (example BMock) and the methods always return back a static output. The mock object is a temporary object to fool the test case of object A that the functionality dependency will be met by the class BMock. Once the actual class B is ready, it is just a matter of replacing the BMock declaration and instantiation to B. Now this process can even be made simpler when coding to an interface. The Mock object is an implementation of the same interface that the actual implementation would implement. In this case the changes necessary after the original implementation is available will be minimal.

Mocking frameworks help in creating mock objects to reduce the additional effort required to create these classes. There are several mock frameworks. Some of them listed below.

1. EasyMock - Generates mock objects for interfaces on the fly
2. JMock - Lightweight framework that can be extended and configured
3. rMock - Another framework for Java that can be used with JUnit
4. EasyMock.net - EasyMock for the .Net environment
5. MockR - Mock for Ruby

To kick start with EasyMock, here is a good article “Getting started with EasyMock“.

Continuous Integration is one of the principles of Extreme Programming. Continuous Integration helps in bringing up the integration issues early on in the project and resolves them early so that there are no surprises when the project is deployed on the server. Martin Fowler’s site has this article on Continuous Integration that explains in detail the process and benefits behind Continuous Integration. We have a setup a continuous integration environment for J2EE projects with the help of following tools.

• Subversion - Subversion is an open source version control system that can keep track of the code changes. The developers commit their code to this version control system which is located on a server.
• Maven - Maven is a project management automation tool that also helps in packaging the application. Our projects are mavenized and follow the Apache packaging structures. Look at my build automation series of posts to know more about mavenizing a project.
• LuntBuild - LuntBuild is a J2EE based tool that helps in scheduling and executing build automation. It supports build automation tools like Ant and Maven and has a web user interface to configure and manage the schedules. We have a nightly build schedule and continuous integration schedule.

This is what happens in our continuous integration environment. When a developer has completed his/her code he/she runs maven on his/her desktop. Maven runs the unit tests, packages and deploys the application on an application server on the desktop. Once the build is successful and the developer is happy with the results he/she synchronizes his/her code with the Subversion repository. If there are any modifications to the mainline code (the latest and greatest available in the repository), he/she updates the code from the repository to the local environment. He/She again runs the maven script locally to make sure still the build is intact and works fine without any problems. If there are errors then those are fixed until the build is successful on his/her desktop. Once the build is successful on his/her desktop he/she commits the code to the Subversion code repository.

In the development server we have LuntBuild installed and configured to manage build automation schedules. A schedule is similar to UNIX cron job that gets triggered every 15 minutes. The project’s details and the Subversion details are configured in LuntBuild. When the schedule is kicked off a process determines if there is a change in the Subversion repository since the last build. If no change is detected then it goes to the sleep mode. If a change is detected, it gets the mainline code (latest) from the Subversion repository and triggers maven. Note that the maven project object model (pom.xml) is also part of the code and gets checked in into the Subversion. If the build is successful, the build output (an enterprise archive file) is copied to the JBoss application server’s directory. Since JBoss has hot deployment feature (with this I don’t need to restart the application server when I want to deploy a new version of the application. It sniff’s changes and picks up the changes automatically) the integrated application is available for testing. LuntBuild sends out a mail to the developers whether the build was successful or failure. If the build is a failure then the developers take appropriate action by looking at the build logs and correct the issues.

Since Maven runs automated unit tests and also generates test results, site documentation of the build and API documentation, it is linked from our project wiki site so that anybody in the team can see what the latest with the application is. Since the site generation would require some additional time in the overall build process this is done only during the nightly build (this is another schedule configured in LuntBuild that gets triggered midnight every day).

Some discipline would be required from the team in order to use continuous integration effectively. This article from Martin Fowler points out the disciplines required to have an effective continuous integration environment.

Getahead’s DWR (Direct Web Remoting) is a javascript framework that enables Ajax with j2ee applications. Recently etahead launched a new use of AJAX called reverse AJAX. In reverse AJAX the response is a push from the server to the clients rather than the traditional pull. The server code pushes the javascript to the clients who are connected to the server. Read this article from Ajaxian on uses of reverse Ajax.

Mergere has published a guide titled “Better builds with Maven“. The guide contains a complete walkthrough of how to use Maven 2 for building and deploying J2EE applications.

PS: Please click here for the complete Build Automation series of posts.

Singleton pattern is the most simplest and easiest of the design patterns that any designer/developer would be aware of. The purpose of a singleton pattern is to make sure that there is only one instance of an object throughtout the application’s life. Once an instance is created, the design makes it in a way that only that instance is used even if the program tries to create a new instance of it. The singleton object itself is lazily loaded meaning it is loaded only when the first use of the object is encountered. In essence Singleton objects have an application scope.

I was thinking that if I follow the design principles behind the singleton pattern I have a singleton object until I read through the JDC Tech Tips published in January this year. I thought this would be worth mentioning since I mentioned about class loaders few days back. According to the tip, if you are using a singleton pattern in your application and your application is a web application then which class loader in the application server loads the singleton class plays an important role in deciding really whether your class is a singleton or not. If the System class loader loads the singleton class and that instance is shared by all the other class loaders, then it is really a singleton object. If multiple class loaders were able to load the same class, then you dont really have a singleton object. Makes sense to me.

Class loading is a fundamental aspect of the Java programming language. A Java programmer should definitely understand the lifecycle of a class, when it gets loaded, linked, intialized and unloaded. Class Loaders are primarily responsible for handling these. The JVM has a bootstrap loader that takes care of this. Custom Class loaders could be created and could be loaded by the bootstrap class loader from which point onwards the custom class loader can customize and handle the default class loader’s functionalities. For example the AppletClassLoader is responsibe for loading the applets over the net and displaying them on the browser. This class loader is loaded by the JRE on the browser system whenever an Applet tag is encountered in the page. The class loader architecture in JVM (Java Virtual Machine) is well explained by Bill Venners in “Inside JVM” book. You can take a look at the class loader architecture in the introduction chapter of the book available here in artima.

Class Loaders play an important role in application servers determining where to look for a class. The ability to create custom class loaders has paved way in the advancement of specialized containers in application servers. Most likely you would have heard of web container and ejb container, they all have custom class loaders to manage the classes specific to the containers. A key problem in the J2EE arena is to solve the class loading problems or to put it crude, the CNFE’s (ClassNotFoundException). The J2EE application structure has different components. When deployed to an application server, these are loaded by different class loaders. If you have deployed a J2EE application, you might have already set some classpath’s, system classpath’s and application class path’s. How the class loading happens? How is the path resolved? This wonderful article on “J2EE Class Loading Demystified” talks about the class loaders in the Websphere application server and how it works.

If you have worked on an ide like eclipse you might have already thought the structure created by Maven is different from how eclipse structures a project. If you directly import the maven created structure into eclipse you might see that eclipse identifies the project as disoriented and shows up compilation issues. No worries, there is a eclipse plugin for maven that comes to rescue. Issue the following command.

c:\helloworld\>mvn eclipse:eclipse

Eclipse workspace needs two important files that determines the project information and the classpath information. These information are stored in the files .project and .classpath respectively. The eclipse plugin modifies these files exactly what is needed in order for eclipse to understand the maven structure. Once you execute the above command, you can use eclipse to point to the directory to load the workspace. You can look at guide to using eclipse with maven for more information.

Maven helps in bringing discipline in the way the code is organized and structured and also helps in automating it. Suppose a new developer joins in the team, all you have to do is setup maven on the developer’s machine, pull down the current source that includes the pom from a version control system, apply the eclipse plugin and the developer is all set to start writing code. What’s more he/she can run maven to package it and deploy it locally and test it too. Thus everyone follows the automated process and the code and structure is standard across the team.

What we saw in this six part series on “Mavenizing your project” was a kick off to Maven. Maven can do a lot more stuff like site generation, code metric collection etc with the help of external plugins. Click here for a list of plugins available for Maven2.