tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Willem Dekker (JIRA)" <...@tapestry.apache.org>
Subject [jira] Created: (TAPESTRY-1713) Tapestry doesn't run correctly on Websphere 6.1 due to a different implementation of httpServletRequest.getServletPath() and handling filter requests
Date Tue, 21 Aug 2007 09:29:30 GMT
Tapestry doesn't run correctly on Websphere 6.1 due to a different implementation of httpServletRequest.getServletPath()
and handling filter requests
-----------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: TAPESTRY-1713
                 URL: https://issues.apache.org/jira/browse/TAPESTRY-1713
             Project: Tapestry
          Issue Type: Bug
    Affects Versions: 5.0.5
         Environment: Websphere 6.1.0.9 on windows xp professional
            Reporter: Willem Dekker
             Fix For: 5.0.6


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


Mime
View raw message