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]
