Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.6.4
-
Fix Version/s: 1.7-rc-1
-
Component/s: Compiler, Groovlet / GSP
-
Labels:None
-
Environment:Linux Ubuntu 8.04.3 LTS, Kernel 2.6.24-16-virtual, JVM 1.6.0_14-b08, Apache Tomcat 6.0.20
-
Number of attachments :
Description
If you change file b.groovy which is used by a.groovy, file b.groovy is not recompiled. Both files are in the same (root) directory of a web application.
Example:
a.groovy
println "<html><body>"; println "a: test<br/>"; def b = new b(); println b.test(); println "</body></html>";
b.groovy
public class b { def String test() { return "b: test<br/>"; } }
Calling a.groovy by a URL like this http://localhost:8080/groovy/a.groovy will show this output:
a: test b: test
If in file b.groovy the return value is changed to "b: test2<br/>" you will not see the change when calling a.groovy again.
Issue Links
- is related to
-
GROOVY-2212
Cannot load the class method after updated, failed after 1.1
-
Activity
I looked into it and this issue is still there and hasn't benefited from GROOVY-3888.
GROOVY-3888 has only removed the 404 issue mentioned above and allowed the original problem to surface with 1.7-rc too. The original issue is there because of the GSE#isSourceNewer() logic, which I doubt was tested with Tomcat (which has different behavior from Jetty, for which it works).
So, the issue is that when a script, say '/a.groovy' is accessed for 2nd time and control comes in GSE#isSourceNewer(), it does the following to get the current timestamp of the script so it can compare it with previously cached timestamp (when it last compiled it):
URLConnection conn = rc.getResourceConnection("/a.groovy"); File file = new File(conn.getURL().getPath()); long lastMod = file.lastModified();
Now the problem is that Jetty and Tomcat behave differently with these URL paths. While Jetty gives back URL as file:/C:/jetty-6.0.1/webapps/g3702/a.groovy (full, real path), tomcat gives it back as "jndi:/localhost/g3702/a.groovy" (a logical path)
Because Tomcat's is a logical path, file.exists() is always false and file.lastModified() always 0, so it doesn't pick up the newer timestamp (which is only available through a real file, that exists).
I couldn't think of a clean solution to get the real path back from AbstractHttpServlet in addition to the URLConnection because call is made through groovy.util.ResourceConnector, which is on the public API, and it didn't want to pollute it with something hackish.
It's 2 AM here now. If someone wants to take it further, it's welcomed 
GROOVY-3702 and GROOVY-2212 are both failing on 1.6.6 - on both Jetty and Tomcat - both having the same issue - that if a.groovy depends on b.groovy and
1) if a.groovy changes on the fly, its changes are seen
2) if b.groovy changes, a.groovy is not re-compiled (as it does in trunk considering that one of files that it depends upon - b.groovy - has changed)
But to achieve this, I guess, the whole trunk's version of GSE has to be ported back before my tiny fixes will have any effect
Let me know what is the call on that? Do we want to port it and have this dependency management logic available in 1.6.6 as well? Or is it a feature that groovy will have from 1.7-rc-1 onwards and ot earlier?
I just tested this with several groovy-jars (1.6.4, 1.6.3, 1.6.2, 1.6.1, 1.5.4, 1.5.1) and on another Linux host (Ubuntu 8.04.3 LTS, Kernel 2.6.24-22-server) with JVM 1.6.0_07-b06 and Tomcat 6.0.14. The result is the same.