Bug 45403 - Tomcat does not reload application
Tomcat does not reload application
Status: RESOLVED FIXED
Product: Tomcat 6
Classification: Unclassified
Component: Catalina
6.0.16
Sun Solaris
: P2 normal (vote)
: default
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2008-07-15 18:39 UTC by kawasima
Modified: 2009-09-07 07:50 UTC (History)
0 users



Attachments
With this patch, "Tomcat" does not load the jar file of Symbolic Link, when "allowLinking" is "false". (1.36 KB, patch)
2008-08-24 23:53 UTC, kawasima
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description kawasima 2008-07-15 18:39:38 UTC
Tomcat does not reload application if
 1)a file in WEB-INF/lib is a symbolic link file, and
 2)the actual file of the symbolic link file changed, and
 3)allowLinking attribute is false

In case of the above, Tomcat throws a NamingException.
Application reloading works well if allowLinking attribute is set to true.
The reason of the above would be as allows.

--------------------
WebappClassLoader:addJar

  long lastModified =
      ((ResourceAttributes) resources.getAttributes(jar))
       .getLastModified();
--------------------


I was wondering if application reloading should work when allowLinking attribute
is false.
Or should Tomcat disregard the Jar (doesn't load it)
when "allowLinking=false"?
Comment 1 kawasima 2008-07-15 19:25:17 UTC
When allowlinging attribute is false, application can load class in jar file.

But, when the actual file of the symbolic link file changed,
tomcat does not reload application.

It is contradictory.
Comment 2 kawasima 2008-08-24 23:53:51 UTC
Created attachment 22478 [details]
With this patch, "Tomcat" does not load the jar file of Symbolic Link, when "allowLinking" is "false".

With this patch, "Tomcat" does not load the jar file 
of Symbolic Link, when "allowLinking" is "false".
Comment 3 kawasima 2008-08-25 00:26:56 UTC
There was a problem in this patch(22478).
Please ignore this patch.
Comment 4 Mark Thomas 2008-10-01 07:34:41 UTC
This has been fixed in trunk and proposed for 6.0.x
Comment 5 Mark Thomas 2009-08-15 05:06:47 UTC
The proposed patch failed to obtain the required votes. A new patch has been applied to trunk and proposed.
Comment 6 Mark Thomas 2009-09-07 07:50:42 UTC
The fix has been applied to 6.0.x and will be included in 6.0.21 onwards.