Should grails filters be invoked twice in this instance?

[Kim Eik]

According to this mailinglist entry, grails filters should be invoked on a forward. which effectively causes filters to be invoked 1 + x number of forwards.

However, in my situation i question the method of how this is done. Here is a rough mashup of my system:

• i have a filter which is invoked on the uri condition of "/api/**"
• an urlmapping that goes something like this: "/api/$version/$apiKey/$rest**"
  • $rest may contain (as an example) the value /book/show/1
• an ApiController thats sole purpose is to forward to another uri depending on $rest

So lets say i access the url /api/0.1/Ks38...7fn38/book/show/1 what then happens is that the api filter is invoked and it does all the version and apiKey validatation. it then continues to forward to the uri /book/show/1 which then invokes the Api filter a second time even though the filter is mapped up agains /api/** and the new uri is effectively /book/.... Now let it be said, i agree that filters should be invoked on a forward, but i dont agree that the api filter should be invoked a second time when i am doing a forward to /book...

This can't be correct behaviour? can it?

I have originally asked this question on stackoverflow, i hope you don't mind that i duplicate this question to the mailinglist as i feel like this is something that needs attention.

http://stackoverflow.com/questions/6205422/should-grails-filters-run-twice-on-forward-in-this-instance

[Jeff Scott Brown]

On Wed, Jun 1, 2011 at 1:03 PM, Kim Eik <[hidden email]> wrote:

> According to this mailinglist entry, grails filters should be invoked on a
> forward. which effectively causes filters to be invoked 1 + x number of
> forwards.
>
> However, in my situation i question the method of how this is done. Here is
> a rough mashup of my system:
>
> i have a filter which is invoked on the uri condition of "/api/**"
> an urlmapping that goes something like this: "/api/$version/$apiKey/$rest**"
>
> $rest may contain (as an example) the value /book/show/1
>
> an ApiController thats sole purpose is to forward to another uri depending
> on $rest
>
> So lets say i access the url /api/0.1/Ks38...7fn38/book/show/1 what then
> happens is that the api filter is invoked and it does all the version and
> apiKey validatation. it then continues to forward to the uri /book/show/1
> which then invokes the Api filter a second time even though the filter is
> mapped up agains /api/** and the new uri is effectively /book/.... Now let
> it be said, i agree that filters should be invoked on a forward, but i dont
> agree that the api filter should be invoked a second time when i am doing a
> forward to /book...
>
> This can't be correct behaviour? can it?
>
> I have originally asked this question on stackoverflow, i hope you don't
> mind that i duplicate this question to the mailinglist as i feel like this
> is something that needs attention.
>
> http://stackoverflow.com/questions/6205422/should-grails-filters-run-twice-on-forward-in-this-instance
>

I _think_, based on that description that this is probably a bug.  If
you would, please file a JIRA.  Attaching a simple demonstrative
sample app would be helpful.  Also, make mention in the description
that this is really not the same thing reported under
http://jira.grails.org/browse/GRAILS-6075.

Thanks for your help.



jb
--
Jeff Brown
SpringSource
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Kim Eik]

Bug created at http://jira.grails.org/browse/GRAILS-7579 and sample appliaction is embedded. This bug is affecting me in a really bad way at the moment :( is there a chance this might work on grails 1.4m1?

On Wed, Jun 1, 2011 at 8:18 PM, Jeff Brown <[hidden email]> wrote:

On Wed, Jun 1, 2011 at 1:03 PM, Kim Eik <[hidden email]> wrote:
> According to this mailinglist entry, grails filters should be invoked on a
> forward. which effectively causes filters to be invoked 1 + x number of
> forwards.
>
> However, in my situation i question the method of how this is done. Here is
> a rough mashup of my system:
>
> i have a filter which is invoked on the uri condition of "/api/**"
> an urlmapping that goes something like this: "/api/$version/$apiKey/$rest**"
>
> $rest may contain (as an example) the value /book/show/1
>
> an ApiController thats sole purpose is to forward to another uri depending
> on $rest
>
> So lets say i access the url /api/0.1/Ks38...7fn38/book/show/1 what then
> happens is that the api filter is invoked and it does all the version and
> apiKey validatation. it then continues to forward to the uri /book/show/1
> which then invokes the Api filter a second time even though the filter is
> mapped up agains /api/** and the new uri is effectively /book/.... Now let
> it be said, i agree that filters should be invoked on a forward, but i dont
> agree that the api filter should be invoked a second time when i am doing a
> forward to /book...
>
> This can't be correct behaviour? can it?
>
> I have originally asked this question on stackoverflow, i hope you don't
> mind that i duplicate this question to the mailinglist as i feel like this
> is something that needs attention.
>
> http://stackoverflow.com/questions/6205422/should-grails-filters-run-twice-on-forward-in-this-instance
>

I _think_, based on that description that this is probably a bug.  If
you would, please file a JIRA.  Attaching a simple demonstrative
sample app would be helpful.  Also, make mention in the description
that this is really not the same thing reported under
http://jira.grails.org/browse/GRAILS-6075.

Thanks for your help.



jb
--
Jeff Brown
SpringSource
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email