Milt,
It's always easier to see how changes to the API affect people when the
group of people affected includes yourself ...
I had an unusual requirement where I needed to have two client programs
share a session, one which supported cookies and one which didn't. The
session was created for the first client and then had to be passed to the
second client. How could I do this? The servlet API doesn't allow me to
_force_ a URL to be encoded. So, I passed the session ID in the URL using my
own session encoding scheme. However, in order to do this, I needed
context.getSession(id) to figure out the session for the session ID when the
URL came back in.
So, basically the change from 2.0 to 2.1 meant that those "doing their own
(legitimate) thing" with sessions have to go right outside the session API
and write the whole thing themselves.
I suggested to the Servlet API team that they give the user of the API more
control over when URLs are session encoded (by adding a
HttpResponse.encodeURL( String url, boolean force ) or somesuch, which would
have got around my problem in the first place. I think this would have fixed
Craig's original problem too. To my mind, what this is all saying isn't so
much that the 2.0 -> 2.1 changes were bad, but that the encodeUrl() call is
not flexible enough, and it was shown up by the changes from 2.0 to 2.1.
Cheers
Geoff
-----Original Message-----
From: Milt Epstein <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Cc: Servlet Interest List <[EMAIL PROTECTED]>
Date: Tuesday, 20 July 1999 7:01
Subject: Re: Getting a session by ID?
>On Mon, 19 Jul 1999, Geoff Soutter wrote:
>
>> Milt,
>>
>> I didn't mean to turn this into a flame war. I think the Servlet API
>
>No intention to flame. I just felt your comments deserved a response.
>
>> is great. That doesn't mean it's perfect though. This is a case
>> where it could have been done better, and it could still be
>> improved.
>
>Sure, there's always room for improvement, and not every change will
>be without problems. But from what I have seen, the changes from 2.0
>to 2.1 were not as bad as you make them out to be. I'm not claiming
>to be an expert on how the removed functionality could've been used,
>but at least from what I've seen posted to these lists, AFAIR, I don't
>think there was anything that couldn't have been done with the new
>API. Also, just because you *can* do something doesn't mean you
>*should* do it.
>
>
>> -----Original Message-----
>> From: Milt Epstein <[EMAIL PROTECTED]>
>> Date: Saturday, 17 July 1999 2:15
>>
>> >On Fri, 16 Jul 1999, Geoff Soutter wrote:
>> >
>> >> Hi there Craig,
>> >>
>> >> I've been trying to do a similar kind of thing. Unfortunately the
>> >> APIs were deprecated AND DISABLED without warning when they went
>> >> from Servlet API 2.0 to 2.1. Which is pretty awful for anyone using
>> >> those API's. Apparently they were a security risk, but they have
>> >> legitimate uses as well which the Servlet API team decided to
>> >> ignore. :-(
>> >[ ... ]
>> >
>> >Servlets and the JSDK are a relatively young technology (despite how
>> >fast things move these days :-). They're trying to improve things, by
>> >making them cleaner and more secure, better organized, and with more
>> >functionality. I think they are doing a pretty good job of this,
>> >especially considering some of the latest talk of where things are
>> >heading, and comparing it to where things were back with JSDK 1.0 and
>> >2.0. Yes, it's a shame some functionality was removed, making things
>> >backwards-incompatible, but that is the price you have to pay
>> >sometimes. Justifying something that is a security risk as having
>> >"legitimate uses as well" is not very compelling, especially when
>> >there are alternate ways to do most/all you could've done with the
>> >functionality that was dropped (which is the case, as far as I can
>> >tell).
>> >
>>
>
>Milt Epstein
>Research Programmer
>Software/Systems Development Group
>Computing and Communications Services Office (CCSO)
>University of Illinois at Urbana-Champaign (UIUC)
>[EMAIL PROTECTED]
>------------------------------------------------------------
>To unsubscribe, send email to [EMAIL PROTECTED]
>and include in the body of the message "unsubscribe jrun-development".
>
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
