404 - UrlMappings, Tomcat

[BrockHeinz]

Hello All,

When mapping a 404 handler in my UrlMappings.groovy file, the handler
is invoked properly in Jetty, but not in Tomcat (5.5.25).  Has anyone
else seen this with Tomcat?

Here is a related thread:
http://www.nabble.com/problem-redirecting-to-error-pages-for-500-and-404-errors-td18075267.html

Baha, did you resolve the issue?  Were you using Tomcat?

- Here is my UrlMappings.groovy file:

class UrlMappings {
    static mappings = {
      "/$controller/$action?/$id?"{
              constraints {
                         // apply constraints here
                  }
          }
          "500"(view:'/error')
          "404"(controller: "system", action: "notfound")
        }
}

- My SystemController.groovy:
class SystemController {
    def notfound = {
        render "404"
    }
}

- I'm using grails 1.0.3

- Stack observed in Tomcat's console (even though I still see the
default 404 error page):
[37444] [/testing].[grails-errorhandler] Servlet.service() for servlet
grails-errorhandler threw exception
java.lang.IllegalStateException: No thread-bound request found: Are
you referring to request attributes outside of an actual web request,
or processing a request outside of the originally receiving thread? If
you are actually operating within a web request and still receive this
message, your code is probably running outside of
DispatcherServlet/DispatcherPortlet: In this case, use
RequestContextListener or RequestContextFilter to expose the current
request.
        at org.springframework.web.context.request.RequestContextHolder.currentRequestAttributes(RequestContextHolder.java:121)
        at org.codehaus.groovy.grails.web.util.WebUtils.retrieveGrailsWebRequest(WebUtils.java:247)
        at org.codehaus.groovy.grails.web.servlet.ErrorHandlingServlet.doDispatch(ErrorHandlingServlet.java:64)
        at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
        at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
        at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:691)
        at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:471)
        at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:403)
        at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
        at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:364)
        at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:285)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
        at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
        at java.lang.Thread.run(Thread.java:613)

Any ideas?

Thanks,
Brock

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

    http://xircles.codehaus.org/manage_email

[BrockHeinz]

I tried deploying the grails built WAR to Apache Tomcat/6.0.16...
still not working :(

Brock


On Tue, Jul 8, 2008 at 4:52 PM, Brock Heinz <brock.heinz@...> wrote:

> Hello All,
>
> When mapping a 404 handler in my UrlMappings.groovy file, the handler
> is invoked properly in Jetty, but not in Tomcat (5.5.25).  Has anyone
> else seen this with Tomcat?
>
> Here is a related thread:
> http://www.nabble.com/problem-redirecting-to-error-pages-for-500-and-404-errors-td18075267.html
>
> Baha, did you resolve the issue?  Were you using Tomcat?
>
> - Here is my UrlMappings.groovy file:
>
> class UrlMappings {
>    static mappings = {
>      "/$controller/$action?/$id?"{
>              constraints {
>                         // apply constraints here
>                  }
>          }
>          "500"(view:'/error')
>          "404"(controller: "system", action: "notfound")
>        }
> }
>
> - My SystemController.groovy:
> class SystemController {
>    def notfound = {
>        render "404"
>    }
> }
>
> - I'm using grails 1.0.3
>
> - Stack observed in Tomcat's console (even though I still see the
> default 404 error page):
> [37444] [/testing].[grails-errorhandler] Servlet.service() for servlet
> grails-errorhandler threw exception
> java.lang.IllegalStateException: No thread-bound request found: Are
> you referring to request attributes outside of an actual web request,
> or processing a request outside of the originally receiving thread? If
> you are actually operating within a web request and still receive this
> message, your code is probably running outside of
> DispatcherServlet/DispatcherPortlet: In this case, use
> RequestContextListener or RequestContextFilter to expose the current
> request.
>        at org.springframework.web.context.request.RequestContextHolder.currentRequestAttributes(RequestContextHolder.java:121)
>        at org.codehaus.groovy.grails.web.util.WebUtils.retrieveGrailsWebRequest(WebUtils.java:247)
>        at org.codehaus.groovy.grails.web.servlet.ErrorHandlingServlet.doDispatch(ErrorHandlingServlet.java:64)
>        at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
>        at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
>        at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:691)
>        at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:471)
>        at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:403)
>        at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
>        at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:364)
>        at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:285)
>        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
>        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
>        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
>        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
>        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
>        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
>        at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
>        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
>        at java.lang.Thread.run(Thread.java:613)
>
> Any ideas?
>
> Thanks,
> Brock
>

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

    http://xircles.codehaus.org/manage_email

[BrockHeinz]

I dunno how the UrlMappings are configured for grails.org, but there
is no 404 handler working there either:

http://grails.org/wontfindme

Brock



