Problem with code fragment evaluator in Grails Debugger

Which Groovy/Grails version do you use?

I am using Grails 1.0.4. It has the groovy 1.5.6 library in its lib directory.

I am also using the Groovy2.zip plugin posted in issue GRVY-2041

Does this happen on any script in any place? Does your content contain
class/variable/property/method named 'res'? Could you provide a script
sample where this error happens?

Hi Peter,

I will try to create a basic project to help work out this issue after I am done with my workday. Here is what is weird to me, I don't have a variable named 'res' in my project that I can find. I will grovel through the general search results later to verify. The issue is that even if I had a variable named 'res' not defined somewhere, how does that make 1 + 1 not evaluate?

-Reggie

Hi Peter,

I found where the problem is, I just don't know how to fix it. My coworker wrote a grails plugin to cache headers for static resource files. He calls it 'jperf'. It lives under plugins/jperf-0.5. In this plugin, he implements a CacheFilter class and made a method doFilter that hooks in at the servlet layer. My knowledge does not extend that far into the servlet API(yet). The doFilter method has 'res' as one of its arguments. Now here is the interesting part. If I set a breakpoint on this method and load a page to stop here, I can execute expressions in the code fragment evaluator. But if I stop in a grails controller, I get the 'res' error mentioned above.

I created a test grails project and in that project the code fragment evaluator works just fine. I put a partial listing of the CacheFilter below with the doFilter method. Hopefully, this is enough to debug the problem.







/**
* CacheFilter - Controls cache headers for static resource files
* This filter will set a far future expires header if the request is for one
* of the enabled file extensions and if the request contains the jPerf
* query string parameter.
*
* Configuration options:
*     jperf.enabled    - Determines if cache control is enabled
*                        (default: true for war deployments, false otherwise)
*     jperf.cache-time - Time in seconds to cache
*                        (default: 1 year)
*     jperf.extensions - The file extensions to enable cache control for
*                        (default: js, css, gif, jpg, png)
*/
public class CacheFilter implements Filter {

private static final int ONE_YEAR_SECONDS = 60 * 60 * 24 * 365;

private boolean enabled;
private int cacheTime;
private List<String> extensions;
private static final List<String> DEFAULT_EXTENSIONS = Arrays.asList(new String[] { "js", "css", "gif", "jpg", "png" });

public void doFilter(ServletRequest req, ServletResponse res,
               FilterChain chain) throws IOException, ServletException {

     HttpServletRequest request = (HttpServletRequest) req;
     HttpServletResponse response = (HttpServletResponse) res;
     String uri = request.getRequestURI();

     if (enabled && isCacheable(request)) {

          response.setDateHeader("Expires", System.currentTimeMillis()
               + (cacheTime * 1000));
          response.setHeader("Cache-Control", "max-age=" + cacheTime);

          if (uri.endsWith(".gz.css") || uri.endsWith(".gz.js")) {
               response.addHeader("Content-Encoding", "gzip");
          }
     }

     chain.doFilter(req, res);
}

...

}                                                                               

Hi Peter. Here is the latest update. It turns out that I get this error in the debugger only in a particular controller. If I set my breakpoint in that controller, then I cannot evaluate code fragments. If I set my breakpoint in another controller or some Java code, the evaluator works fine.

If you have some suggestions on how to narrow this down, that would be great. Otherwise, when I get some free time, I will remove blocks of code until it works and then figure out what's so special about that code.

Would be most great if you send me some project where this happens. I've
encountered it myself but then I wasn't able to reproduce. Unfortunately.