Pauses Café

In this serie of articles, we will explore the JMX capabilities of Java applications, in particular with CruiseControl. If you are familiar with CruiseControl and JMX, you may want to skip directly to the installation procedure.

For the others, CruiseControl is a continuous integration system, an application that schedules and builds your software, notifying you upon failure. It can do much more (handling reports, publish artifacts), but we don’t really to know much more about that now.

CruiseControl comes as a 2 part system:

• a build loop, a daemon configured using an XML file which performs the build work
• a reporting web interface, with which most users interact

The CruiseControl web interface is a simple presentation layer. By default, it doesn’t provide a particular interface to modify the build loop configuration or interact with the scheduling operations (e.g. kick off or pause a build). Still you can perform these operations. Thanks to JMX.

JMX is a Web-friendly Java API that allows for managing and configuring applications, devices, services locally or on a network.

CruiseControl 2.2.x comes with inbuilt JMX support, thanks to mx4j, an open source JMX implementation which also supports JSR-160 (the 1.0 JMX Remote API). The CruiseControl build loop exposes its internals (a set of Java beans) through JMX and lets you enable up to 2 different connectors (HTTP or RMI). These allow for JMX clients based on different remoting technologies to control your build loop. The HTTP connector is in fact a self-contained simple HTTP server and can be controlled by a simple browser.

For practicality, the reporting module contains a panel that can be configured to access the build loop inbuilt HTTP client which then lets you invoke methods or read properties on the exposed configuration/controller beans. For example the object representing a Project has a build() method, and JMX will allow you to invoke it on a particular project object, thus triggering a build.

For the curious, the CruiseControl class that enables the 2 types of JMX connectors is CruiseControlControllerAgent.java.

So if you enable the HTTP connector, and correctly configure your reporting module to access your build loop, you end up with something similar to:

But if you have several CruiseControl installations (for example, to support different platforms), or if you have different applications that use JMX, you may want to centralize all your JMX management needs. That way you will provide a single access point to your services, easing the access and access control to your various systems.

And here comes jManage. From the web site:

jManage is an open source, web and command-line based JMX client, which provides a centralized console for managing application clusters and distributed-application production environments.

In this first tutorial will show you how to install jManage and connect it to the CruiseControl JMX interface.

Preconditions.

• CruiseControl is running on a remote machine
• You have a JRE (>=1.4) on the machine where you want to install jManage.

And now the installation and configuration steps are:

• install JManage on a machine. Here’s a quick worklog:

  > jar xvf jmanage-0.5.jar
  > cd jmanage-0.5
  > find . -name "*.sh" | xargs chmod +x
  # I've had to do that in order for the interaction with cruisecontrol jm4x to work
  > cat > classes/jndi.properties < < EOF
  java.naming.factory.initial=com.sun.jndi.rmi.registry.RegistryContextFactory
  EOF
  # edit jmanage.properties and change the port if necessary
  # start jManage, choose a password
  > ./bin/startup.sh
  

• make sure cruisecontrol starts with the httpConnector (specify -rmiport [portnumber] in your build loop startup script)
• restart cruisecontrol build loop & check your logs. You should see something like “INFO CruiseControlControllerAgent - starting connectorServer”
• if necessary, don’t forget to change your firewall rules
• login using admin/$yourPassword
• add a new jsr 160 application, with “service:jmx:rmi://$yourHost/jndi/jrmp”

Voila!

Through the jManage interface, we now have the same information as found in the Control panel page (1). But even if it looks the same, there are some key differences:

• The jManage application runs on a remote machine
• It is now very easy to perform centralized operations like access control

We will look into that in a next post.

Notes:

•  note, the description of the properties and methods is apparently missing in the jManage interface, I will look into it.

You use a remote source control server (e.g. CVS) that you access through ssh.
But now you want to set-up some kind of automated procedure that retrieves/updates the files. That can be usefull if you have a separate CruiseControl server.

So the first thing it to learn how to use ssh keys. I had a former blog entry not so long ago pointing to a good resource. Now this guide shows the transparent use of ssh with rsync and cron. In order to use it with our setup we have to make some little changes.

  mkdir -p ~/tmp
  chmod 700 ~/tmp
  ssh-agent > ~/tmp/ssh-agent.startup
  chmod +x ~/tmp/ssh-agent.startup
  . ~/tmp/ssh-agent.startup
  rm ~/tmp/ssh-agent.startup
  ssh-add ~/.ssh/host-cvs-dsa-key

I have started using quilt for my patching needs. While working on some projects where I don’t have committing rights, my patches tend to queue in line. Managing them becomes a pain, in particular when it comes to unrotting.
The solution I used before was to create several directories, one for each patch you are working on. But I don’t like it. It takes too much disk space (in particular when the projects include their own libraries) and has other issues. In particular I like to use a single IDE

Quilt is supposed to help me managing my patches, by maintaining a stack of your changes.
Quilt has an overall good documentation: PDF and man pages.

Importing my patches in it was the first thing I had to do. Here’s a simple worklog:

# get your project
> cvs co yourproject
> cd yourproject
# repeat the following for each of your patches:
# prepare to create a new patch (called myfix1.diff)
> quilt new myfix1.diff
> quilt fold -p0 < patch1.txt
# quick fold finds the modified files add them to the patch currently on top and applies the specified patch (like quilt import does).
# You could reproduce something similar with:
# grep +++ patch1.txt  | cut -c 5- | cut -f 1 | xargs -l1 quilt add
# patch -p0 < patch1.txt
# obvisouly not as easy 
# Now take the changes into account
> quilt refresh myfix1.diff

I have now to find a way to maintain these patches accross several machines and autopublish them.