On Tue, Jul 8, 2008 at 7:20 PM, Brock Heinz <brock.heinz@...> wrote:

> I tried deploying the grails built WAR to Apache Tomcat/6.0.16...
> still not working :(
>
> Brock
>
>
> On Tue, Jul 8, 2008 at 4:52 PM, Brock Heinz <brock.heinz@...> wrote:
>> Hello All,
>>
>> When mapping a 404 handler in my UrlMappings.groovy file, the handler
>> is invoked properly in Jetty, but not in Tomcat (5.5.25).  Has anyone
>> else seen this with Tomcat?
>>
>> Here is a related thread:
>> http://www.nabble.com/problem-redirecting-to-error-pages-for-500-and-404-errors-td18075267.html
>>
>> Baha, did you resolve the issue?  Were you using Tomcat?
>>
>> - Here is my UrlMappings.groovy file:
>>
>> class UrlMappings {
>>    static mappings = {
>>      "/$controller/$action?/$id?"{
>>              constraints {
>>                         // apply constraints here
>>                  }
>>          }
>>          "500"(view:'/error')
>>          "404"(controller: "system", action: "notfound")
>>        }
>> }
>>
>> - My SystemController.groovy:
>> class SystemController {
>>    def notfound = {
>>        render "404"
>>    }
>> }
>>
>> - I'm using grails 1.0.3
>>
>> - Stack observed in Tomcat's console (even though I still see the
>> default 404 error page):
>> [37444] [/testing].[grails-errorhandler] Servlet.service() for servlet
>> grails-errorhandler threw exception
>> java.lang.IllegalStateException: No thread-bound request found: Are
>> you referring to request attributes outside of an actual web request,
>> or processing a request outside of the originally receiving thread? If
>> you are actually operating within a web request and still receive this
>> message, your code is probably running outside of
>> DispatcherServlet/DispatcherPortlet: In this case, use
>> RequestContextListener or RequestContextFilter to expose the current
>> request.
>>        at org.springframework.web.context.request.RequestContextHolder.currentRequestAttributes(RequestContextHolder.java:121)
>>        at org.codehaus.groovy.grails.web.util.WebUtils.retrieveGrailsWebRequest(WebUtils.java:247)
>>        at org.codehaus.groovy.grails.web.servlet.ErrorHandlingServlet.doDispatch(ErrorHandlingServlet.java:64)
>>        at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
>>        at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
>>        at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:501)
>>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
>>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
>>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
>>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
>>        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:691)
>>        at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:471)
>>        at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:403)
>>        at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
>>        at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:364)
>>        at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java:285)
>>        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
>>        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>>        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
>>        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
>>        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
>>        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
>>        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
>>        at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
>>        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
>>        at java.lang.Thread.run(Thread.java:613)
>>
>> Any ideas?
>>
>> Thanks,
>> Brock
>>
>

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

    http://xircles.codehaus.org/manage_email

[baha007]

Hi Brock,

the redirection of the 404 seems to work on both the default Jetty and tomcat servers I have for the exception of the rendering of the 'not found' page which is not properly done on a missing page event as I mentioned in my previous post.

I do suggest that you create a separate page and render it in your action instead of rendering 404, ie replace:
render "404"
by
render(view: "notFound")
and create a gsp file called 'notFound.gsp'

this should work. As for rendering the page, I do not know why the rendering is not done properly.
In my case, when I point to my not found page directly, the server properly renders the layout definition defined in my gsp but when I try to access a page that doesn't exist ie www.myGrailsDomain.com/myAppContext/somePagethatdontexist, the layout is not rendered anymore.

This is my latest finding about the 404 error issue.

regards,

Baha

BrockHeinz wrote:

I dunno how the UrlMappings are configured for grails.org, but there
is no 404 handler working there either:

http://grails.org/wontfindme

Brock

[BrockHeinz]

Baha,

Thanks for the feedback.  I'm 99% this is a Grails bug in relation to
Tomcat.  I've put together a quick experiment that validates why I
think it's a bug.  I've done the following:

1) Reverted back to Grails 1.0.2

2) Created a trivial application that isolates the 404 behavior

3) Coded an 'errors' handler which the docs exhibit as seen here
http://grails.org/doc/1.0.x/guide/6.%20The%20Web%20Layer.html#6.4.4%20Mapping%20to%20Response%20Codes

class ErrorsController {
def index = { render "Action: $actionName" }
def notFound = { render "Action: $actionName" }
}

4) Followed the UrlMapping exactly as shown in the Grails docs here
http://grails.org/doc/1.0.x/guide/6.%20The%20Web%20Layer.html#6.4.4%20Mapping%20to%20Response%20Codes

