Matthew Heaton wrote:
> I've been trying to get Struts to work on weblogic for many days with little
> success because of the failures of Weblogic's part. Finally tried to deploy
> and use it on Weblogic 6.0 Beta 2 and noticed some interesting behavior. It
> deployed fine but when I tried to run the example application I started
> getting errors saying that Weblogic could not deserialize the context
> attribute (see exact errors at end of mail) It appears that Weblogic
> requires any object that you use as a context attribute on a JSP page must
> be serializable. I went through some of the Struts source and it's trying
> to use objects which aren't serializable as JSP page context attributes.
> This looks like it may be a shortcoming in the JSP spec because it makes
> sense that to support to failover of sessions you would need to be able to
> serialize the attributes since the attributes of a PageContext may have the
> scope of an entire session. This is a bug that probably will show up on
> many different App Servers that support the failover of Sessions not just
> Weblogic and should probably be addressed in Struts even though it hasn't
> been directly addressed by the JSP 1.1 or 1.2 specs
The specification that actually matters in this regard is the servlet spec. In
Servlet 2.2, it says (p. 37):
Within an application that is marked as distributable,
all requests athat are part of that session can only
be handled on a single VM at any one time. In addition,
all objects placed into instances of the HttpSession
class using the setAttribute or putValue method must
implement the Serializable interface. The servlet container
may throw an IllegalArgumentException if a non serializable
object is placed in the session.
(There is similar language in Servlet 2.3 pp. 51-52).
In other words, you are only prohibited (by the specs themselves) from storing
non-serializable session attributes if you include a <distributable> element in
the web.xml file -- which the Struts example application does *not* do. There
is no spec-based prohibition on storing non-serializable attributes if
<distributable> is not set, although an application server environment might
impose such requirements (although you'd think they would throw the
IllegalArgumentException when session.setAttribute() was called, as the text
above suggests :-).
In non-distributed environments, it is quite common to have non-Serializable
things like JDBC connections and result sets, references to open files, and
things like that stored in sessions. That is why they are not prohibited
outright.
That all being said, I will take a pass through the example application and make
sure it will run in a distributable fashion on servers that support this.
Besides just making the relevant objects Serializable, there are some other
issues that need to be reviewed -- in particular, the way that the
pseudo-database in the example works.
Note that this issue relates *solely* to the Struts example application. The
only session attribute that the framework itself ever sets is the
java.util.Locale describing the user's current language choice -- and this class
is itself Serializable.
>
> -Matt
Craig McClanahan
