Why do I need to serialize ALL session objects?

[Gerry Giese]

I probably have mentioned this before, but my (recent) past desktop development server was Resin. I've been putting objects into sessions and getting them out just fine. But I tried to run my webapp on iAS SP4 on my desktop (W2K) and it choked. The stack trace makes me thing it choked on the objects I'm putting into the sessions, complaining that they aren't serializable. Since when was that a requirement for .WAR webapps??
Has anyone else had this happen? Has it happened on the Solaris iAS? Is this some option in the server that I haven't found yet, or a requirement that I can't get around and I'm just going to have to make all my session objects serializable?
Thanks! Here's the stack trace:

[13/Feb/2002 14:20:58:1] info: --------------------------------------
[13/Feb/2002 14:20:58:1] info: Main: init
[13/Feb/2002 14:20:58:1] info: --------------------------------------
[13/Feb/2002 14:20:58:5] error: SERVLET-put_nonserial: Putting non-serializable object when using NAS session
[13/Feb/2002 14:20:58:8] error: Exception: SERVLET-execution_failed: Error in executing servlet Main: java.lang.NullPointerException 
Exception Stack Trace: 
java.lang.NullPointerException
at java.util.Hashtable.put(Hashtable.java:381)
at Main.doProcessing(Main.java:68)
at snl.app.AppServlet.doGet(AppServlet.java:229)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:865)
at com.netscape.server.servlet.servletrunner.ServletInfo.service(Unknown Source)
at com.netscape.server.servlet.servletrunner.ServletRunner.execute(Unknown Source)
at com.kivasoft.applogic.AppLogic.execute(Unknown Source)
at com.kivasoft.applogic.AppLogic.execute(Unknown Source)
at com.kivasoft.thread.ThreadBasic.run(Native Method)
at java.lang.Thread.run(Thread.java:479)

[Mike Curwen]

I've used ias6SP4 on my Win2000 desktop and haven't run into this. On the other hand, I've only used Java API provided objects, most of which implement Serializable.

From the spec (servlet 2.3):

Final Version
SRV.7.7.2 Distributed Environments
Within an application marked as distributable, all requests that are part of a session
must handled by one virtual machine at a time. The container must be able to handle
all objects placed into instances of the HttpSession class using the setAttribute or
putValue methods appropriately. The following restrictions are imposed to meet
these conditions:
• The container must accept objects that implement the Serializable interface
• The container may choose to support storage of other designated objects in
the HttpSession, such as references to Enterprise JavaBean components and
transactions.
• Migration of sessions will be handled by container-specific facilities.
The servlet container may throw an IllegalArgumentException if an object is
placed into the session that is not Serializable or for which specific support has
not been made available. The IllegalArgumentException must be thrown for
objects where the container cannot support the mechanism necessary for
migration of a session storing them.
These restrictions mean that the Developer is ensured that there are no
additional concurrency issues beyond those encountered in a non-distributed
container.
 
 
 
** The bit I think is important **
The Container Provider can ensure scalability and quality of service features
like load-balancing and failover by having the ability to move a session object,
and its contents, from any active node of the distributed system to a different node
of the system.
**********************************
 
If distributed containers persist or migrate sessions to provide quality of
service features, they are not restricted to using the native JVM Serialization
mechanism for serializing HttpSessions and their attributes. Developers are not
guaranteed that containers will call readObject and writeObject methods on
session attributes if they implement them, but are guaranteed that the
Serializable closure of their attributes will be preserved.

There's stuff in there that doesn't apply, but it gives some hint as to why iPlanet might object if the objects are not serializable. So I've highlighted the part I think is tripping your code up. Looks like iPlanet requires your objects to support serialization, which is not a hugely awful thing (or is it?).
[ February 16, 2002: Message edited by: Mike Curwen ]

[Mike Curwen]

The evidence piles up:

Here's a document from the days of NAS (thank GOD things got simpler)

http://developer.iplanet.com/viewsource/gee_nas/gee_nas_p.html

Search that page for "java.io.Serializable" and the paragraph it is in, explains that objects to be placed into a session MUST implement it.

I'll post again if I can find something relating to iPlanet 6

[Gerry Giese]

Thanks Mike! Using your notes and some additional research, I finally got the whole picture. The biggest help was the release notes, which listed this as one of their ongoing issues. Apparently you have to set the "session-impl" in ias-web.xml to be "lite". Related is a suggestion to use "sticky" load balancing. Apparently NAS (now iPlanet) sessions try to be distributed by default, and in order to set copies of the session info from one session to another, the data is moved out of the JVM and into the KXS, hence the serialization requirement. After playing around a bit I finally got it configured so I can use non-serializable objects into sessions.
Thanks for the help!