In March 2007 Europol, the European Law Enforcement Organisation, has released their EU Terrorism Situation and Trend Report. TE-SAT was established in the aftermath of the 9/11 attacks in 2001 to establish a reporting mechanism to the European Parliament.

Read more...

For asynchronous messaging we are using Active MQ in a few web applications deployed to Apache Tomcat.

This works quite well until you start redeploying the applications multiple times without restarting Tomcat. After a few redeployments you will inevitably hit a java.lang.OutOfMemoryError: PermGen space. This usually indicates a memory leak caused by the class loader of the web application not being garbage collected.

I've used Lambda Probe to get an overview of what's going on: Indeed PermGen usage increased with each redeployment until it finally hit the wall after 4 minutes (redeploying every 30 seconds) as you can see on the first chart. Having a look at the memory with YourKit Java Profiler also showed an additional WebappClassLoader after each redeployment. The problem with the leaked WebappClassLoader is that it contains hard references to all classes that it has loaded – for our webapp more than 2000 – that pollute the PermGen.

What is causing the WebappClassLoader to leak?

There are two common causes:

• Threads started by the webapp that are not properly terminated
• References to your objects or classes from outside of your webapp

As it turned out ActiveMQ uses a few internal "ActiveMQ Scheduler" threads that are part of a ThreadGroup of a maximum of 5 threads. These threads are not properly cleaned when ActiveMQ is shut down. AMQ-1214 describes the issue.

What can we do to prevent the leak?

The ThreadGroup must be shut down. Fortunately the clockDaemon property is publicly accessible so the easiest solution was to add a clean up bean to my spring context that calls it shutdown() method when the context is destroyed.

import org.apache.activemq.thread.Scheduler;
import org.springframework.beans.factory.DisposableBean;

public class ActiveMQCleaner implements DisposableBean
{
    public void destroy() throws Exception
    {
        Scheduler.clockDaemon.shutdown();
    }
}

As you can see in the second chart this fixed the problem. More than 20 minutes and 50 redeployment cylces later still no OutOfMemoryError.

If you are interested in other causes of PermGen leaks and strategies to hunt them have a look at Frank Kieviet's Blog and his JavaOne Presentation.

Jim Alateras talks about how Buildr could replace Maven in a blog entry titled "From Maven to buildr".

Buildr claims to be a drop-in replacement of Maven as it uses the same file layout, artifact specifications, local and remote repositories.
For sure the best practices built into Maven are great and the central repository is a place where you'll find almost every relevant open source java library but Maven is much more. Maven's big advantage over ant is a declarative approach describing projects instead of describing (or programming) the build process. Buildr drops the Maven POM (project object model) and returns to coding the build process — this time not in XML as in ant but in Ruby. Apache ODE’s Rakefile may serve as an example.

Jim notes that Buildr seems to be faster than Maven and continues

All extension tasks (ala maven plugins) are written in Ruby so you get all the power and benefits of a turing complete language as opposed to the constraints of maven plugins.

Well since Maven 2 all its plugins are written in plain Java — seems like the author really should have invested some time to actually look at Maven's design.

Can we learn from efforts like Buildr?

Well, the POM used by Maven to describe the projects is a bit verbose in some cases, this should be addressed in future versions. Besides that some performance optimizations might be a good thing tough I don't think they are so badly needed. Maven already reduces the time to build by making it very easy to reuse pre-built snapshots of depentant modules.

Besides this it will remain a religious issue on whether you prefer a declarative or a procedural approach for your build process. If you prefer the later have a look at Buildr but don't buy it as a drop-in replacement but as a different solution that reuses some of Maven's achievements.

The User Status Plugin is a small plugin for Openfire 3.3.2 to save the user status to the Openfire database.

Use the plugin if you need easy access to the data from other applications or scripts that can access your Openfire database.

The plugin automatically saves the last status (presence, IP address, logon and logoff time) per user and resource to userStatus table in the Openfire database.

Optionally you can archive user status entries (IP address, logon and logoff time) for a specified time. History entries are stored in the userStatusHistory table. The settings for history archiving can be configured on the "User Status Settings" page that you'll find on the "Server" tab of the Openfire Admin Console.

Development of the plugin has been sponsored by Restomax.
It is available under GPL for download.

Note: Rename the plugin to user-status.jar before deploying it to the plugin folder of Openfire.

Ed Burnette notes "Despite public comments by Steve Jobs that 'Java’s not worth building in [to the iPhone]', it turns out that Apple did just that by using an ARM-based CPU that supports Java natively. Programmers cannot (yet) take advantage of this, but Apple could, if they wanted, ship a software upgrade to enable it."

The processor in Apple's iPhone nativly supports Java bytecode. On top of that the Jazelle technology software provides a full featured multi-tasking Java Virtual Machine, highly optimized to take advantage of Jazelle technology architecture extensions available the processor core.

So what is the point? Apple's strategy regarding Java does not seem to be technically motivated. Have a look at Java 6 support in OS X: While they were quite fast with the first beta snapshots (released almost at the same time for OS X, Windows and Linux) a final Java 6 JDK will probably never be released for Tiger. If Leopard will support Java 6 that's almost one year after Java 6 for Windows and Linux has been released by Sun.

Maybe the open source community will take over and port OpenJDK to the Mac. For now I am pissed and as a Java developer I feel discriminated against :-).

When assembling applications from a set of reusable compoenents that use the Spring Framework to wire their beans you will end up with a whole bunch of Spring configuration snippets spread around the JAR files containing your components.

Components should be self-contained so everything belonging to the component (including configuration) should be part of it. Ideally assembling the application would just mean dropping an additional component JAR file into the classpath (i.e. adding dependency to its Maven POM) and using the beans it exposes.

A simple convention makes this quite easy: Just put a spring.xml file into the META-INF directory of your components and declare the application context in the application's web.xml like this:

<context-param>
  <param-name>contextConfigLocation</param-name>
  <param-value>
    classpath*:META-INF/spring.xml
    /WEB-INF/applicationContext.xml
  </param-value>
</context-param>

The result: For each component the contained spring.xml is added to the application context and any beans defined therein are automatically created on deployment.

To make sure no name clashes occur you should establish a simple naming conventions for the id attribute of your beans like component.beanname. Resources defined in the main application context that the components require like Hibernate sessions will be named core.beanname.
For example:

<bean id="pbx.pbxDao" class="com.reucon.astis.dao.hibernate.PbxHibernateDao">
  <property name="sessionFactory" ref="core.sessionFactory"/>
</bean>

IntelliJ IDEA 7.0 (Selena) which is currently available as part of Jetbrain's Early Access Program now supports Maven out of the box.

The efforts of various previous third party plugins have been joined into a first class feature with support for

• running Maven goals directly from the IDE similar to the ant integration
• synchronizing pom and IDEA project files (updating depedencies, etc.)
• a default project layout conforming to Maven standards in the project wizard.

Given the fact that Eclipse is still unable to ship out of the box support for Subversion - not to talk about Maven - this makes choosing the right IDE quite easy.