You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by sh...@brm.com on 2001/01/01 18:27:20 UTC
RE: Session Serialize code
Hi,
I don't want to nudge too much, but I'm wondering what's going on with this.
Correct me if I'm wrong, but the last (GREAT !!) patches you have sent does
not implement read/write object to session object.
M I right?
Another issue is 'why making SimpleSessionStore final?'. I'm working on
implementing Serializable session store. Till latest patch there
SimpleSessionStore was different module than ServerManager, and I was able
to extend it. Now, I can't reuse that code and extend it without copy/paste
it (which not seems to me the right way to 'reuse' code).
???
--Shai
-----Original Message-----
From: Shai Fultheim (BRM IL)
Sent: Saturday, December 30, 2000 21:25
To: tomcat-dev@jakarta.apache.org
Cc: cmanolache@yahoo.com
Subject: RE: Session Serialize code
Thanks. I'll love to see this.
I'm rewriting the session serialize code as a plug-in module (that was your
offer), so I need sterilization support for ServerSession.
Please take care of that as fast as you can.
--Shai
-----Original Message-----
From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
Sent: Friday, December 29, 2000 06:17
To: tomcat-dev@jakarta.apache.org
Subject: RE: Session Serialize code
I'll check in the fix tommorow - the HttpSessionBindingEvent and
session reloading should go into the facade22 module.
I was thinking about this - does it make sense to keep the session code in
the core ? It seems to me that maintaining an object store is orthogonal
to the http functionality - all that's needed in core is management of the
session IDs ( create, encode in cookies/urls, etc ) - while the actual
store shouldn't be part of the core.
I'll try to find a way to decouple that even more than it is today,
probably that would help anyone who is working on advanced session
management as it'll make it independent of tomcat ( or server container ).
Costin
> I can't see ServerSession.writeObject (and readObject) there.
> You must have code which is ServerSession aware, since SeverSession member
> ssm (point to its manager) is not serializeable.
>
> Here is jon's original code (3.2.1): This must be fixed to be 3.3
> compatible. I can do that (it's really easy), but I don't know how to
handle
> the HttpSessionBindingEvent (in writeObject) below (It seems that
> ServerSession can't cast to HttpSession).
>
> Please let me know if you think this is un-needed.
>
> /**
> * Read a serialized version of this session object from the specified
> * object input stream.
> * <p>
> * <b>IMPLEMENTATION NOTE</b>: The reference to the owning Manager
> * is not restored by this method, and must be set explicitly.
> *
> * @param stream The input stream to read from
> *
> * @exception ClassNotFoundException if an unknown class is specified
> * @exception IOException if an input/output error occurs
> */
> private void readObject(ObjectInputStream stream)
> throws ClassNotFoundException, IOException {
>
> // Deserialize the scalar instance variables (except
> Manager)
> creationTime = ((Long) stream.readObject()).longValue();
> id = (String) stream.readObject();
> lastAccessedTime = ((Long) stream.readObject()).longValue();
> thisAccessedTime = ((Long)
stream.readObject()).longValue();
> maxInactiveInterval = ((Integer)
> stream.readObject()).intValue();
> isNew = ((Boolean) stream.readObject()).booleanValue();
> isValid = ((Boolean) stream.readObject()).booleanValue();
>
> attributes = (Hashtable) stream.readObject();
> }
>
>
> /**
> * Write a serialized version of this session object to the specified
> * object output stream.
> * <p>
> * <b>IMPLEMENTATION NOTE</b>: The owning Manager will not be stored
> * in the serialized representation of this Session. After calling
> * <code>readObject()</code>, you must set the associated Manager
> * explicitly.
> * <p>
> * <b>IMPLEMENTATION NOTE</b>: Any attribute that is not Serializable
> * will be silently ignored. If you do not want any such attributes,
> * be sure the <code>distributable</code> property of our associated
> * Manager is set to <code>true</code>.
> * <p>
> * <b>IMPLEMENTATION NOTE</b>: If we can't serialize the object stored
> in
> * the session, then check to see if it implements
> * HttpSessionBindingListener and then call its
> * valueUnbound method, allowing it to save its state
> * correctly instead of just being lost into the etherworld
> *
> * @param stream The output stream to write to
> *
> * @exception IOException if an input/output error occurs
> */
> private void writeObject(ObjectOutputStream stream) throws IOException
{
>
> // Write the scalar instance variables (except Manager)
> stream.writeObject(new Long(creationTime));
> stream.writeObject(id);
> stream.writeObject(new Long(lastAccessedTime));
> stream.writeObject(new Long(thisAccessedTime));
> stream.writeObject(new Integer(maxInactiveInterval));
> stream.writeObject(new Boolean(isNew));
> stream.writeObject(new Boolean(isValid));
>
> if (attributes.size() > 0) {
> // Accumulate the names of serializable attributes
> Hashtable results = new
> Hashtable(attributes.size());
>
> for (Enumeration e = attributes.keys();
> e.hasMoreElements() ; ) {
> String key = (String) e.nextElement();
> Object value = attributes.get(key);
> if (value instanceof Serializable) {
> results.put(key, value);
> }
> // if we can't serialize the object stored
> in
> // the session, then check to see if it
> implements
> // HttpSessionBindingListener and then call
> its
> // valueUnbound method, allowing it to save
> its state
> // correctly instead of just being lost into
> the etherworld
> else if (value instanceof
> HttpSessionBindingListener ) {
> try {
>
> ((HttpSessionBindingListener)value)
> .valueUnbound(new
> HttpSessionBindingEvent(this, key));
> } catch (Exception f) {
> // ignored
> }
> }
> }
> stream.writeObject(results);
> } else {
> stream.writeObject(new Hashtable());
> }
> }
> }
>
>
>
> --Shai
>
> -----Original Message-----
> From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> Sent: Friday, December 29, 2000 03:24
> To: tomcat-dev@jakarta.apache.org
> Cc: cmanolache@yahoo.com
> Subject: Re: Session Serialize code
>
> Hi Shai,
>
> Mea culpa :-)
>
> I moved Jon's code to org.apache.tomcat.util.ObjectSerializer
> ( I removed all dependencies to Session or tomcat internals - it should
> work for any serializable object ).
>
> ( my intentions were to make it more reusable and to reuse it in reloading
> context attributes, etc - there are other objects that might get lost in
> a server reload ).
>
> Let me know if you can use it in this form, and I can certainly add it
> back.
>
> Costin
>
>
>
> > Hi Costin,
> >
> > As discussed a week ago, someone took out Jon's code to serialize
session
> > from 3.3.
> > That code was part of 3.2 but does not exist in 3.3. Could you please
add
> it
> > back into ServerSession??
> >
> > As proposed by you I'm working on "SerializableSession" module, and I
need
> > that piece of code to serialize sessions.
> >
> > (Functions: writeObject, readObject)
> > Thx.
> >
> > ________________________
> > Shai Fultheim
> > Chief Technology Officer
> > BRM Group
> >
> > E-Mail: shai@brm.com
> > Mobile: 972-53-866-459
> > Office: 972-2-5891-459
> >
> .
> hx.
> >
> > ________________________
> > Shai Fultheim
> > Chief Technology Officer
> > BRM Group
> >
> > E-Mail: shai@brm.com
> > Mobile: 972-53-866-459
> > Office: 972-2-5891-459
> >
> .
>
RE: Session Serialize code
Posted by cm...@yahoo.com.
Hi, Shai,
Thanks for the feedback - now that the refactoring is almost completed,
testing the extension mechanisms and fixing errors is the most
important thing for 3.3.
> I don't want to nudge too much, but I'm wondering what's going on with this.
> Correct me if I'm wrong, but the last (GREAT !!) patches you have sent does
> not implement read/write object to session object.
I tried to make sure the core has all the support and can handle this -
and I think now it does.
We still use ObjectSerializer to change the class loader on reload, and
the HttpSession events are now handled in Servlet22Interceptor.
Read/Write is not implemented - but I think it can be done in a module, so
it's something that can be done at any time ( after 3.3 or whatever is
released ). BTW, there are many other session-related improvements that
can/should be done ( performance, scalability ) - but again, it'll be just
an add-on, independent module.
> M I right?
Yes.
> Another issue is 'why making SimpleSessionStore final?'. I'm working on
> implementing Serializable session store. Till latest patch there
> SimpleSessionStore was different module than ServerManager, and I was able
> to extend it. Now, I can't reuse that code and extend it without copy/paste
> it (which not seems to me the right way to 'reuse' code).
Sorry about this - my mistake. There is one reason to not extend
SimpleSessionStore and ServletManager ( now SimpleManager ) - the code has
not been refactored and cleaned up ( it's a module - the focus so far has
been on the core, modules can be done later and in an independent way,
without politics and fights ).
If you want, it might be a good idea to try to start a new
(cleaner) module to replace the current SimpleSessionStore. You can use
some of the code in SimpleSessStore. This would also test the current
mechanisms and hooks.
Costin