Gopi's Linux Account wrote:
> Hi,
>
> I know i am intruding b/w discussion of developers, yet i let it go. The
> Servlet Tutorial that comes along with JWS says that you can use encodeURL()
> in case of cookies-non supporting env. Also it has a feature of turning
> on./off writing the session contents to HD, of course that
> java.io.serialization tech. hold good there too. Why should not encodeURL()
> , as Jon mentioned, be used ??
>
> Riaz
>
Using encodeURL() is exactly the right thing to do if you want to use the
servlet engine's session management capabilities in an environment where
cookies are turned off. The original questioner wanted to use encoding even if
cookies are turned on, because it eliminates the "multiple windows are treated
as one session" issue. In such cases, servlet engines will stop encoding, even
if you call encodeURL(), because the session ID was returned in a cookie.
Apache JServ 1.0 will use cookies in this manner if they are turned on, and
there is no current way to turn that behavior off (as there is in some other
servlet engines). Jon suggested a workaround that was totally independent of
the servlet engine's session management, and always used encoding as the
mechanism, to get around this.
Craig
>
> -----Original Message-----
> From: Craig R. McClanahan <[EMAIL PROTECTED]>
> To: Java Apache Users <[EMAIL PROTECTED]>
> Date: 14 July 1999 08:40
> Subject: Re: Cookies & Url Rewriting
>
> >jon * wrote:
> >
> >> > 1.1 has a configuration setting for turning off the use of cookies, but
> 1.0
> >> does
> >> > not. Jon's suggestion is about the only viable work-around, but do be
> aware
> >> that
> >> > it locks you in to Apache JServ's mechanism for encoding with a query
> >> parameter.
> >>
> >> I'm not quite sure I understand you Craig. I personally have an
> application
> >> that has its own class which allows you to easily build URI's which
> contain
> >> a session variable that is associated to the user. It is servlet engine
> >> independant and does not rely on cookies.
> >
> >If you're talking about something totally independent of servlet engine
> session
> >management, I agree that you're not locked in. I thought you were
> recommending
> >that he force URL rewriting by pretending to be JServ, and using a
> "JServSessionId"
> >query parameter as the means to encode it.
> >
> >
> >>
> >>
> >> > Even in the 2.1 and 2.2 APIs, session persistence is not a required
> feature of
> >> > any servlet engine.
> >>
> >> Correct. I can't see the servletrunner.exe with this overhead. ;-)
> >>
> >> > If you configure 1.1 for this, it will attempt to serialize and
> deserialize
> >> your
> >> > session objects. Thus, they must implement "java.io.Serializable" to
> be
> >> > persisted. This will probably be true for any servlet engine that
> supports
> >> > session persistence.
> >>
> >> Yep...
> >>
> >> Lots of interesting tidbits and info:
> >>
> >> <http://www4.weblogic.com/docs/admindocs/properties.html#session>
> >>
> >> <http://www4.weblogic.com/docs/classdocs/API_servlet.html#session0>
> >>
> >> This is the best one from the page...;-)
> >>
> >> > Note: You can add any Java descendant of Object as a session value and
> >> > associate it with a name. However, if you are using session
> persistence,
> >> > your 'value' objects must implement Serializable.
> >>
> >
> >Where did you *think* I got a lot of my ideas on what features to include
> :-)?
> >These guys do it right.
> >
> >In my implementation, I don't complain if you store a non-Serializable
> object,
> >because this is still very useful for things like connection pools. I just
> >silently ignore such objects when storing a session to persistent storage,
> so they
> >effectively disappear when the session is reloaded.
> >
> >There was some talk about outlawing the storing of non-Serializable objects
> in the
> >spec. I was one of the voices against this, and the argument was
> apparently
> >persuasive enough.
> >
> >>
> >> More details:
> >>
> >>
> <http://www4.weblogic.com/docs/classdocs/API_servlet.html#sessionpersistence
> >> >
> >>
> >> -jon
> >>
> >
> >Craig
> >
> >
> >
> >
> >--
> >--------------------------------------------------------------
> >To subscribe: [EMAIL PROTECTED]
> >To unsubscribe: [EMAIL PROTECTED]
> >READ THE FAQ!!!! <http://java.apache.org/faq/>
> >Archives and Other: <http://java.apache.org/main/mail.html/>
> >Problems?: [EMAIL PROTECTED]
> >
> >
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> READ THE FAQ!!!! <http://java.apache.org/faq/>
> Archives and Other: <http://java.apache.org/main/mail.html/>
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
READ THE FAQ!!!! <http://java.apache.org/faq/>
Archives and Other: <http://java.apache.org/main/mail.html/>
Problems?: [EMAIL PROTECTED]
