Generalized problems with session

["Rousseau, John" <JR...@silverstream.com>]

This is an expansion of the problem trying to be addressed by the
MessageResources -> MessageBundle proposed conversion. 

I haven't done much struts development (I'm more on the container
side), so bear with me.

I'm having a problem with state stored in the session that is not
serializable. For example in ActionServlet.processActionForm(), the
new formBean is stored in the session (assuming session scope). This
causes us problems with redeployment because the formBean is not
serializable, and we can't serialize the bean out and back into the
new session.

In the case of SilverStream (and others I believe), we use
Serialization to move instances from an old classloader to a new one
on redeployment. As discussed earlier, this falls apart when the
data in the session is not serializable.

Why doesn't struts save state in the servlet context instead of in
the session for instances like this? The life cycle of these
instances seems to map better to the lifecycle of an application,
and it has the decided advantage (for us) that the context is
destroyed when an application is redeployed. HttpSession, mapping to
the HTTP session concept can be longer lived, and can be active when
an appliction needs to be redeployed.

I realize that session specific data (like the message resources)
needs to be in the session, but it looks like other data could be
stored in the context. Am I missing any reasons why struts couldn't
use the context instead of the session for storing state?

Thanks
-John

----------------------------------------------------------------
John Rousseau                               jrr@silverstream.com
SilverStream Software                     Phone: +1 978 262 3564
2 Federal Street                            Fax: +1 978 262 3499
Billerica, MA 01821                  http://www.silverstream.com
----------------------------------------------------------------

Re: Generalized problems with session

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Hi John ... I've got a few comments interspersed below, and I'm sure others will
have thoughts as well.

"Rousseau, John" wrote:

> This is an expansion of the problem trying to be addressed by the
> MessageResources -> MessageBundle proposed conversion.
>
> I haven't done much struts development (I'm more on the container
> side), so bear with me.
>
> I'm having a problem with state stored in the session that is not
> serializable. For example in ActionServlet.processActionForm(), the
> new formBean is stored in the session (assuming session scope). This
> causes us problems with redeployment because the formBean is not
> serializable, and we can't serialize the bean out and back into the
> new session.
>

It makes sense to me that ActionForm beans should be Serializable.  They tend to
be very transient, because they represent state information across one, or a
very small number, of requests.

One option we have is to be heavy-handed and add "implements Serializable" to
the ActionForm base class, to remind/force people into doing this.  Can anyone
think of negative ramifications of this approach?

An additional choice in a Struts 1.0 environment is the ability to use request
scope for ActionForm instances, rather than session scope.  This should be the
preferred mechanism for pretty much all single-page forms, unless the cost of
instantiating an ActionForm bean on each request is abnormally high.

>
> In the case of SilverStream (and others I believe), we use
> Serialization to move instances from an old classloader to a new one
> on redeployment. As discussed earlier, this falls apart when the
> data in the session is not serializable.
>

In addition to container-specific issues (Tomcat has a feature like this as
well), the servlet specification mandates Serializable session attributes if you
run in a distributed server environment, and mark your application as
<distributable/> in the deployment descriptor.

>
> Why doesn't struts save state in the servlet context instead of in
> the session for instances like this?

Since ActionForm state is per-user, wouldn't that essentially be duplicating
what sessions already do for you?  You'd have to store these beans inside some
sort of collection keyed by session id anyway.

> The life cycle of these
> instances seems to map better to the lifecycle of an application,
> and it has the decided advantage (for us) that the context is
> destroyed when an application is redeployed. HttpSession, mapping to
> the HTTP session concept can be longer lived, and can be active when
> an appliction needs to be redeployed.
>
> I realize that session specific data (like the message resources)
> needs to be in the session, but it looks like other data could be
> stored in the context. Am I missing any reasons why struts couldn't
> use the context instead of the session for storing state?
>

It's actually the other way around, to my point of view -- the message resources
are a natural to be stored in application (i.e. servlet context) scope, and they
already are.  As we've discovered, some containers put restrictions on
attributes that are stored in application scope as well -- more info in an
upcoming message).

ActionForm beans should ideally be stored in request scope, unless you really
need to save them across requests -- in which case you really do want them saved
and restored on a "redeploy an updated application" scenario (so that this
action is essentially transparent to the user).  That would seem to work best by
storing them in session scope.

>
> Thanks
> -John
>

Craig McClanahan