Tomcat behind Apache HTTP server using Spring Security

Since I have been struggling with applications not working properly behind Apache HTTP server that use Spring Security I dedicated this blog to this issue.

When you develop an application using Spring security this works fine when just running on a Tomcat server e.g. http://localhost:8080/app-context/. The problems start when you want to setup your environment properly by adding an Apache HTTP server in front of it using proxy AJP. You would start by adding the following to your apache config file:

ProxyPass /app-context/ ajp://localhost:8009/app-context/


This works fine when trying to go to http://servername/app-context/ but when you try to login you will be redirected back to the login page everytime. To avoid this behavior you need to add the following line to your Apache configuration:

ProxyPass /app-context/j_spring_security_check ajp://localhost:8009/app-context/j_spring_security_check


For some reason it doesn't work without this line which seems weird to me since you basically map the context and everything that comes after it with the previous line. After trying a lot of options I just tried adding this and this seemed to work. I discovered that when I was logging in (using firebug) that it couldn't find the path /app-context/j_spring_security_check so I tried adding it and it finally worked :-).

There is still one thing left to do though since you also want to be able to logout you have to add the following line too:

ProxyPass /app-context/j_spring_security_check ajp://localhost:8009/app-context/j_spring_security_logout


Configure Tomcat as a deamon on Linux

Since I keep on forgetting how to do this I decided to put this on my blog to make it easier for me and other people that have the same issue as me. It's pretty simple actually but yesterday I caught myself forgetting how it needs to be done. Basically you need to follow to following steps to successfully.

Step 1 - Creating startup deamon file

You can take the following file and adjust it accordingly. You have to create this file in /etc/init.d/.



#Jenkins startup script
#!/bin/sh -e
#Jenkins startup script
#chkconfig: 2345 80 05
#description: Jenkins CI

# Define some variables
# Name of app
APP=Jenkins
# Name of the user to run as
USER=tomcat
# Location of application's bin directory
BASE=/var/tomcat/instances/jenkins
# Location of Java JDK
export JAVA_HOME=/opt/java/jdk1.6.0_11

case "$1" in
# Start command
start)
echo "Starting $APP"
/bin/su -m $USER -c "cd $BASE/logs && $BASE/bin/startup.sh &> /dev/null"
;;
# Stop command
stop)
echo "Stopping $APP"
/bin/su -m $USER -c "$BASE/bin/shutdown.sh &> /dev/null"
echo "$APP stopped successfully"
;;
# Restart command
restart)
$0 stop
sleep 5
$0 start
;;
*)
echo "Usage: /etc/init.d/$APP {start|restart|stop}"
exit 1
;;
esac

exit 0


Step 2 - Register your deamon

To register your deamon you can use chkconfig. This will make sure your deamon will be started up on boot and enables you to use the following command to start and stop your tomcat instance.

To start:

service jenkins start


To stop:

service jenkins stop


To do the magic you should execute the following command:

chkconfig jenkins --add


Now your done :-)

Cargo-itest extended

I have been doing some work on the cargo-itest project and extended it with the following features:
- JOnas support
- Jetty support
- Auto detection of configuration files for JBoss
- Extended logging information to be able to detect problems in an easier way

These changes will be in the next release 1.2.0.

The auto detection is a nice one since it automatically picks up .properties files and -ds.xml (Data source files) from a preconfigured location so you don't have to copy them selves to the correct location. :-)

In the future we will try to implement configuration by annotation since some users prefer doing configuration through annotation instead of an XML file. In this case a Spring context file.

Disk Defragmenter Could not start

Anyone getting the "Disk Defragmenter Could not start" message and on Windows XP this is what worked for me.

Go to Control Panel, Select System and select the Advance Tab. Now Select Settings Under Performance and again select the advance tab. Under Virtual Memory select Change. Make sure that the Paging File Size for selected Drive for the Drive partition you want to Defrag has either a custom at least 2 times the amount of installed RAM if the space is available or is set to System Managed Size.

Once I did this Defrag started working again. I don't know how the Page file got turned off on my system but this has been driving me mad for months!! Hope it helps someone else out there !!!

Shared configuration on Tomcat 6

