Grails

Grails filters are not executed anymore when requesting the root (/)

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.2 final
  • Fix Version/s: 1.2.1
  • Component/s: None
  • Labels:
    None
  • Testcase included:
    yes

Description

When requesting the root of my project (eg, http://localhost:8080/mapper/), in Grails 1.1.1 my filters got executed, which are responsible for loading things from the database so that it's available in the Grails view. However, in Grails 1.2.0, the filter is not triggered anymore!

I've made two projects: mapper and mapper2.0. The mapper is a Grails 1.1.1 project, which prints a hello to the console for each request. The Mapper 2.0 does the same, but for some reason it's not triggered when requesting /, and therefore doesn't print 'hello'.

I hope this can be fixed, though a workaround would also be quite welcome for now!

Issue Links

Activity

Hide
Jean-Noël Rivasseau added a comment - - edited

I can confirm this. This does not happen only in the root but in any URL where there is no action (so for a controller that has a defaultAction that triggers too).

Any filter with controller: "foo" and action: "*" in the rule will exhibit this.

It also does not work with any kind of regexp, even ".*"

This is IMHO a serious regression from and cause troubles for people upgrading (the new regexp syntax for filters is cool though
I suspect the bug comes from the fact that there is a test on actionName which is null or empty on this case.

Workaround: I got it working by switching to uri: /foo/**" in my case.

Show
Jean-Noël Rivasseau added a comment - - edited I can confirm this. This does not happen only in the root but in any URL where there is no action (so for a controller that has a defaultAction that triggers too). Any filter with controller: "foo" and action: "*" in the rule will exhibit this. It also does not work with any kind of regexp, even ".*" This is IMHO a serious regression from and cause troubles for people upgrading (the new regexp syntax for filters is cool though I suspect the bug comes from the fact that there is a test on actionName which is null or empty on this case. Workaround: I got it working by switching to uri: /foo/**" in my case.
Hide
Jeff Brown added a comment -

Erik,

In your original note you ask for a workaround. You could create a filter with a uri attribute like this:

grails-app/conf/ExampleFilters.groovy
class ExampleFilters {
   def filters = {
      sampleFilter(uri:'/') {
           before = {
              println 'hello'
           }
      }
   }
}
Show
Jeff Brown added a comment - Erik, In your original note you ask for a workaround. You could create a filter with a uri attribute like this:
grails-app/conf/ExampleFilters.groovy
class ExampleFilters {
   def filters = {
      sampleFilter(uri:'/') {
           before = {
              println 'hello'
           }
      }
   }
}
Hide
Jean-Noël Rivasseau added a comment -

Yes, although the workaround is not always possible. I realized that in my case it was not possible, mainly due to the fact that uri does not seem to support the regular expression syntax, and I have a relatively complex URL setup to support locales in the URL.

Show
Jean-Noël Rivasseau added a comment - Yes, although the workaround is not always possible. I realized that in my case it was not possible, mainly due to the fact that uri does not seem to support the regular expression syntax, and I have a relatively complex URL setup to support locales in the URL.
Hide
Erik Pragt added a comment - - edited

Ah, thanks, I'll try that out! I think it will work in my case since the problem I have is quite simple (retrieve some data on every call to /).

Show
Erik Pragt added a comment - - edited Ah, thanks, I'll try that out! I think it will work in my case since the problem I have is quite simple (retrieve some data on every call to /).
Hide
Jeff Brown added a comment -

Another thing to note... If you add a url mapping which maps '/' to a controller action, your filters should work.

Show
Jeff Brown added a comment - Another thing to note... If you add a url mapping which maps '/' to a controller action, your filters should work.
Hide
Jeff Brown added a comment -

Jean-Noël,

I think the uri pattern does currently support ant style paths like '/*' and '/demo/'. Does that help with your situation?

Show
Jeff Brown added a comment - Jean-Noël, I think the uri pattern does currently support ant style paths like '/*' and '/demo/'. Does that help with your situation?
Hide
Jeff Brown added a comment -

Part of this issue is related to GRAILS-5609 which relates to filters not executing for default controller actions.

Show
Jeff Brown added a comment - Part of this issue is related to GRAILS-5609 which relates to filters not executing for default controller actions.
Hide
Jean-Noël Rivasseau added a comment -

Hi,

I am not really sure what you meant with ant style paths like '/*' and '/demo/' since again the double star messed up the formatting. I think in my case it would not help (I need to catch all URIs of the form /{localeCode}/demo/** but localeCode is optional so it can be just demo/**

By the way please reopen this bug. I looked at your fix but this will only fix the OP problem eg when accessing the root of the app. As I mentionned the problem is much wider:

any URL which will result in not having an actionName will cause problems. For instance /demo/ if you have DemoController and def defaultAction = main. This wont be catch by a filter.

Show
Jean-Noël Rivasseau added a comment - Hi, I am not really sure what you meant with ant style paths like '/*' and '/demo/' since again the double star messed up the formatting. I think in my case it would not help (I need to catch all URIs of the form /{localeCode}/demo/** but localeCode is optional so it can be just demo/** By the way please reopen this bug. I looked at your fix but this will only fix the OP problem eg when accessing the root of the app. As I mentionned the problem is much wider: any URL which will result in not having an actionName will cause problems. For instance /demo/ if you have DemoController and def defaultAction = main. This wont be catch by a filter.
Hide
Tim Reilly added a comment -

Please reopen. I'm seeing this in 1.2.1 too.

In my environment a filter for "/**" does not execute on a direct call to any /foo.gsp page, however it does execute on a call to a controller.

Show
Tim Reilly added a comment - Please reopen. I'm seeing this in 1.2.1 too. In my environment a filter for "/**" does not execute on a direct call to any /foo.gsp page, however it does execute on a call to a controller.
Hide
Jeff Brown added a comment -

Tim,

I don't think this issue should be re-opened. I do think that the original issue has been resolved. The mapper2 application that the original poster attached does work with 1.2.1. I think the defaultAction thing that Jean mentions is resolved.

You may be seeing a different issue related to filters. If you want to create a simple demonstrative app and attach it to a new issue, we can investigate that. If you do that, feel free to link that issue as related to this one. Thanks for your help.

Show
Jeff Brown added a comment - Tim, I don't think this issue should be re-opened. I do think that the original issue has been resolved. The mapper2 application that the original poster attached does work with 1.2.1. I think the defaultAction thing that Jean mentions is resolved. You may be seeing a different issue related to filters. If you want to create a simple demonstrative app and attach it to a new issue, we can investigate that. If you do that, feel free to link that issue as related to this one. Thanks for your help.
Hide
Jeff Brown added a comment -

Jean-Noël,

I think that the defaultAction issue was resolved as part of GRAILS-5609.

Show
Jeff Brown added a comment - Jean-Noël, I think that the defaultAction issue was resolved as part of GRAILS-5609.
Hide
Tim Reilly added a comment -

Jeff,

Please see a new JIRA filed here: http://jira.codehaus.org/browse/GRAILS-5952

I will be the first to admit that this may be due to user error.

Once again, a thousand thanks for your help with this issue and others.

Show
Tim Reilly added a comment - Jeff, Please see a new JIRA filed here: http://jira.codehaus.org/browse/GRAILS-5952 I will be the first to admit that this may be due to user error. Once again, a thousand thanks for your help with this issue and others.

People

Vote (1)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: