Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 62719 invoked by uid 500); 3 Feb 2003 16:05:02 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 62638 invoked from network); 3 Feb 2003 16:05:01 -0000 Delivered-To: <> User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 03 Feb 2003 16:06:47 +0000 Subject: Re: News from the Websphere 5.0 front From: Pier Fumagalli To: , Greg Wilkins Message-ID: In-Reply-To: <20030203142921.GE4514@bremen.dvs1.informatik.tu-darmstadt.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N "Christian Haul" wrote: > On 03.Feb.2003 -- 02:18 PM, Pier Fumagalli wrote: >> "Christian Haul" wrote: >> >>> On 03.Feb.2003 -- 01:55 PM, Pier Fumagalli wrote: >>>> "Gernot Koller" wrote: >>>>> >>>>> >>>>> >>>>> seems to fix most of these problems. >>>>> Still it's probably not the most elegant solution, is it ? >>>> >>>> Nope... But Jetty had the same problem... It's not a problem within Cocoon, >>>> it's a problem within WebSphere. In Jetty we patched it (in CVS right now). >>> >>> Speaking of jetty: In jetty request.getServletPath() returns an empty >>> string. Is that a bug or a feature? >> >> It is (IMO) the correct interpretation of the specification. If a servlet is >> mapped to all, as Cocoon does, then also ("/") is part of the path info, and >> therefore getServletPath (in my opinion) should be empty... >> >> What does Tomcat do? Does it return "/" or ""???? > > Depends on where you evaluate it. See the 2.1 samples. I use > getServletPath() to find the paths involved after the context path to > locate the source files. It works well in tomcat but does not in > jetty. > > Thus jetty http://localhost:8888/samples/foo/bar gives "" > and tomcat http://localhost:8080/cocoon/samples/foo/bar gives "samples/foo" The spec is (IMO) stupid in that, as it defines in page 76 that the behaviour of "/" as an "exceptional" case to be treated with care... I verified it, and actually Jetty doesn't do what page 76 of the servlet spec says in regards to the default ("/" mapped) servlet, it behaves as a person with some intelligence should... I just verified that both Tomcat and ServletExec correctly interpret the specification and map stuff as the exception on page 76 mentions... I'm CCing Greg Wilkins on that as he might be aware of a trick to make it work, or maybe he can help us fix the engine, and get the next version of Jetty even "better" (more compliant to an becoming-idioticly-complex specification) :-) :-) Greg, you aware of this or should I try to get a patch working for it? I know you're very busy, and I seriously don't mind putting some hours in it. Just tell me if I should. The problem is that if I map a servlet to "/" ServletExec and I request the "/the/servlet/spec/is/stupid" and Tomcat both return "/the/servlet/spec/is/stupid" as getServletPath() and null as getPathInfo(), while Jetty returns "" to getServletPath() and "/the/servlet/spec/is/stupid" in getPathInfo()... Pier --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org