8 Debugging

Usually these are due to incorrect dependencies in your modules, but you may also have actual bugs in your JS or CSS.

When you're using mappers that completely rename or aggregate files, it can be hard to tell where the problem lies.

There are a number of features in Resources that make it easier to debug such issues.

First: Get familiar with your browser's resource inspector. All modern browsers have a developer mode which lets you inspect the resources loaded by a page - including the request and response headers and the content itself. This is indispensable. For Safari you need to explicitly turn this on. For Firefox you may need to install firebug.

The custom response header

Every resource served by the plugin in development mode adds the X-Grails-Resources-Original-Src header to all resources served.

The value shows you the original filename of the resource. In the case of bundled resources, the first part is the bundle name, and then follow all the names of the resources appended to the file, in the order they appear.

The quick debug option - turn off processing for the current request

Any URL in your application can have the query parameter _debugResources=y added to it, and the request will perform no processing. So for example if you are browsing http://localhost:8080/myapp/admin and need to bypass resources, just change the URL in your browser to http://localhost:8080/myapp/admin?_debugResources=y

Dependency management will still be in effect (otherwise your app would break) but the resources will not be bundled or have other mappers applied. Resources will be served with a timestamp - this allows you to set breakpoints on resources and yet also force a refresh in your browser if you find that your browser still caches resources even after you have edited them and no caching headers are set. If this occurs, you can force a timestamp refresh by adding _refreshResources=y to the query params.

The nuclear debug option - turn on resource debugging all the time

You can turn off resource processing completely with the trivial Config variable, so that it is as if every request you make has _debugResources=y appended to it:

grails.resources.debug = true

You can specify this value per-environment in your Config.

Inspecting your dependency data

A utility function in the grailsResourceProcessor bean can be used to output the current resource metadata that the plugin has - all the modules and resources and their dependencies.

Simply add a "println grailsResourceProcessor.dumpResources()" somewhere in your application or GSP and it will come out.

Turning on debug logging

There are copious amounts of debug logging output by the plugin that should make it relatively easy to track down problems. This information includes the order of mapper execution that will be used, the dependency order of your resource module definitions, and all the steps of processing each resource.

To enable debug logging add this to your Config logging section:

debug "org.grails.plugin.resource"