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 > >
