some time ago Aljona showed
how to monitor and manage your java application with jmx

I'm going to show, how you can make use of JMX from the viewpoint of a sysadmin.

initial point:

You have a Java-application deployed in an applicationserver like JBoss or Tomcat and you want to monitor the health of this application(including the applicationserver and the Java-virtual-machine it is running in) with a tool like Nagios.

Use Jolokia on the server-side!

Why do i have to use an extra Agent for this? My applicationserver is able to use Mbeans.

Modern web applications often consist of quite some configuration files that should at least be tested for validity. Think of Spring controller configurations, web application descriptors and the like that can't be tested easily using Unit Tests. Fortunately it's quite easy to start a tomcat instance on your CI system (Jenkins or Hudson) using the Tomcat Maven Plugin.

As you probably don't want to start and stop the server on every test run it's a good idea to bind it to the integration-test phase, probably even to a separate profile that is only triggered on the continuos integration machine. This is what the plugin configuration might look like:

At Synyx we're currently taking care of a rather large legacy project for one of our customers in the course of our Code Clinic services. The project comprises several components such as a fat client implemented with a custom UI framework on top of Swing, a bulky web application using a mixture of custom and obsolete frameworks, and a lot of asynchronously running jobs to process input from other systems involving custom XSL transformations and a heap of stored procedures in a Oracle 9i database. You get the picture, it's the prototype of a legacy system.

7 Little Logging Frameworks on their way into your code base

The original developers of the system suffered a serious case of the well-known NIH syndrome and thus a lot of technical debt has been piled up over the course of its development.

Continue reading →

Ever wondered why Tomcat reloads the context when editing web.xml?

This is a default configuration that can also be adjusted to your needs. The file conf/context.xml is the default context configuration that is used for all webapps. In this file you can find the line

<WatchedResource>WEB-INF/web.xml</WatchedResource>

which triggers the reload for any web.xml.

You can either add more resources here or, preferably, add your own context configuration with your resources.

Find out more about context configuration in the Tomcat documentation.

When developing web apps with Maven the de facto standard for running the app is to use the excellent Maven Jetty Plugin which runs the project in an embedded Jetty server. When configured, it can either run the project from the war file directly via mvn jetty:run or in exploded mode where the war is unpacked before being run (mvn jetty:run-exploded). This noticably speeds up development as there is no need to manually deploy the artifact to a server.

But if the production system does not run on Jetty but on Tomcat you might run into some problems: