I looked into it and this issue is still there and hasn't benefited from
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