snip... >> >> BTW, that doesn't work so well when Tuscany is running in as Webapp, as >> the HTTPBindingListenerServlet doesn't get the right resource paths. >> >> I think that the problem is in HTTPBindingListenerServlet.java:78 >> String path = >> URLDecoder.decode(request.getRequestURI().substring(request.getServletPath().length()), >> "UTF-8"); >> which, I guess, is trying to get the part of the request URI after the >> http binding servlet path?? >> >> That code seems to work OK in J2SE with an embedded Web container, where >> there's no Web context root before the servlet path, but gets the wrong part >> of the URI in a hosted Webapp, where there is a Web context before the >> servlet path. >> >> I've tried to replace that line by: >> String path = URLDecoder.decode(request.getPathInfo(), "UTF-8"); >> which returned the expected resource path, but I'm not sure what else that >> change could break. >> >> Does anybody know for sure the intent of the original code? and why it >> used getRequestURI() instead of just request.getPathInfo()? >> >> Thanks > > That change doesn't cause any build break, and nobody has come up with any > more insight, so if there's no objections I'll push it from > sandbox/sebastien/java/dynamic [1] to trunk. > > [1] http://svn.apache.org/repos/asf/tuscany/sandbox/sebastien/java/dynamic/ > -- > Jean-Sebastien >
Looking at the line you reference: request.getRequestURI().substring(request.getServletPath().length()) It would seem to be trying to get the resource path after the part of path that identifies the servlet itself. Just by reading the docs your replacement of this with getPathInfo() seems to be correct. Description of getPathInfo() at [1] is "Returns any extra path information associated with the URL the client sent when it made this request. The extra path information follows the servlet path but precedes the query string and will start with a "/" character." Interestingly looking at the description of getRequestURI() at [1]. "Returns the part of this request's URL from the protocol name up to the query string in the first line of the HTTP request. The web container does not decode this String. For example: First line of HTTP request Returned Value POST /some/path.html HTTP/1.1 /some/path.html GET http://foo.bar/a.html HTTP/1.0 /a.html HEAD /xyz?a=b HTTP/1.1 /xyz " The example "GET http://foo.bar/a.html HTTP/1.0 /a.html" doesn't seem to match the description of being from the protocol name up to the query string. What do they mean by "protocol name" in this case? The bottom line is +1 on the change. Simon [1] http://www.javadocsonline.com/api/apis/java-ee-sdk6.0.zip/api/javax/servlet/http/HttpServletRequest.html -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
