Your filter show only that the class implements java.io.Serializable
and not that the object is really serializable ;-(

A good live session analyze shows the probe tomcat manager.
http://tomcatprobe.org

regards
Peter


Am 15.03.2006 um 14:59 schrieb Tim Lucia:

You may also find the following filter helpful. I wrote it to find those
session members who were not serializable.

Tim

package tim.lucia;

import java.io.IOException;
import java.io.Serializable;
import java.text.MessageFormat;
import java.util.Collection;
import java.util.Date;
import java.util.Enumeration;
import java.util.Iterator;
import java.util.LinkedList;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

/**
 * J2EE "Filter" to dump session info
 *
 * @author tim.lucia
 */
public class SessionDumper implements Filter
{
    private final static Log logger =
LogFactory.getLog(SessionDumper.class);
private final static String defaultSessionStatusFormat = "SessionID [{0}] created {1, date, yyyy-MMM-dd hh:mm a zzz} last {2, date, yyyy-MMM-dd
hh:mm a zzz}";
    private final static String defaultSessionObjectFormat = "[{0}] =
[{1}]";
    private final static boolean defaultShowSerializable = false;
private static String sessionStatusFormat = defaultSessionStatusFormat; private static String sessionObjectFormat = defaultSessionObjectFormat;
    private static boolean showSerializable = defaultShowSerializable;

    /**
     * Container startup notification
     */
    public void init(FilterConfig arg0) throws ServletException
    {
        if (logger.isDebugEnabled()) {
            logger.debug("init(): " + arg0);
        }
        String value = arg0.getInitParameter("sessionStatusFormat");
        if (null != value) {
                sessionStatusFormat = value;
        }
        value = arg0.getInitParameter("sessionObjectFormat");
        if (null != value) {
                sessionObjectFormat = value;
        }
        value = arg0.getInitParameter("showSerializable");
        if (null != value) {
                showSerializable = Boolean.valueOf(value).booleanValue();
        }
    }

    /**
     * Container shutdown notification
     */
    public void destroy()
    {
        logger.debug("destroy()");
    }

    /**
     * Process the container's filter request.
     * @param request - Request object
     * @param response - response object
     * @param chain - next filter in the chain.
     */
public void doFilter(ServletRequest request, ServletResponse response,
                         FilterChain chain)
        throws IOException, ServletException
    {
        if (logger.isDebugEnabled()) {
HttpServletRequest httpRequest = (HttpServletRequest) request;
            String uri = httpRequest.getRequestURI();
            chain.doFilter(request, response);
            logger.debug("Session for " + uri);
            dumpSession(request);
        }
        else {
            chain.doFilter(request, response);
        }
    }

    private void dumpSession(ServletRequest request)
    {
        if (request instanceof HttpServletRequest) {
                HttpSession session =
((HttpServletRequest)request).getSession(false);
                if (null != session) {
                        final String sessionID = session.getId();
                        final long createdAt = session.getCreationTime();
                        final long lastAccessed =
session.getLastAccessedTime();
                if (logger.isDebugEnabled()) {
                    final String sessionStatus =
                        MessageFormat.format(sessionStatusFormat, new
Object[] { sessionID, new Date(createdAt), new Date(lastAccessed) });
                    logger.debug(sessionStatus);
                }
                        Enumeration enumerator =
session.getAttributeNames();
                        Collection serializable = new LinkedList();
                        Collection nonSerializable = new LinkedList();
                        while (enumerator.hasMoreElements()) {
                                final String key =
(String)enumerator.nextElement();
                                final Object value =
session.getAttribute(key);
                                final String message =
MessageFormat.format(sessionObjectFormat, new Object[] {key, value});
                                if (value instanceof Serializable) {
                                        serializable.add(message);
                                }
                                else {
                                        nonSerializable.add(message);
                                }
                                if (showSerializable) {
                                        dumpList("====>Serializable<====",
serializable);                                  
                                }
                                dumpList("====>Non-Serializable<====",
nonSerializable);                               
                        }
                }
        }
    }

    private void dumpList(String header, Collection list)
    {
        if (list.size() > 0) {
                logger.debug(header);
                Iterator iterator = list.iterator();
                while (iterator.hasNext()) {
                        logger.debug(iterator.next());
                }
        }
    }

}

