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]
