Great! Well, the first thing to do is think hard about SavedRequest and see if there is any reason it can't be Serializable. If not, then
1) Open a Feature Request JIRA under the Application Server project on jira.jboss.com. 2) You need to post a patch to the Tomcat development list making SavedRequest Serializable. I'm not a Tomcat committer, so I can't just commit it for you; needs to be blessed and committed by the TC people. If you want, reference the JIRA issue so they know what you're working toward. 3) Then we need to deal with replicating the note itself. In Branch_4_0 you're limited in what you can do, as changing the serialized format of a session is not allowed. So, probably the thing to do is in ClusteredSession override setNote(), check if the key is for your SavedRequest, and if it is also cache the value in a transient field. Then update write/readExternal to store your cached SavedRequest under a special key in the regular attribute map (via setAttribute()). This ensures the SavedRequest is stored in a way that's already part of the existing serialized format. You need to think about this; want to make sure the SavedRequest doesn't remain in the attribute map on either the sender or receiver side, no matter which of the ClusteredSession subclasses is used (SessionBased, FieldBased or AttributeBasedClusteredSession). In HEAD we have more flexibility as to what to do, as it's OK to change the serialized format because there have been no releases of the 5.0.x series yet. I'm tempted to just replicate the notes map (or better yet a copy of it with anything that doesn't implement Serializable removed). But would need to analyze all uses of the map first. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3969115#3969115 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3969115 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
