Bug 57627 - JSP recompilation process confused when tags refer to other tags
JSP recompilation process confused when tags refer to other tags
Product: Tomcat 8
Classification: Unclassified
Component: Jasper
PC Linux
: P2 normal (vote)
: ----
Assigned To: Tomcat Developers Mailing List
Depends on:
  Show dependency tree
Reported: 2015-02-24 07:22 UTC by Kenny Moens
Modified: 2015-03-06 19:45 UTC (History)
1 user (show)

Project with nested tags (13.58 KB, application/x-zip-compressed)
2015-02-24 07:22 UTC, Kenny Moens

Note You need to log in before you can comment on or make changes to this bug.
Description Kenny Moens 2015-02-24 07:22:51 UTC
Created attachment 32516 [details]
Project with nested tags

We have a setup as follows:
- Web project, which contains the necessary JSPs.
- Common project, which contains our common code, but also some generic tags. These tags are defined as regular JSP tagfiles. This one is included as a JAR in the web project.
- Struts library as dependency, the Struts tags are referenced from the JSP pages, but more specifically also from our tagfiles.

The problem we experience is that our JSP pages are always recompiled. Even if nothing is changed in the backend (JSP or library).

Based on our debugging session we found out that, during Java code generation of the JSP file, Tomcat correctly records the timestamp of our JSP files and the common project's JAR file. However, the Struts JARs have all a timestamp of '-1'.

We came to the point of the JspCompilationContext, the method getLastModified, which is used to get the timestamp of these JARs or JSP files. This works correctly for the JSPs, and also for the Common JAR, but not for the Struts JAR.

The metohd gets called with the path of the JAR, but the tagJar variable is filled with the Common JAR's path. It then attempts to get the timestamp of the struts JAR inside the Common JAR, which obviously won't work as that JAR is part of our WAR directly. 

A workaround we apply is to disable the development mode for the JSP servlet and then the problem disappears.

I've attached a project which reproduces the issue at our side.

We experience this even with our older Tomcat 6 installations.
Comment 1 Mark Thomas 2015-03-06 19:45:31 UTC
Thanks for the report the the test case. Bug reports like this are a pleasure to work with - mainly because they take so much less time to resolve.

I was able to reproduce the problem with trunk and 8.0.x and I have fixed it for both of these branches. It will be included in 8.0.21 onwards.

The test case does not demonstrate an issue on 7.0.x or 6.0.x. If you still see issues on either of these platforms with the latest stable release of each then please open a separate Bugzilla issue and we'll take a look.