Hi
Hope the following extract from weblogic doucmentation helps.
Note: (this is more of a general rather than weblogic specific problem)
http://www.weblogic.com/docs45/classdocs/API_servlet.htm
<extract>
The dreaded ClassCastException !
This will invariably jump up and bite you at some point when you start using
HTTP sessions seriously, and so deserves the title. Here's what happens...
1. You store a reference to a custom class in an HTTP session. Let's call
your custom class myFoo.
2. Whilst in mid-session, you change your servlet (or JSP or JHTML), causing
it to be reloaded. In fact, it is necessary for it to be reloaded by a
completely new class loader, and the old class loader that had previously
loaded it must be discarded.
3. Since your custom class myFoo is also located under the servlet
classpath, it too is reloaded by the new class loader.
4. Now, when you retrieve myFoo from the HTTP session, you cast it to the
expected type, but you recieve a ClassCastException. The exception is thrown
even if class myFoo has not changed. Since it has been loaded by a different
class loader, it is regarded by the JVM as incompatible.
Note that if you are using session persistence, the class contents must be
serialized, hence you will not see this issue.
Here are some suggested work arounds to this problem:
Do not place your class myFoo in the servlet classpath. Instead, place it in
the system classpath or the weblogic.class.path that are accessible by the
WebLogic Server; it won't be reloaded when the servlet is modified. This
solution has the drawback that you can't prototype the myFoo class, since
you must restart the server in order to reload the class after it is
modified.
If you need to prototype the class, you could write a wrapper method within
it to store and retrieve its contents to and from the session. You don't
access the class directly from the session, but instead call it's wrapper
methods to store or populate it's contents from the session. So long as you
use standard Java class types to store the class contents, they will not be
reloaded when the servlet is reloaded. This approach has performance
drawbacks since your wrapper methods would need to set or get multiple
name=value pairs for each of your class's attributes.
Another workaround is to 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 in the 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. If you
are upgrading your system online, we advise that you warn your customer
base.
</extract>
Sriram Narayan
CTS - Pune
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
