Behind that obscure title lies a problem that I recently had with Grails and that consumed half of my morning. The solution was rather simple but finding it was hard for me (although once it has happened once to you, I guess it is one of the ones that you won’t forget).

When rendering a certain template (no matter what controller, taglib or parent template invoked that rendering), I was getting an error like:

groovy.lang.MissingPropertyException: No such property: id for class: org.codehaus.groovy.grails.web.taglib.NamespacedTagDispatcher

The exception was being thrown when null-safely accessing a variable that was optional in the template model, so some renderings wouldn’t include it.

After a while, I discovered that NamespacedTagDispatcher is the class used to make all the taglibs namespaces available as objects in both controllers or views (so you can do but also ${g.message(…)}, and in the second case g would be an instance of NamespacedTagDispatcher).

After a bit of thinking I realized I recently included a new tablig whose namespace was exactly the same as the variable that was crashing. So when the variable was not passed as part of the model, instead of being null, it became a NamespacedTagDispatcher for invoking the tags contained in that taglib.

I don’t know if there’s a solution for preventing this (other than choosing very concrete namespaces), but this is yet another reason to avoid using views for other than coordinating taglibs invokations (no logic in the views at all). The way templates work right now, with model being implicitly spread to variables, and no “method signature”, is evil (666) .