On 11/15/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 11/14/05, Rahul Akolkar <[EMAIL PROTECTED]> wrote: <snip/> > > > > The other major item its complaining about is non-transient > > non-serializable fields in Serializable classes. That explains some of > > the NotSerializableException's I get with sticky sessions on Tomcat > > startup (mostly in subclasses of Commons Chain's base impls). Will > > take a stab at that soon. > > > Thanks ... those are important. Not just because we need to honor the > contracts about Serializable session scope attributes, but they also > indicate potential architectural issues if we are maintaining references to > non-Serializable stuff in session scope that should really not be > referenced. Struts 1.x has suffered from some of this kind of thing, causing > memory bloat due to duplicated object trees when you migrate a session from > one instance to another. > <snap/>
I got around to looking at some code today in serializability's light, and that leads to a few questions. I bring this up because I've err'ed here before and I wouldn't want [shale] (or [resources] - a similar discussion is probably in order on commons-dev) to do the same. First, the offenders include: [shale] * ServletRemoteContext * CommonsValidatorTag * CommonsValidator * ShalePhaseListener * ShaleWebContext * StatusImpl [clay] * ClayContext * ComponentBean * BuilderRuleContext * SymbolTag Some might be serializable, others are clearly not, even with any lazy initialization attempts. So, for each, maybe its best to revisit what prompted the serializability requirement, and how much each needs to be pushed. My cursory observations: * For the *Tag impls there isn't much leeway, so it might be worth biting the bullet * StatusImpl needs to be serializable by design * ShaleWebContext is in a tough spot already (see below) What are the Shale developers' views on the rest? It might not be a bad idea to have test cases to show that the round trips work as advertised (I can volunteer some), once this gets sorted out. > For the cases where this is really issues with Commons Chain implementation > classes, we will (of course) need to supply patches for that. Fortunately, > I'm a committer there too :-). > <snip/> Yes, having looked at the developer list for [chain], let me ask one [OT] question here, and I'll move to commons-dev (or user) if it becomes apparent this deserves its own thread: Digging into [chain], I found a related commit message on top of ContextBase [1]. Were there any further developments on that? Seems like it may be required to allow subclass implementors (of the base impls in chain) to make their own decisions about serializability to liberate the *WebContext classes, but that probably won't fit a minor release (I'm not even sure if one is planned for [chain]). -Rahul [1] http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/chain/trunk/src/java/org/apache/commons/chain/impl/ContextBase.java > > -Rahul > > > Craig > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
