thought i may as well post this (even though it is long winded), as the
"ClassCastException" now seems to be under control.
its a pretty good explanation of what is going on with ClassLoaders
and session persistence....so i hope it will help someone out there...
regards,
Kate.
***********************************************************
Josh,
yes, session persistence set to true by default
JRun reads data saved in the session upon detecting a change in a .class
file. "An error is detected reading session data"
This is refers to the error with the ClassLoaders as they are refencing
"old" Class objects
"This is caused by the ClassLoader object in JDK1.3 foundation classes
(Every Class object contains a reference to the ClassLoader that defined it.
)"
so far so good
<<touchwood>>
cheers:)
Kate
***********************************************************
Glad to help.
Based on what you said below, I started thinking that it still may be
possible for you to get CCE errors of the sort I talked about if you have
session persistence set to true. After thinking it through though, I don't
think so, but here is how my thoughts went....
It's been awhile since I looked into this, but doesn't JRun automatically
persist session objects during a restart? (Maybe it doesn't...I don't
remember.) If it does, you could still have the same problem if you
updated/touched a servlet file but not a jsp file....I think.
I decided this isn't true through, because JRun does clear and instantiate
new classloaders upon restart, which is where the problem is.
Troubleshooting a technical problem is hard. Troubleshooting technical
problem caused by a "people" problem is just about impossible. :)
Goodluck,
josh
***********************************************************
Hi Joshua,
After monitoring the situation closely, it would seem a team member has
ben
updating .class files without restarting, thus causing CCE errors being
thrown when reading session data.
It certainly fits with what you said about "old file"/"new file"
references
and ClassLoaders.
I have implemented an update/compilation/restart policy for my team.
Hopefully we won't see this error again.
Thanks for all your help
:)
Kate
--------------
POLICY:
--------------
servlets:
compiled in Web-inf/classes
.class and .java files left in Web-inf/classes dir
RESTART THE WEBSERVER
supporting class files (not beans or foundation JDK classes):
compiled in Web-inf/classes dir
packaged
.class put in a folder referenced when insatntiated
.java and respective folder left in Web-inf/classes dir
then JAR the .java file
(** please note any servlets that reference this package must be compiled
before placing the .class file in the folder **)
RESTART THE WEBSERVER
beans:
compiled in Web-inf/classes dir
packaged
.class put in a folder referenced when insatntiated
.java and respective folder left in Web-inf/classes dir
then move the .java and the folder to the Web-inf/lib dir
(** please note any servlets that reference this package must be compiled
before placing the .class file in the folder or moving the ntire object to
the /lib dir**)
RESTART THE WEBSERVER
***********************************************************
Hello,
ClassCaseException can happen for numerous reasons when using beans. In
our
situation, we've already dealt with every common reason for
ClassCaseException. If you're sure you have and understand the
complexities
of it, then you might have the same problem. More likely though, your
problem is different. Some possible things to check first: Is your
bean
and the entire object tree it references serializable? (Check the log
files)
How are you storing the bean? If you are using JSP declarative syntax,
then
the SP1 supposedly fixed some isses with beans in sessions and CCE.
If you checked everything though, we're fairly confident we figured out
the
problem.
It seems to be related to how JRun is handling its class loaders with
respect to JSP, Beans, and servlet classes. The class loader appears to
only reload a "new" class when the class is directly requested, but not
when
it is forwarded to.
So, if you update a jsp page, "hit" the jsp page so that it is reloaded,
then "hit" an "old" servlet that forwards to the JSP page, a
ClassCastException occurs because the servlet is using an old class of
the
JSP page. (This example might not be entirely correct, but something
similar.)
In our case, we wanted to be able to do hot deployments. The solution
would
be to programmatically "hit" every resource after a site update, so that
every resource is reloaded with new class versions. (In our site,
certain
resources are not normally accessed accept via request.forward(...),
which
is what causes the problem.) We haven't had time to so this, but in
theory
it would work.
Kind-of confusing, yes? :) It's really late on Sunday here in Missouri,
USA. So if you want some more detailed explanation of how we came up
with
this theory, let me know, and I'll get back to you sometime in the next
few
days.
Sincerely,
Joshua
***********************************************************
Hi Joshua,
I have been reading your post reagrding the infamous
"ClassCastException" on
the Allaire site:
Subject: ClassCastExceptions Preventing 'Hot' Deployment
Have you guys ever manage to sort out this problem?
..as I am experiencing this exact same thing at the moment.
My beans seems to throw the CCE err on session timeout
Thanks,
Kate
____________________________________________________________________________
________________________________________
IMPORTANT: This email is intended only for the use of the individual or
entity named above and may contain information that is confidential and
privileged. The views expressed in this e-mail are those of the author and
not of the company unless otherwise clearly indicated. When addressed to
our clients, any information or quotes contained in this e-mail are subject
to the terms and conditions relevant at that time to the matter being
addressed. If you are not the intended recipient and have received this
e-mail in error, please notify us immediately by return email or telephone
+61 8 93235555 and delete the e-mail and any attachments without using or
disclosing the contents in any way. If you are not the intended recipient
any dissemination, distribution or copying of this e-mail is strictly
prohibited. Before opening or using attachments, check them for viruses and
defects. Our liability is limited to re-supplying any affected attachments.
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
