True. But if you don't implement java.io.Serializable, you are surely not serializable, so it is a start. When I recently clustered an application, this filter found all those session objects which were not serializable. My first task at a new company was to cluster their app, which I knew nothing about. It was much easier to get one list then to look in the log, fix bean1, restart. Look in the log, fix bean2, restart...
Tim -----Original Message----- From: Peter Rossbach [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 15, 2006 9:30 AM To: Tomcat Users List Subject: Re: manager-remove/undeploy without losing sessions 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
