You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org> on 2008/10/28 17:51:44 UTC
[jira] Closed: (TAP5-222) Runtime problems for Tapestry inside
WebSphere 6.1
[ https://issues.apache.org/jira/browse/TAP5-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship closed TAP5-222.
-------------------------------------
Resolution: Cannot Reproduce
The suggested fix is implemented, nobodie's come forward to verify that this is still a problem.
> Runtime problems for Tapestry inside WebSphere 6.1
> --------------------------------------------------
>
> Key: TAP5-222
> URL: https://issues.apache.org/jira/browse/TAP5-222
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.0.15
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org