tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <cmcclana...@mytownnet.com>
Subject Re: Servlet reloading?
Date Sun, 13 Feb 2000 06:19:03 GMT
Jason Hunter wrote:

> > > Cool trick.  What happens to objects in the session that aren't
> > > serializable, such as happens with a non-distributed webapp?
> >
> > Right now, they are just discarded silently which can be annoying if
> > you forget to make them serializable...
>
> Yep, that's what I was afraid of.  IMO, it would be better to lose all
> session objects on a context reload than lose some session data.  The
> downside though is that if I arrange for everything to be Serializable,
> then having this behavior would be really slick.  Maybe this should be
> an optional behavior that can be turned on?
>

The current approach implemented in the Catalina branch does this -- it's
a configuable option whether the entire session is trashed or the
Serializable objects are saved and restored.  In addition, since I've got
the 2.2 deployment descriptor to play with, I would encourage someone
utilizing this functionality to set the <distributable> element on their
application's descriptor, which causes HttpSession.setAttribute() to throw
an exception if you try to store a non-serializable attribute.  Then,
you're never going to get surprised when it disappears.

>
> > > And do you see this as a way to satisfy the API 2.2 requirement
> > > that no unexpected ClassCastException problems occur?  What about
> > > objects not in a session that are shared by servlets?
> >
> > I see this as a way to solve the problems. JServ has been doing
> > this since like 1.1b3.
>
> Right, but 1.1b3 isn't trying to be 2.2 compliant.

>
> > Other servlet engines do the same exact thing. I posted
> > something to the experts group about making this behavior as part
> > of the ServletAPI, but no one commented...sigh...
>
> So considering an endorsement of this behavior didn't make it into the
> spec (for whatever reason), is this still viable?
>

Class cast exceptions will still be caused if your new version of the
session attribute's class is not compatible with the old (serialized) one
-- and there is really very little a servlet container could do about
this.  The problem is the hokey way Java makes you deal with revisions to
classes (throwing away an entire class loader and everything loaded by
it).

As Jon points out, this is not normally a big deal in practice, because
it's used primarily in development environments.  However, I find myself
changing bean classes a LOT more than I change servlet classes, because
that's where I put all my business logic.  Thus, I still consider an
auto-reload implementation that saves session attributes (even with its
warts) very important during development.

If you want to auto-reload on changes to classes you are using as session
beans, you also need to configure things such that those classes are
loaded by AdaptiveClassLoader instead of the system class loader.  For
Apache JServ, that is accomplished by using the "repositories" propery.
My understanding of what Costin is doing on the main Tomcat branch is he
treats the WEB-INF/lib and WEB-INF/classes locations as the reloadable
repository.


>
> -jh-
>

Craig McClanahan



Mime
View raw message