In Tomcat 5 there was the famous ${catalina.home}/shared/classes which you could use for sharing class files, properties files etc. Tomcat 6 by default doesn't come with this directory. In a first glance it seems that you can't do it anymore :-(.. But that's not true :-)..

You need to configure Tomcat to point to a directory which you want to be shared location so applications can pick up resources from the classpath. The configuration is very simple. Just go to ${catalina.home}/conf and open catalina.properties. Add the path to the shared.loader property. It will look something like this:

#

# List of comma-separated paths defining the contents of the "shared" 

# classloader. Prefixes should be used to define what is the repository type.

# Path may be relative to the CATALINA_BASE path or absolute. If left as blank,

# the "common" loader will be used as Catalina's "shared" loader.

# Examples:

#     "foo": Add this folder as a class repository

#     "foo/*.jar": Add all the JARs of the specified folder as class 

#                  repositories

#     "foo/bar.jar": Add bar.jar as a class repository 

# Please note that for single jars, e.g. bar.jar, you need the URL form

# starting with file:.

shared.loader=${catalina.home}/shared/classes

This can be very usefull when you want to share configuration between several web applications or even just to decouple the configuration from your web application in an easy way. Using this makes it easier to have a platform independent configuration without creating separate artifacts for every platform. :-)

Fastest XML parser

In most applications you need to do some XML parsing to either provide XML to external systems or parse XML from external systems or of course both. Since the systems I work on use a lot of XML and they need to be as fast as possible I did some tests on several XML parsers. I tested the following parsers/XML frameworks:

1. JDom
2. Piccolo
3. StaxMate
4. XStream
5. JAXB 2.1

All parsers were tested in isolation with the following parameters:

1. 25 threads running simultaniously
2. Every thread calls the parser 100 times

The results are as follows.

1. JDom
   Avg. parsing time: 325.24 ms
   Avg. memory usage: 307 KB
2. Piccolo
   Avg. parsing time: 88.08 ms
   Avg. memory usage: 454 KB
3. StaxMate
   Avg. parsing time: 96.16 ms
   Avg. memory usage: 203 KB
4. XStream
   Avg. parsing time: 77.04 ms
   Avg. memory usage: 319 KB
5. Jaxb 2.1
   Avg. parsing time: 1778.12 ms
   Avg. memory usage: 618 KB

As you can see XStream is the fastest one of them all. The total ranking of the parsers you can find below:

1. XStream
2. Piccolo
3. StaxMate
4. JDom
5. JAXB 2.1

As you can see StaxMate has the smallest memory footprint. The total ranking of the parser you can find below:

1. StaxMate
2. JDom
3. XStream
4. Piccolo
5. JAXB 2.1

If you take the ovarall pro's and con's XStream comes out as the best choice as it comes to:

1. Speed
2. Memory footprint
3. Ease of use

JDom has a remarkably low memory footprint but this is because the test was done with a single XML file which wasn't that big so when the XML file will grow the memory footprint will drastically grow with JDom since it loads everything in memory to construct the full document.

JAXB is dissapointingly slow and has a huge memory footprint. The ease of use was a big plus though but if you compare it to XStream it's almost the same. XStream also provides annotations to easily map XML to Java objects. And it performs much better.

Piccolo was a bit slower than XStream but there is a significant difference in the memory footprint but also in the ease of use. When using Piccolo you need to implement a lot of stuff that you actually don't use at all. Also a lot of Exceptions need to catched resulting in a lot of boiler plate code.

StaxMate would also be a good choice but the ease of use compared to XStream or JAXB lacks a bit.

XStream itself also has some additional features like:

1. JSON support.
2. Streaming capabilities.
3. Ability to switch to other type of XML parser without changing the parsing code.

So in general if you want fast XML parsing and an easy to use API I would recommend to use XStream. :-)

Cargo-itest continues

The 0.3 version of my cargo-itest project now also supports Tomcat. So now Tomcat users can also write integration tests with fairly little effort.

I am also extending it with an AbstractDefaultHibernateDeploymentTest which can be used to easily generate your database schema from your annotated classes. Before it wasn't possible to execute SQL scripts for test data. Now I added the functionality to enable you to execute SQL scripts before the deployment tests are run and also after. The execution of the SQL scripts will be before and after transaction so it will not be rolled back by the test case itself. Internally it uses the AbstractTransactionalJUnit4SpringContextTests but you only need to configure a list of file names in your itest-context.xml file which in turn will automatically be picked up by the test.

Also added support for applications that don't use a database at all with the AbstractDefaultNoDbDeploymentTest class. In the near future I will also implement container utilies for:

1. Jetty
   
2. Resin
   
3. Jonas