[
https://issues.apache.org/jira/browse/TAP5-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Gusev updated TAP5-2074:
-------------------------------
Description:
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("");
}
}
});
}
was:
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("");
}
}
});
}
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