class UrlMappings {
    static mappings = {
      "/$controller/$action?/$id?"{
              constraints {
                         // apply constraints here
                  }
          }
          "500"(view:'/error')
          "404"(controller:"errors", action:"notFound")
     }
}

5) Test in Jetty (>grails run-app) by invoking
http://localhost:8080/err/wontfindme.  The test works as expected and
my 'notFound' action is invoked.

6) Packaged the war (>grails dev war) and deploy to Tomcat (5.5.25)

7) Test in Tomcat by invoking http://localhost:8080/err/wontfindme.
Again, the test works.

8) Upgrade grails to 1.0.3 (>grails upgrade)

9) Test in Jetty again.  Again, the test works.

10) Package war and deploy to tomcat again.

11) Test URL again in Tomcat (http://localhost:8080/err/wontfindme).
Test FAILS.  I'm greeted with Tomcat's default 404 page :(

I'm tired of opening JIRAs and waiting (this statement isn't a knock
on the Grails developers, just my own frustration with my thus-far
reluctance to really dive head first into the Grails source)... I
think I'm going to create a patch for this one.

I'll follow up with the JIRA that I create and I'll be sure to post
the test Grails application I used in the experiment.

Brock



On Wed, Jul 9, 2008 at 12:15 PM, baha007 <baha007@...> wrote:

>
> Hi Brock,
>
> the redirection of the 404 seems to work on both the default Jetty and
> tomcat servers I have for the exception of the rendering of the 'not found'
> page which is not properly done on a missing page event as I mentioned in my
> previous post.
>
> I do suggest that you create a separate page and render it in your action
> instead of rendering 404, ie replace:
> render "404"
> by
> render(view: "notFound")
> and create a gsp file called 'notFound.gsp'
>
> this should work. As for rendering the page, I do not know why the rendering
> is not done properly.
> In my case, when I point to my not found page directly, the server properly
> renders the layout definition defined in my gsp but when I try to access a
> page that doesn't exist ie
> www.myGrailsDomain.com/myAppContext/somePagethatdontexist, the layout is not
> rendered anymore.
>
> This is my latest finding about the 404 error issue.
>
> regards,
>
> Baha
>
>
>
> BrockHeinz wrote:
>>
>> I dunno how the UrlMappings are configured for grails.org, but there
>> is no 404 handler working there either:
>>
>> http://grails.org/wontfindme
>>
>> Brock
>>
>>
>>
> --
> View this message in context: http://www.nabble.com/404---UrlMappings%2C-Tomcat-tp18349963p18366566.html
> Sent from the grails - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email

[BrockHeinz]

http://jira.codehaus.org/browse/GRAILS-3219


On Wed, Jul 9, 2008 at 3:01 PM, Brock Heinz <brock.heinz@...> wrote:

> Baha,
>
> Thanks for the feedback.  I'm 99% this is a Grails bug in relation to
> Tomcat.  I've put together a quick experiment that validates why I
> think it's a bug.  I've done the following:
>
> 1) Reverted back to Grails 1.0.2
>
> 2) Created a trivial application that isolates the 404 behavior
>
> 3) Coded an 'errors' handler which the docs exhibit as seen here
> http://grails.org/doc/1.0.x/guide/6.%20The%20Web%20Layer.html#6.4.4%20Mapping%20to%20Response%20Codes
>
> class ErrorsController {
> def index = { render "Action: $actionName" }
> def notFound = { render "Action: $actionName" }
> }
>
> 4) Followed the UrlMapping exactly as shown in the Grails docs here
> http://grails.org/doc/1.0.x/guide/6.%20The%20Web%20Layer.html#6.4.4%20Mapping%20to%20Response%20Codes
>
> class UrlMappings {
>    static mappings = {
>      "/$controller/$action?/$id?"{
>              constraints {
>                         // apply constraints here
>                  }
>          }
>          "500"(view:'/error')
>          "404"(controller:"errors", action:"notFound")
>     }
> }
>
> 5) Test in Jetty (>grails run-app) by invoking
> http://localhost:8080/err/wontfindme.  The test works as expected and
> my 'notFound' action is invoked.
>
> 6) Packaged the war (>grails dev war) and deploy to Tomcat (5.5.25)
>
> 7) Test in Tomcat by invoking http://localhost:8080/err/wontfindme.
> Again, the test works.
>
> 8) Upgrade grails to 1.0.3 (>grails upgrade)
>
> 9) Test in Jetty again.  Again, the test works.
>
> 10) Package war and deploy to tomcat again.
>
> 11) Test URL again in Tomcat (http://localhost:8080/err/wontfindme).
> Test FAILS.  I'm greeted with Tomcat's default 404 page :(
>
> I'm tired of opening JIRAs and waiting (this statement isn't a knock
> on the Grails developers, just my own frustration with my thus-far
> reluctance to really dive head first into the Grails source)... I
> think I'm going to create a patch for this one.
>
> I'll follow up with the JIRA that I create and I'll be sure to post
> the test Grails application I used in the experiment.
>
> Brock
>
>
>
> On Wed, Jul 9, 2008 at 12:15 PM, baha007 <baha007@...> wrote:
>>
>> Hi Brock,
>>
>> the redirection of the 404 seems to work on both the default Jetty and
>> tomcat servers I have for the exception of the rendering of the 'not found'
>> page which is not properly done on a missing page event as I mentioned in my
>> previous post.
>>
>> I do suggest that you create a separate page and render it in your action
>> instead of rendering 404, ie replace:
>> render "404"
>> by
>> render(view: "notFound")
>> and create a gsp file called 'notFound.gsp'
>>
>> this should work. As for rendering the page, I do not know why the rendering
>> is not done properly.
>> In my case, when I point to my not found page directly, the server properly
>> renders the layout definition defined in my gsp but when I try to access a
>> page that doesn't exist ie
>> www.myGrailsDomain.com/myAppContext/somePagethatdontexist, the layout is not
>> rendered anymore.
>>
>> This is my latest finding about the 404 error issue.
>>
>> regards,
>>
>> Baha
>>
>>
>>
>> BrockHeinz wrote:
>>>
>>> I dunno how the UrlMappings are configured for grails.org, but there
>>> is no 404 handler working there either:
>>>
>>> http://grails.org/wontfindme
>>>
>>> Brock
>>>
>>>
>>>
>> --
>> View this message in context: http://www.nabble.com/404---UrlMappings%2C-Tomcat-tp18349963p18366566.html
>> Sent from the grails - user mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>

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

    http://xircles.codehaus.org/manage_email

[BrockHeinz]

After a bit more investigation, I think I found the root of the
problem, and it resides in the
GrailsWebRequestFilter.doFilterInternal() method's 'finally' block.
Within that finally block, the request is marked as completed, and any
thread bound attributes are removed.

In the embedded version of Jetty that ships with Grails, the finally
block in the GrailsWebRequestFilter.doFilterInternal() method is
invoked AFTER the ErrorHandlingServlet.doDispatch() method is called.
In Tomcat, the finally block in the
GrailsWebRequestFilter.doFilterInternal() method is called BEFORE
invocation of the ErrorHandlingServlet.doDispatch() error handler.

I'm guessing there is some ambiguity in the Servlet specification in
terms of what the expected behavior *should* be.  The Jetty
implementation dispatches to the configured <error-page> (the
ErrorHandlingServlet) in the life of the FilterChain... but in Tomcat,
the container invokes it after the chain is complete.

I think that a fix could be as follows:

1) In the finally block of the
GrailsWebRequestFilter.doFilterInternal() method we could detect if an
error has occurred
(request.getAttribute("javax.servlet.error.status_code") != null).  If
there is an error - don't clear the thread bound request.

