[jira] Closed: (TAPESTRY-1713) Tapestry doesn't run correctly on Websphere 6.1 due to an incorrect implementation of HttpServletRequest.getServletPath()

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

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

Howard M. Lewis Ship closed TAPESTRY-1713.
------------------------------------------

       Resolution: Fixed
    Fix Version/s: 5.0.8

I've added documentation, culled from this bug listing, to the Tapestry project site.

> Tapestry doesn't run correctly on Websphere 6.1 due to an incorrect implementation of HttpServletRequest.getServletPath()
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: TAPESTRY-1713
>                 URL: https://issues.apache.org/jira/browse/TAPESTRY-1713
>             Project: Tapestry
>          Issue Type: Bug
>          Components: tapestry-core
>    Affects Versions: 5.0.5
>         Environment: Websphere 6.1.0.9 on windows xp professional
>            Reporter: Willem Dekker
>            Assignee: Howard M. Lewis Ship
>             Fix For: 5.0.8
>
>
> When evaluating T5 on Websphere 6.1 with RAD7.0 as development environment I had some problems running the tutorial1 application.
> I found that WAS handles the following things differently:
> Websphere does handle filter requests different then 'the other' containers this can be fixed  by installing fixpack 9 and setting the com.ibm.ws.webcontainer.invokeFiltersCompatibility to true.
> see:
> http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg1PK31377
> http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg1PK33090
> The other problem was that T5 depends on the getServletPath() method of the HttpServletRequest which is used in the getPath() method of the Request interface(RequestImp). 
> Websphere however always returns an empty string("") in the tutorial1 application. While other containers(I've tested on tomcat) returns the desired path.
> To make tapestry work on WAS6.1 I've contributed a Filter to the RequestHandler which puts an extended implementation of the RequestImp in the service method. 
> The getPath() method is now overidden like this:
> 		@Override
> 		public String getPath() {
> 			//Websphere returns the path in the getPathInfo()
> 			String path = request.getPathInfo();
> 			//path == null so no Websphere
> 			if (path == null) {
> 				return super.getPath();
> 			}
> 			//TODO find out if this is necessary
> 			if (path.length() == 0) {
> 				path = "/";
> 			}
> 			return path;
> 		}
> As one can see WAS6.1 gives the desired result on the getPathInfo() method and not on the getServletPath().
> I've looked up what the J2EE spec says about this and it states the following:
> • Servlet Path: The path section that directly corresponds to the mapping
> which activated this request. This path starts with a'/' character except in the
> case where the request is matched with the '/*' pattern, in which case it is an
> empty string.
> • PathInfo: The part of the request path that is not part of the Context Path or
> the Servlet Path. It is either null if there is no extra path, or is a string with a
> leading '/'.
> (source: Java(TM) Servlet Specification 2.4 Final Release)
> With the contributed filter the tutorial1 runs fine and I can continue evaluating T5.
> I don't think however, creating this kind of Filter should be a basic thing WAS developers should do when the want to create a T5 application.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org