On 11/29/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 11/29/05, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > <snip/> > In general, here's the policy that I propose to follow w.r.t. serialization: > > * Any class for which an instance might get stored (by the framework, > or by the application with the blessing of framework documentation > that says to do so) must be serializable. > > * Any class that is not serializable should not claim that it > "implements Serializable". > <snap/>
Indeed. > That being said, let's review the cases: > <snip/> > > * CommonsValidator > > > This is a JSF Validator, so it could well be attached to a UIComponent > stored in session scope. It's not obvious from a static review of the code > what's the problem, but if there is one it'll need to be fixed. > <snap/> > * StatusImpl > > > Absolutely has to be serializable -- it's probably the non-static > non-transient Log instance here. > <snip/> Actually, both classes have declared fields that are non-serializable interface types, rather than the serializable implementations of those interfaces (this is probably a candidate to deviate from the Java best practice of "coding to an interface" given the fields are private implementation details hidden from the class' public contract). And the logs. I'll take a stab at these two in a few days, since there is already consensus about the need to resolve these, and earlier this evening, I told Niall I'd look at similar issues in [resources] anyway. > > > 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]). > > > It's not obvious what we should do here ... but it's also not a decision we > (Shale developers) or even we (Struts developers) can make in a vacuum. > Needs to be addressed on commons-dev so any other stakeholders who care can > pitch in an opinion. > <snip/> Will move this bit to commons-dev when I get a chance. -Rahul > > -Rahul > > > Craig > > > [1] > > http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/chain/trunk/src/java/org/apache/commons/chain/impl/ContextBase.java > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