2) Implement a finally block in the
ErrorHandlingServlet.doFilterInternal() that performs the cleanup
skipped above.

I'll take a look SVN to see if this has already been fixed.... if not,
I can submit a patch.

Brock

On Wed, Jul 9, 2008 at 3:58 PM, Brock Heinz <brock.heinz@...> wrote:

> http://jira.codehaus.org/browse/GRAILS-3219
>
>
> On Wed, Jul 9, 2008 at 3:01 PM, Brock Heinz <brock.heinz@...> wrote:
>> Baha,
>>
>> Thanks for the feedback.  I'm 99% this is a Grails bug in relation to
>> Tomcat.  I've put together a quick experiment that validates why I
>> think it's a bug.  I've done the following:
>>
>> 1) Reverted back to Grails 1.0.2
>>
>> 2) Created a trivial application that isolates the 404 behavior
>>
>> 3) Coded an 'errors' handler which the docs exhibit as seen here
>> http://grails.org/doc/1.0.x/guide/6.%20The%20Web%20Layer.html#6.4.4%20Mapping%20to%20Response%20Codes
>>
>> class ErrorsController {
>> def index = { render "Action: $actionName" }
>> def notFound = { render "Action: $actionName" }
>> }
>>
>> 4) Followed the UrlMapping exactly as shown in the Grails docs here
>> http://grails.org/doc/1.0.x/guide/6.%20The%20Web%20Layer.html#6.4.4%20Mapping%20to%20Response%20Codes
>>
>> class UrlMappings {
>>    static mappings = {
>>      "/$controller/$action?/$id?"{
>>              constraints {
>>                         // apply constraints here
>>                  }
>>          }
>>          "500"(view:'/error')
>>          "404"(controller:"errors", action:"notFound")
>>     }
>> }
>>
>> 5) Test in Jetty (>grails run-app) by invoking
>> http://localhost:8080/err/wontfindme.  The test works as expected and
>> my 'notFound' action is invoked.
>>
>> 6) Packaged the war (>grails dev war) and deploy to Tomcat (5.5.25)
>>
>> 7) Test in Tomcat by invoking http://localhost:8080/err/wontfindme.
>> Again, the test works.
>>
>> 8) Upgrade grails to 1.0.3 (>grails upgrade)
>>
>> 9) Test in Jetty again.  Again, the test works.
>>
>> 10) Package war and deploy to tomcat again.
>>
>> 11) Test URL again in Tomcat (http://localhost:8080/err/wontfindme).
>> Test FAILS.  I'm greeted with Tomcat's default 404 page :(
>>
>> I'm tired of opening JIRAs and waiting (this statement isn't a knock
>> on the Grails developers, just my own frustration with my thus-far
>> reluctance to really dive head first into the Grails source)... I
>> think I'm going to create a patch for this one.
>>
>> I'll follow up with the JIRA that I create and I'll be sure to post
>> the test Grails application I used in the experiment.
>>
>> Brock
>>
>>
>>
>> On Wed, Jul 9, 2008 at 12:15 PM, baha007 <baha007@...> wrote:
>>>
>>> Hi Brock,
>>>
>>> the redirection of the 404 seems to work on both the default Jetty and
>>> tomcat servers I have for the exception of the rendering of the 'not found'
>>> page which is not properly done on a missing page event as I mentioned in my
>>> previous post.
>>>
>>> I do suggest that you create a separate page and render it in your action
>>> instead of rendering 404, ie replace:
>>> render "404"
>>> by
>>> render(view: "notFound")
>>> and create a gsp file called 'notFound.gsp'
>>>
>>> this should work. As for rendering the page, I do not know why the rendering
>>> is not done properly.
>>> In my case, when I point to my not found page directly, the server properly
>>> renders the layout definition defined in my gsp but when I try to access a
>>> page that doesn't exist ie
>>> www.myGrailsDomain.com/myAppContext/somePagethatdontexist, the layout is not
>>> rendered anymore.
>>>
>>> This is my latest finding about the 404 error issue.
>>>
>>> regards,
>>>
>>> Baha
>>>
>>>
>>>
>>> BrockHeinz wrote:
>>>>
>>>> I dunno how the UrlMappings are configured for grails.org, but there
>>>> is no 404 handler working there either:
>>>>
>>>> http://grails.org/wontfindme
>>>>
>>>> Brock
>>>>
>>>>
>>>>
>>> --
>>> View this message in context: http://www.nabble.com/404---UrlMappings%2C-Tomcat-tp18349963p18366566.html
>>> Sent from the grails - user mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>

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

    http://xircles.codehaus.org/manage_email

[BrockHeinz]

Another option would be to ensure that the GrailsWebRequestFilter is
mapped to both REQUEST and ERROR dispatchers as follows:

    <filter-mapping>
        <filter-name>grailsWebRequest</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>ERROR</dispatcher>
        <dispatcher>REQUEST</dispatcher>
    </filter-mapping>

In the embedded Jetty environment, the GrailsWebRequestFilter is still
only invoked once when 404's occur, but in Tomcat it's invoked twice.

Jetty:

Start GrailsWebRequestFilter
  ... chain
  ... invoke error servlet
End GrailsWebRequestFilter

Tomcat:

Start GrailsWebRequestFilter
  ... chain
End GrailsWebRequestFilter
Start GrailsWebRequestFilter
  invoke error servlet
End GrailsWebRequestFilter

The second invocation of GrailsWebRequestFilter in the Tomcat scenario
ensures that the call to WebUtils.retrieveGrailsWebRequest() does not
result in an IllegalStateException (because there will still be
thread-bound request attributes).

Currently, I've hacked the ControllersGrailsPlugin to add the
dispatcher mappings, but I'll likely just create my own plugin and see
if I can hook into the web.xml generation without tampering with the
Grails source.  I really think the next version of Grails should
address this issue for a myriad of reasons.  If anyone is interested
in the plugin I'm going to create or if anyone wants to know more
about this issue that has exhausted me.... please let me know :)

