[
https://issues.apache.org/jira/browse/TAPESTRY-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Howard M. Lewis Ship reassigned TAPESTRY-1713:
----------------------------------------------
Assignee: Howard M. Lewis Ship
> 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
> 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
>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
