tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Gainty" <>
Subject Re: JSP/Tag recompilation on running server
Date Wed, 30 Jan 2008 19:21:40 GMT
Answered by Bill 5 years ago..

This will turn off tag-pooling.
You'll also need to clear out $CATALINA_HOME/work so that the JSP pages get

relevant doc at


----- Original Message -----
From: "Chris Hut" <>
To: "Tomcat Users List" <>
Sent: Wednesday, January 30, 2008 1:46 PM
Subject: JSP/Tag recompilation on running server

Hi all,

We use a "global message" .tag file to display any important updates to
users - by default it is blank but can be updated to say, e.g. "Site
will be going down for maintenance in one hour.".  We push these updates
by deploying an updated .tag file to our system.

We just switched to Tomcat 6.0.14 (from Resin) in our production systems
and everything is running smoothly except for JSP recompilation when
updating tags.

Here are the relevant Jasper settings from web.xml:


The behavior we see is: if we drop in a new .tag file, dependant JSPs
are properly re-compiled - the timestamps on the JSP and tag classes are
updated - however, the contents of the new tag are not always updated
(it seems indeterminant whether it happens or not).  It's difficult to
reproduce in a localhost environment (that is, the update seems to
always work properly there), leading me to think it might have something
to do w/ load or concurrency.

Since the tag and JSP .class files are updated (can tell by the
timestamps in the work directory) we were wondering if it could also be
related to tag pooling (i.e. the JSP is getting "stale" instances of the
tag objects) in which case I'm wondering if there's a way to "reset" the
pool, or if there are any other known issues about recompilation that we
might be running into.

I realize that updating tags in a production environment may not be
considered a best practice (though background recompilation described in
the Jasper docs sounds like it should be good to go) but we were hoping
we could rely on it for small text UI updates.  Of course there are
other options (database, etc) we could look into if needed, too.


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message