[jira] [Closed] (TAP5-2074) Extra leading slashes in URLs in HTTP 404 error pages

["Howard M. Lewis Ship (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TAP5-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard M. Lewis Ship closed TAP5-2074.
--------------------------------------

    Resolution: Won't Fix

Since this is clearly a problem with the container, returning the wrong thing for .getContextPath(), and you have a work-around, this won't be fixed in Tapestry.

> Extra leading slashes in URLs in HTTP 404 error pages
> -----------------------------------------------------
>
>                 Key: TAP5-2074
>                 URL: https://issues.apache.org/jira/browse/TAP5-2074
>             Project: Tapestry 5
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.3.6
>            Reporter: Dmitry Gusev
>
> When implementing custom HTTP error page in Tapestry5 (like HTTP 404 error page described here: http://tapestry.apache.org/error-page-recipe.html ), all client URLs contain extra leading slashes, which makes those links invalid.
> By client URLs I mean URLs generated by tapestry for t:pagelink and all the assets (js, css, images, etc.).
> I had this bug in Tapestry 5.3.6 application deployed at Tomcat 7.0.29 as the ROOT context.
> The problem seems to be in HttpServletRequest.getContextPath() which returns "/" when request has been handled by ERROR dispatcher.
> Here's the javadoc of org.apache.tapestry5.services.Request.getContextPath():
> /**
>      * Returns the context path. This always starts with a "/" character and does not end with one, with the exception
>      * of servlets in the root context, which return the empty string.
>      */
>     String getContextPath();
> Default implementation of Tapestry5's RequestImpl.getContextPath() is simply delegates contextPath retrieval to servlet API:
>     public String getContextPath()
>     {
>         return request.getContextPath();
>     }
> Not sure if this is Tomcat or Tapestry bug, but Tapestry should definitely handle this situation.
> As a temporary workaround I had to implement MethodAdvice for Request.getContextPath() in my AppModule like this:
>     @Match("Request")
>     public void adviseRequestContextPath(MethodAdviceReceiver receiver) throws SecurityException, NoSuchMethodException
>     {
>         if (!receiver.getInterface().equals(Request.class))
>         {
>             return;
>         }
>         
>         @SuppressWarnings("unchecked")
>         Method method = receiver.getInterface().getDeclaredMethod("getContextPath");
>         
>         receiver.adviseMethod(method, new MethodAdvice()
>         {
>             @Override
>             public void advise(MethodInvocation invocation)
>             {
>                 MethodInvocation proceed = invocation.proceed();
>                 
>                 if ("/".equals(proceed.getReturnValue()))
>                 {
>                     proceed.setReturnValue("");
>                 }
>             }
>         });
>     }



--
This message was sent by Atlassian JIRA
(v6.2#6252)