-----Original Message-----
From: Reinhard Moosauer [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 15, 2006 3:58 AM
To: Tomcat Users List
Subject: Re: manager-remove/undeploy without losing sessions


i filed an enhancement request for this issue here:
http://issues.apache.org/bugzilla/show_bug.cgi?id=38975

Rodrigo,

The mentioned session serialization is always activated and works fully
automatic. But only if all requirements to your applicatin are met:

All objects, which are ever bound to a HttpSession have to implement
'Serializable' and should also have a serialVersionUid the enable compatible changes. And all objects which are referenced by the session- attributes.
In practice there some more requirements:
- follow the guidelines for compatible changes to serializable objects
   (see jdk-docs)
- make all references to unserializable objects 'transient'
- Implement a public no-args constructor to initialize all these transient members correctly. (Sometimes necessary for loggers or db- connections)
- Check 'catalina.out' for NotSerializableExceptions and fix them.

A nice side effect of these guidlines is: you can use tomcat's clustering facilities quite easily, because it only requires serializable sessions!

Hope that helps,

Reinhard

Am Dienstag, 14. März 2006 16:29 schrieb Asensio, Rodrigo:
Reinhard, thanks for the tip, is that option (serialize sessions) in
the manager or in the admin ? Or it is a value that need to be changed
manually in server.xml or any props file ?

Thanks

Rodrigo Asensio

-----Original Message-----
From: Reinhard Moosauer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 14, 2006 9:04 AM
To: Tomcat Users List
Subject: Re: manager-remove/undeploy without losing sessions

Hi List,

I found something, that looked promising, but did not work.
Developers, please look, this could be a bug:

The deploy-task has an attribute "update", removes the context before
re-installing it. I hoped that this one would do what I want.

But unfortunately, it is equivalent to undeploy/deploy so my sessions
are gone again. :-(

Maybe I have to clarify, what I am doing with my sessions (for Rodrigo):

I have all session-attribute in my application serializable, so that
tomcat can save all session data to disk when the context or tomcat
itself is stopped. At startup these serialized data is being read back
by tomcat automatically. As a result, users can coutinue their work
exactly where the are.
(Except that the application is not available for 1-2 seconds. But it
is still unlikely that a users fires a request just in this moment, at
least for medium-frequency apps) Formerly, the persisted session data
survived the remove, so I could re-install the app.

Please help!

Reinhard

Am Dienstag, 14. März 2006 13:53 schrieb Reinhard Moosauer:
Hello List,

recently I upgraded from tomcat 5.5.9 to 5.5.15 Since then, all my
sessions are lost after a remove/install via the manager.

The problem is the following:
I installed a war-file, which is copied to the webapps-folder during
manager-install. When I want to replace the war with a new version,
I _have_ to undeploy, which deletes my persistent sessions too.

How can I get back the smooth behavior of 5.5.9, which allowed me an
application update on the fly without disturbing user sessions?

many thanks in advance for your advice

Reinhard

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

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


This message (including any attachments) contains confidential and/or
proprietary information intended only for the addressee.
Any unauthorized disclosure, copying, distribution or reliance on the
contents of this information is strictly prohibited and may constitute
a violation of law.  If you are not the intended recipient, please
notify the sender immediately by responding to this e-mail, and delete
the message from your system.  If you have any questions about this
e-mail please notify the sender immediately.

Ce message (ainsi que les eventuelles pieces jointes) est
exclusivement adresse au destinataire et contient des informations
confidentielles. La copie, la communication ou la distribution du
contenu de ce message sans l'accord prealable de l'expediteur sont
strictement interdits et peuvent constituer un delit. Si vous n'etes
pas destinataire de ce message, merci de le detruire et d'avertir
l'expediteur. Si vous avez des questions se rapportant a ce courrier
electronique, merci de bien vouloir notifier l'expediteur
immediatement.

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

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



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




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

Reply via email to