The scenario is this: JSP page creates a an object and puts it in a session. A servlet handles the action of a form and retrieves the object from the session. The class of the session object in the session has not changed and is located in the web-inf directory.
If I recompile the servlet, it will give me a class cast exception. Sometimes if I compile an unrelated class. It will still throw a ClassCastException forcing me to restart Tomcat everytime I recompile. Seems like a bug, or maybe something that could be done differently to facilitate development. -Dave -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 12, 2001 1:55 PM To: Tomcat Users List Subject: Re: class cast exception On Wed, 12 Dec 2001, Durham David Cntr 805CSS/SCBE wrote: > Date: Wed, 12 Dec 2001 13:48:19 -0600 > From: Durham David Cntr 805CSS/SCBE <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: class cast exception > > I receive a class cast exception pulling something out of a session > after I recompile a servlet. > > The object I'm pulling out of the session is of a class that has not > changed. i.e. I changed a servlet not the class of an object in the > session. Restarting Tomcat fixes the problem. This seems like a bug to > me, has anyone else noticed this behavior? > This will absolutely happen if you are using classes out of a shared library directory instead of within the webapp, or if you are somehow maintaining references to object instances created with the old class and trying to use them after the reload. > > > David Durham > Programmer Analyst, NCI Information Systems > 805th AMC / SCBE > (618) 256 - 5264 > Craig -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]> -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
