Application Server Quirks

Tomcat quirks

There are a bunch of Tomcat quirks, let's start a list.

Web-Application startup order and import XSL transformation

Some info

[We|Roel] have found a weird quirk using Tomcat. We use use the extenisibility of Xalan so we can call Java functions from XSL templates, especially for the XSL files for importing articles (NITF) and images (IPTC). For example, here we define a prefix check for a certain class, and we can call functions in the class:

{{ <xsl:stylesheet

xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:check="xalan://com.telegraaf.escenic.CheckVerdachten"

extension-element-prefixes="check"

version="1.0">

}}

and in our xsl templates, we can call the functions like this:

{{ <xsl:value-of select="check:containsKeywords(../Zak)"/>\\ }}

These classes we use in in our templates are in the WEB-INF folder of the escenic web-app.

So far so good. This has been tested and has worked for years on our resin server.

The quirk

Here's the quirk: up until recently we didn't have any problems with imports, but suddenly our imports were buggy. Articles would be imported in the correct section, but the fields were not filled with any text. The images were imported but the size of the pictures was not set (dimension -1 x -1) and no fields were present. Obviously, something was wrong with these imports.

The cause

What had changed? We had only added one more web application to our Tomcat configuration.. The Catalina (Tomcat) log showed us that before we added this web application, the 'escenic' webapp was always the first to start. But in Tomcat you have no influence of the order in which applications are started, and after adding another web application, one of our publications web-app was started first, and the escenic engine 2nd, 3rd or ..

Somehow, the classes used in the XSL files could not be found anymore during transformation. This is weird, because the escenic engine web application takes care of the XSL transformation during imports, and should have no problem finding the classes in its WEB-INF directory. Apparently, it does have a problem.

The work-around (solution)

A work-around to this quirk is to place the classes that are used in XSL files on a higher level. In this case we placed them in Tomcat's shared classloader directory.