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: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 29, 2000 06:17
To: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 29, 2000 03:24
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
> > Mobile: 972-53-866-459
> > Office: 972-2-5891-459
> >
> .
> hx.
> >
> > ________________________
> > Shai Fultheim
> > Chief Technology Officer
> > BRM Group
> >
> > E-Mail: [EMAIL PROTECTED]
> > Mobile: 972-53-866-459
> > Office: 972-2-5891-459
> >
> .
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to