Hello,

How do I prevent the creation of the SESSIONS.ser file in the directory
/work/Catalina/localhost/mywebapp?

I have tried various things without success. We are new to Tomcat and Java in general. I'm assuming I need to set the saveOnRestart to false ?? But I'm not sure where or how. We have a applicaton that uses JSP and does call a java program from which we make our calls to DB2 on z/OS. When we shutdown the JZOS task or if we reload the application using Tomcat's Manager application, we get errors about being unable to serialize and other rather nasty looking messages.

From what I can gather Tomcat is attempting to save information about the application for use at startup and that info is being stored in the SESSIONS.ser file? We really don't need that behavior and are hoping that we can disable that feature.

Our environment is:
Apache Tomcat/5.0.28 / JVM 1.3.1 / JZOS 1.2.3 z/OS

Thanks in advance,
Dave

By default Tomcat will create a "Manager" for each Webapp that will try to serialize servlet sessions. A JSP can attach Java object to sessions, but if it does, then those objects must be "serializable". If not, you will get errors as you describe. So, the problem is that your JSP app doesn't conform with the spec.

For more information, see: http://tomcat.apache.org/tomcat-5.0-doc ... nager.html

But, to work around the problem, you can certainly disable this feature.
To do so, you need to create a <Context> element for the web app, and inside of it specify a <Manager> element with a empy "pathname" attribute (see above reference for more information).

The best way is to create a "context.xml" file in the META-INF directory of the application's WAR file. In the file, put somthing like this (changing "mypath" to your webapp's path):
Note: I haven't actually tested this myself, but I should work according to the documentation, so give it a try...

This is my $TOMCATHOME/JavaUploader/WEB-INF/web.xml

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">

<Context path="/JavaUploader"
docBase="$TOMCATHOME/webapps/JavaUploader"
reloadable="true">
<Manager pathname="" />
</Context>

<display-name>GCAP UpLoader</display-name>
<description>
Welcome to the GCAP UpLoader
</description>

</web-app>

Before starting JZOS task the directory $TOMCATHOME/work/Catalina/localhost/JavaUploader does not contain a file called SESSIONS.ser.

Starting and then stopping the JZOS task, without any use of the application causes the SESSIONS.ser file to be created.

Any thoughts as to why it still creates this file?
Thank you.

I don't believe that you can put the Manager tag in the web.xml. Try it the way I described above.

Thanks,
I was able to get the SESSIONS.ser files to not be created. I am not familar with the use of a WAR file. We modify the files in the various directories and than use the Tomcat Manager application to reload the application. I was unsure where to place the <Context> element. I read in someother post (not on dovetail.com) that having a "context.xml" file in the META-INF directory of the application's WAR file would cause that file to be placed in the $TOMCATHOME/conf/Catalina/localhost directory. That is where I placed my JavaUploader.xml file and it seems to work fine.

Is that the correct place to locate such a file if not using a WAR file to deploy the application?

Thanks for all your help and patience.
Dave.

Yes, that works if not using a WAR. There are several other options covered in the Tomcat docs.

We have a applicaton that uses JSP and does call a java program from which we make our calls to DB2 on z/OS. When we shutdown the JZOS task or if we reload the application using Tomcat's Manager application, we get errors about being unable to serialize and other rather nasty looking messages????

SESSIONS.ser is where Tomcat saves and restores sessions on shutdown/startup.

This is not a JZOS or z/OS related issue, so I would suggest that you research solutions to this with Google or Tomcat user support lists.