• Bug
  • Status: Resolved
  • 2 Major
  • Resolution: Won't Fix
  • teck
  • Reporter: teck
  • August 21, 2006
  • 4
  • Watchers: 2
  • September 06, 2013
  • September 06, 2013


If one shares an instance of some application scoped class (ie. something that is part of your .war, not in CLASSPATH), and then the app is hot re-deployed…the user will almost certainly be rewarded with ClassCastException. For example, if some servlet in a web app sticks an instance of some application class (say an inner class of the servlet) in shared map (a DSO root)….if that app is redeployed, the servlet will come up, try to access the root, and the instance of the inner class (which is still memory resident) will be from the prior app instance classloader…ClassCastException.

One solution (there might be others) is to flush any and all resident shared objects defined by the app being re-deployed. This implies some form of hook to the app lifecycle, and a way to crawl the space of local DSO objects looking for particular loaders.


Fiona OShea 2006-08-22

Tim, what is the level of effort in fixing this for Kirkham?

Fiona OShea 2006-08-22

Maybe related to LKC-1673

Tim Eck 2006-09-06

It is certainly too late to put a change like this into kirkham

Eugene Kuleshov 2006-09-20

Tim, please “untimebomb” RedeploymentTest from dso-spring-tests when this issue is resolved.

Fiona OShea 2007-09-28

Can you look into this for Pacheco? See what we can do about it.