Hi nalani,
When your JSP needs to be recompiled, the Server has to create and use a new class-loader to ensure that the older classes are
dropped, and the newer classes are used instead. This is a workaround for a 'characteristic' of the Java class loader. If you
define a custom class and that class is loaded from the servlet classpath, it is also loaded by the same class loader that loaded your generated JSP servlet. Of course, that class loader is destroyed when the JSP is reloaded, and the custom class must
also be reloaded.
Now, when you attempt to retrieve the custom class from the HTTP session, you get a ClassCastException since it was loaded by a
different class loader. Although the classes may be the same logically, they have been loaded by different class-loaders,
and are regarded by the JVM as incompatible.
Workaround for this solution is:
==============================
Catch the ClassCastException, and replace the old class that is stored in the session
with a newly instantiated class, or remove it from the session. Unfortunately, you will lose the session data that was
previously stored inthe class, so you should write your application to handle this scenario.
This is the easiest solution to the problem -- remember that you should not be storing critical information in an HTTP session,
but rather storing it in a database.
The above exception will generally occur whilst you are developing your servlets, and should not be an issue in a
stable production system
Regards,
Tirumalarao
Developer Technical support,
Sun Microsystems,India.