Tomcat 5.5/6 - JSP Reload

[Sylvain Goulmy <sy...@gmail.com>]

Hello everyone,

Having spent some time trying to understand why when I deploy a new version
of my JSP, it was not recompiled, I observe that in fact a new version is
taken into account only if the modification timestamp of the new JSP (Linux
Environment) is newer than the modification timestamp of the class generated
for the JSP in the work directory.

If I change the modification timestamp of the JSP directly into the webapps
directory with a command like:

touch-m-t 1104071423.16 BonjourResult.jsp

and set it to a newer value, it works very well.

The big problem is that this method of detection does not work for a
rollback... You can of course do the cleaning at the work directory level
but it is not at all adequate in terms of performance since it will force the
recompilation of all the JSPs to the application.

Under Websphere I do not observe this behavior, if the timestamp is
different (and not only older) then the JSP is recompiled.

I'm pretty surprised by this difference, can you confirm it to me ? Is there
any way to reload the JSP as soon as the modification timestamp changes, and
not only when it is older than the modification timestamp of the .class file
previouly generated ?

Thank you in advance.

Re: Tomcat 5.5/6 - JSP Reload

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sylvain,

On 4/7/2011 11:41 AM, Sylvain Goulmy wrote:
> Having spent some time trying to understand why when I deploy a new version
> of my JSP, it was not recompiled, I observe that in fact a new version is
> taken into account only if the modification timestamp of the new JSP (Linux
> Environment) is newer than the modification timestamp of the class generated
> for the JSP in the work directory.

Correct.

> If I change the modification timestamp of the JSP directly into the webapps
> directory with a command like:
> 
> touch-m-t 1104071423.16 BonjourResult.jsp
> 
> and set it to a newer value, it works very well.

Yup.

> The big problem is that this method of detection does not work for a
> rollback... You can of course do the cleaning at the work directory level
> but it is not at all adequate in terms of performance since it will force the
> recompilation of all the JSPs to the application.

Or, you could do your individual-file rollback and then 'touch' the file
again.

> Under Websphere I do not observe this behavior, if the timestamp is
> different (and not only older) then the JSP is recompiled.

Great.

> I'm pretty surprised by this difference, can you confirm it to me? Is there
> any way to reload the JSP as soon as the modification timestamp changes, and
> not only when it is older than the modification timestamp of the .class file
> previouly generated ?

Jasper simply checks the .class file (or .java file, depending on the
caller) against the .jsp file.

You could modify Jasper to change it's modification-time-checking logic.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2eEXMACgkQ9CaO5/Lv0PBiyACfR39D9g4u7kGOxAMk0yRGn0WI
o+8AoKhIN6iwozVR4erJYfk7ub0NBtbG
=Jv2y
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org