The people who made that decision are by now long gone, and I can't think of any good reason myself.
musachy On Wed, Oct 28, 2009 at 7:26 AM, Greg Lindholm <greg.lindh...@gmail.com> wrote: > I believe the short answer is you can ignore this warning. If really > inclined you could create your own base class that extends from > ActionSupport and implements readObject(). > > It's very common in web frameworks to use Serializable objects for a couple > or reasons, such as being able to preserve state across a server restart and > for shipping objects around in a cluster. > > With that said, (IMHO) I believe it was a design mistake to have > ActionSupport implement Serializable. I don't believe that either of the > above really apply to Action objects since they are short-lived. The choice > of making Actions Serializable should have been left to the developer and > not "forced" by the framework. > (Of course I realize that no one is truly forced to use ActionSupport and > you can reimplement your own version that is not Serializable, but why > should you need to.) > > Any committers care to comment on the reasons for having ActionSupport > implement Serializable? > > > On Wed, Oct 28, 2009 at 1:11 AM, Lee Clemens <j...@leeclemens.net> wrote: > >> Hello, >> >> I (my IDE) noticed a warning showing that my Struts 2 Actions (they extend >> com.opensymphony.xwork2.ActionSupport) may be deserialized, compromising >> security. >> >> The IDE (IntelliJ 8.1) further states that the class may be deserializable >> as it supports the Serializable interface (ActionSupport does) and its >> readObject() method is not defined to immediately throw an error. >> >> Please excuse my naivety or if this is off-topic, but is this safe? >> Furthermore, how can I override the readObject() method as suggested and >> throw an error without compromising functionality within Struts? >> >> As an aside, if this warning can safely be addressed, why doesn't >> ActionSupport override readObject() to avoid this? >> >> Thanks, >> Lee >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> For additional commands, e-mail: user-h...@struts.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
