tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: ContextPath, ServletPath and backwards compatibility
Date Thu, 18 Nov 1999 02:36:16 GMT
jon * wrote:

> on 11/17/99 6:03 PM, <> wrote:
> > I suppose I would have argued that the getServletPath() method should
> > have been backwards compatible, behaving like it did in the 2.0 JSDK,
> > and returning the "full" servlet path, context included.  One could
> > then trivially obtain the non-context part by getting a substring.  As
> > it is, this new behaviour seems likely to break many applications, and
> > force ugly, inefficient hacks to make them compatible with the
> > different API versions.
> >
> > I suppose, however, that it may be possible to change Turbine in such
> > a way that the above hack is not necessary.  I currently don't know
> > how to do that, though.
> >
> > Comments?
> Hey Jay, thanks for bringing this up. ;-) For now, I think that Brett is
> going to add your ugly hack (well, it is well done) to Turbine so that you
> can use it. But, I think that this list should discuss this issue further.
> This change is really bad for backwards compatibility. The method should
> have been deprecated or something imho so that it would be more easily
> possible to know if it was broken or not.
> -jon

First thought -- it's kinda late now to respecify the behavior of
getServletPath() in 2.2 even if everyone wanted to, so discussion on this
point is somewhat academic.

Second thought -- looking to the future rather than the past, compatibility
with the other calls that parse components of the request URI
(getContextPath(), getServletPath(), getPathInfo(), and getQueryString()) is
very important.  Renaming it might have been nice, but "getServletPath" nicely
connotes what it really does -- grabs the part of the URI that selected which
servlet to execute.

Third thought -- a large number of servlet applications based on the 2.0 API
are going to need to be rearchitected anyway because they relied on
getServlet() or HttpSessionContext.  Dealing with the getServletPath() issue
is trivial compared to dealing with those impacts.

Fourth though -- I can be somewhat sympathetic to the "backward compatible"
concept, until I remember that the 2.0 API is *ancient* in terms of Internet
time, and is essentially two major revs back.  Even the 2.1 based engines need
to be using the 2.2 interpretation to be compatible (see the JSP 1.0 spec,
Appendix B - "Java Servlet 2.1 clarifications").

Fifth thought -- even without the "hack", Turbine should have worked OK in the
default context (i.e. no context path prefix).  It only fails when you map to
a non-default context path, which is a feature not even contemplated in the
2.0 API.  If there's any incompatibility, it's actually in the opposite
direction :-).

Craig McClanahan

View raw message