Brock



On Wed, Jul 9, 2008 at 7:27 PM, Brock Heinz <brock.heinz@...> wrote:

> After a bit more investigation, I think I found the root of the
> problem, and it resides in the
> GrailsWebRequestFilter.doFilterInternal() method's 'finally' block.
> Within that finally block, the request is marked as completed, and any
> thread bound attributes are removed.
>
> In the embedded version of Jetty that ships with Grails, the finally
> block in the GrailsWebRequestFilter.doFilterInternal() method is
> invoked AFTER the ErrorHandlingServlet.doDispatch() method is called.
> In Tomcat, the finally block in the
> GrailsWebRequestFilter.doFilterInternal() method is called BEFORE
> invocation of the ErrorHandlingServlet.doDispatch() error handler.
>
> I'm guessing there is some ambiguity in the Servlet specification in
> terms of what the expected behavior *should* be.  The Jetty
> implementation dispatches to the configured <error-page> (the
> ErrorHandlingServlet) in the life of the FilterChain... but in Tomcat,
> the container invokes it after the chain is complete.
>
> I think that a fix could be as follows:
>
> 1) In the finally block of the
> GrailsWebRequestFilter.doFilterInternal() method we could detect if an
> error has occurred
> (request.getAttribute("javax.servlet.error.status_code") != null).  If
> there is an error - don't clear the thread bound request.
>
> 2) Implement a finally block in the
> ErrorHandlingServlet.doFilterInternal() that performs the cleanup
> skipped above.
>
> I'll take a look SVN to see if this has already been fixed.... if not,
> I can submit a patch.
>
> Brock
>
> On Wed, Jul 9, 2008 at 3:58 PM, Brock Heinz <brock.heinz@...> wrote:
>> http://jira.codehaus.org/browse/GRAILS-3219
>>
>>
>> On Wed, Jul 9, 2008 at 3:01 PM, Brock Heinz <brock.heinz@...> wrote:
>>> Baha,
>>>
>>> Thanks for the feedback.  I'm 99% this is a Grails bug in relation to
>>> Tomcat.  I've put together a quick experiment that validates why I
>>> think it's a bug.  I've done the following:
>>>
>>> 1) Reverted back to Grails 1.0.2
>>>
>>> 2) Created a trivial application that isolates the 404 behavior
>>>
>>> 3) Coded an 'errors' handler which the docs exhibit as seen here
>>> http://grails.org/doc/1.0.x/guide/6.%20The%20Web%20Layer.html#6.4.4%20Mapping%20to%20Response%20Codes
>>>
>>> class ErrorsController {
>>> def index = { render "Action: $actionName" }
>>> def notFound = { render "Action: $actionName" }
>>> }
>>>
>>> 4) Followed the UrlMapping exactly as shown in the Grails docs here
>>> http://grails.org/doc/1.0.x/guide/6.%20The%20Web%20Layer.html#6.4.4%20Mapping%20to%20Response%20Codes
>>>
>>> class UrlMappings {
>>>    static mappings = {
>>>      "/$controller/$action?/$id?"{
>>>              constraints {
>>>                         // apply constraints here
>>>                  }
>>>          }
>>>          "500"(view:'/error')
>>>          "404"(controller:"errors", action:"notFound")
>>>     }
>>> }
>>>
>>> 5) Test in Jetty (>grails run-app) by invoking
>>> http://localhost:8080/err/wontfindme.  The test works as expected and
>>> my 'notFound' action is invoked.
>>>
>>> 6) Packaged the war (>grails dev war) and deploy to Tomcat (5.5.25)
>>>
>>> 7) Test in Tomcat by invoking http://localhost:8080/err/wontfindme.
>>> Again, the test works.
>>>
>>> 8) Upgrade grails to 1.0.3 (>grails upgrade)
>>>
>>> 9) Test in Jetty again.  Again, the test works.
>>>
>>> 10) Package war and deploy to tomcat again.
>>>
>>> 11) Test URL again in Tomcat (http://localhost:8080/err/wontfindme).
>>> Test FAILS.  I'm greeted with Tomcat's default 404 page :(
>>>
>>> I'm tired of opening JIRAs and waiting (this statement isn't a knock
>>> on the Grails developers, just my own frustration with my thus-far
>>> reluctance to really dive head first into the Grails source)... I
>>> think I'm going to create a patch for this one.
>>>
>>> I'll follow up with the JIRA that I create and I'll be sure to post
>>> the test Grails application I used in the experiment.
>>>
>>> Brock
>>>
>>>
>>>
>>> On Wed, Jul 9, 2008 at 12:15 PM, baha007 <baha007@...> wrote:
>>>>
>>>> Hi Brock,
>>>>
>>>> the redirection of the 404 seems to work on both the default Jetty and
>>>> tomcat servers I have for the exception of the rendering of the 'not found'
>>>> page which is not properly done on a missing page event as I mentioned in my
>>>> previous post.
>>>>
>>>> I do suggest that you create a separate page and render it in your action
>>>> instead of rendering 404, ie replace:
>>>> render "404"
>>>> by
>>>> render(view: "notFound")
>>>> and create a gsp file called 'notFound.gsp'
>>>>
>>>> this should work. As for rendering the page, I do not know why the rendering
>>>> is not done properly.
>>>> In my case, when I point to my not found page directly, the server properly
>>>> renders the layout definition defined in my gsp but when I try to access a
>>>> page that doesn't exist ie
>>>> www.myGrailsDomain.com/myAppContext/somePagethatdontexist, the layout is not
>>>> rendered anymore.
>>>>
>>>> This is my latest finding about the 404 error issue.
>>>>
>>>> regards,
>>>>
>>>> Baha
>>>>
>>>>
>>>>
>>>> BrockHeinz wrote:
>>>>>
>>>>> I dunno how the UrlMappings are configured for grails.org, but there
>>>>> is no 404 handler working there either:
>>>>>
>>>>> http://grails.org/wontfindme
>>>>>
>>>>> Brock
>>>>>
>>>>>
>>>>>
>>>> --
>>>> View this message in context: http://www.nabble.com/404---UrlMappings%2C-Tomcat-tp18349963p18366566.html
>>>> Sent from the grails - user mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>    http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>
>>
>

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

    http://xircles.codehaus.org/manage_email

[BrockHeinz]

If anyone is still following this thread - here's a way to ensure the
web.xml contains the error / request dispatch elements for the
grailsWebRequest filter mapping:

http://amorproximi.blogspot.com/2008/07/more-on-grails-declarative-error.html

hth,
Brock



On Thu, Jul 10, 2008 at 11:49 AM, Brock Heinz <brock.heinz@...> wrote:

> Another option would be to ensure that the GrailsWebRequestFilter is
> mapped to both REQUEST and ERROR dispatchers as follows:
>
>    <filter-mapping>
>        <filter-name>grailsWebRequest</filter-name>
>        <url-pattern>/*</url-pattern>
>        <dispatcher>ERROR</dispatcher>
>        <dispatcher>REQUEST</dispatcher>
>    </filter-mapping>
>
> In the embedded Jetty environment, the GrailsWebRequestFilter is still
> only invoked once when 404's occur, but in Tomcat it's invoked twice.
>
> Jetty:
>
> Start GrailsWebRequestFilter
>  ... chain
>  ... invoke error servlet
> End GrailsWebRequestFilter
>
> Tomcat:
>
> Start GrailsWebRequestFilter
>  ... chain
> End GrailsWebRequestFilter
> Start GrailsWebRequestFilter
>  invoke error servlet
> End GrailsWebRequestFilter
>
> The second invocation of GrailsWebRequestFilter in the Tomcat scenario
> ensures that the call to WebUtils.retrieveGrailsWebRequest() does not
> result in an IllegalStateException (because there will still be
> thread-bound request attributes).
>
> Currently, I've hacked the ControllersGrailsPlugin to add the
> dispatcher mappings, but I'll likely just create my own plugin and see
> if I can hook into the web.xml generation without tampering with the
> Grails source.  I really think the next version of Grails should
> address this issue for a myriad of reasons.  If anyone is interested
> in the plugin I'm going to create or if anyone wants to know more
> about this issue that has exhausted me.... please let me know :)
>
> Brock
>
>
>
> On Wed, Jul 9, 2008 at 7:27 PM, Brock Heinz <brock.heinz@...> wrote:
>> After a bit more investigation, I think I found the root of the
>> problem, and it resides in the
>> GrailsWebRequestFilter.doFilterInternal() method's 'finally' block.
>> Within that finally block, the request is marked as completed, and any
>> thread bound attributes are removed.
>>
>> In the embedded version of Jetty that ships with Grails, the finally
>> block in the GrailsWebRequestFilter.doFilterInternal() method is
>> invoked AFTER the ErrorHandlingServlet.doDispatch() method is called.
>> In Tomcat, the finally block in the
>> GrailsWebRequestFilter.doFilterInternal() method is called BEFORE
>> invocation of the ErrorHandlingServlet.doDispatch() error handler.
>>
>> I'm guessing there is some ambiguity in the Servlet specification in
>> terms of what the expected behavior *should* be.  The Jetty
>> implementation dispatches to the configured <error-page> (the
>> ErrorHandlingServlet) in the life of the FilterChain... but in Tomcat,
>> the container invokes it after the chain is complete.
>>
>> I think that a fix could be as follows:
>>
>> 1) In the finally block of the
>> GrailsWebRequestFilter.doFilterInternal() method we could detect if an
>> error has occurred
>> (request.getAttribute("javax.servlet.error.status_code") != null).  If
>> there is an error - don't clear the thread bound request.
>>
>> 2) Implement a finally block in the
>> ErrorHandlingServlet.doFilterInternal() that performs the cleanup
>> skipped above.
>>
>> I'll take a look SVN to see if this has already been fixed.... if not,
>> I can submit a patch.
>>
>> Brock
>>
>> On Wed, Jul 9, 2008 at 3:58 PM, Brock Heinz <brock.heinz@...> wrote:
>>> http://jira.codehaus.org/browse/GRAILS-3219
>>>
>>>
>>> On Wed, Jul 9, 2008 at 3:01 PM, Brock Heinz <brock.heinz@...> wrote:
>>>> Baha,
>>>>
>>>> Thanks for the feedback.  I'm 99% this is a Grails bug in relation to
>>>> Tomcat.  I've put together a quick experiment that validates why I
>>>> think it's a bug.  I've done the following:
>>>>
>>>> 1) Reverted back to Grails 1.0.2
>>>>
>>>> 2) Created a trivial application that isolates the 404 behavior
>>>>
>>>> 3) Coded an 'errors' handler which the docs exhibit as seen here
>>>> http://grails.org/doc/1.0.x/guide/6.%20The%20Web%20Layer.html#6.4.4%20Mapping%20to%20Response%20Codes
>>>>
>>>> class ErrorsController {
>>>> def index = { render "Action: $actionName" }
>>>> def notFound = { render "Action: $actionName" }
>>>> }
>>>>
>>>> 4) Followed the UrlMapping exactly as shown in the Grails docs here
>>>> http://grails.org/doc/1.0.x/guide/6.%20The%20Web%20Layer.html#6.4.4%20Mapping%20to%20Response%20Codes
>>>>
>>>> class UrlMappings {
>>>>    static mappings = {
>>>>      "/$controller/$action?/$id?"{
>>>>              constraints {
>>>>                         // apply constraints here
>>>>                  }
>>>>          }
>>>>          "500"(view:'/error')
>>>>          "404"(controller:"errors", action:"notFound")
>>>>     }
>>>> }
>>>>
>>>> 5) Test in Jetty (>grails run-app) by invoking
>>>> http://localhost:8080/err/wontfindme.  The test works as expected and
>>>> my 'notFound' action is invoked.
>>>>
>>>> 6) Packaged the war (>grails dev war) and deploy to Tomcat (5.5.25)
>>>>
>>>> 7) Test in Tomcat by invoking http://localhost:8080/err/wontfindme.
>>>> Again, the test works.
>>>>
>>>> 8) Upgrade grails to 1.0.3 (>grails upgrade)
>>>>
>>>> 9) Test in Jetty again.  Again, the test works.
>>>>
>>>> 10) Package war and deploy to tomcat again.
>>>>
>>>> 11) Test URL again in Tomcat (http://localhost:8080/err/wontfindme).
>>>> Test FAILS.  I'm greeted with Tomcat's default 404 page :(
>>>>
>>>> I'm tired of opening JIRAs and waiting (this statement isn't a knock
>>>> on the Grails developers, just my own frustration with my thus-far
>>>> reluctance to really dive head first into the Grails source)... I
>>>> think I'm going to create a patch for this one.
>>>>
>>>> I'll follow up with the JIRA that I create and I'll be sure to post
>>>> the test Grails application I used in the experiment.
>>>>
>>>> Brock
>>>>
>>>>
>>>>
>>>> On Wed, Jul 9, 2008 at 12:15 PM, baha007 <baha007@...> wrote:
>>>>>
>>>>> Hi Brock,
>>>>>
>>>>> the redirection of the 404 seems to work on both the default Jetty and
>>>>> tomcat servers I have for the exception of the rendering of the 'not found'
>>>>> page which is not properly done on a missing page event as I mentioned in my
>>>>> previous post.
>>>>>
>>>>> I do suggest that you create a separate page and render it in your action
>>>>> instead of rendering 404, ie replace:
>>>>> render "404"
>>>>> by
>>>>> render(view: "notFound")
>>>>> and create a gsp file called 'notFound.gsp'
>>>>>
>>>>> this should work. As for rendering the page, I do not know why the rendering
>>>>> is not done properly.
>>>>> In my case, when I point to my not found page directly, the server properly
>>>>> renders the layout definition defined in my gsp but when I try to access a
>>>>> page that doesn't exist ie
>>>>> www.myGrailsDomain.com/myAppContext/somePagethatdontexist, the layout is not
>>>>> rendered anymore.
>>>>>
>>>>> This is my latest finding about the 404 error issue.
>>>>>
>>>>> regards,
>>>>>
>>>>> Baha
>>>>>
>>>>>
>>>>>
>>>>> BrockHeinz wrote:
>>>>>>
>>>>>> I dunno how the UrlMappings are configured for grails.org, but there
>>>>>> is no 404 handler working there either:
>>>>>>
>>>>>> http://grails.org/wontfindme
>>>>>>
>>>>>> Brock
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> View this message in context: http://www.nabble.com/404---UrlMappings%2C-Tomcat-tp18349963p18366566.html
>>>>> Sent from the grails - user mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>>    http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

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

    http://xircles.codehaus.org/manage_email