On a recent project I had problems deploying a web application built on the Struts 2 MVCframework to a fresh WebSphere installation. I wasted a lot of time labouring under the incorrect assumption (for once) that the architectural changes I had introduced in the latest sprint were the cause of my troubles.

But it turned out to be an environmental issue. We were deploying Struts 2 as a servlet filter and out of the box WebSphere does not support HTTP requests that are served by a servlet filter. A custom property called com.ibm.ws.webcontainer.invokefilterscompatibilty must be set for the web container. I guess I should have just deployed straight to the UAT environment!

Here is the procedure for setting the com.ibm.ws.webcontainer.invokefilterscompatibility custom property:

  1. In the administrative console click Servers > Application Servers > server_name> Web Container Settings > Web Container.
  2. Under Additional Properties select Custom Properties.
  3. On the Custom Properties page, click New.
  4. On the settings page, enter com.ibm.ws.webcontainer.invokefilterscompatibility in the Name field and true in the Value field.
  5. Click Apply or OK.
  6. Click Save on the console task bar to save your configuration changes.
  7. Restart the server.

On my current assignment we are developing a multi-tennant web application and are giving the individual tennants the ability to customize the look and feel of the application. We are using Jackrabbit to host the style sheets, images and scripts that for each of the look and feels.

Initially I tried to deploy Jackrabbit as using the Shared J2EE Resource deployment model on WebSphere 6.1. Due to a leathal cocktail of stupidity and environmental constraints I couldn’t get it working earlier in the project and decided to settle for the Application Bundle deployment model.

Now we need to have more that one instance of the application running in the test environment and we’ve had to finally figure out how to get the Shared J2EE Resource deployment model up and running.

It turned out to be a lot easier than I exepcted. In order to get Jackrabbit working I just needed to customize the ra.xml deployment descriptor from jackrabbit-jca-2.2.x.rar by changing the <transaction-support/> element to from XATransaction to NoTransaction.

This change is necessary because Jackrabbit does not support local transactions and actually raises an exception when called by WebSphere.

Rather than have to customise this by hand I a put together the Maven POM below to build custom RAR for me. You must place the ra.xml deployment descriptor in src/main/rar/META-INF.