Thanks for your quick response. I dont think we do have exactly the same situation but I will check with our customer if the server was restarted at all.
To better understand the whole request setup process, could you give me a quick idea of what kind of data is handled here in _propertySource = (IPropertySource) servletContext.getAttribute(name); I still dont understand where in our tapestry application to search for a potential class cast mismatch. joerg -----Original Message----- From: Johan Maasing [mailto:[EMAIL PROTECTED] Sent: Mon 5/2/2005 23:29 To: Tapestry users Cc: Subject: Re: ClassCastException in setupForRequest() [HELP...] > Hi , > > we are facing a serious problem at a customer's production site, which makes > it hard > for us to debug. We are getting a ClassCastException in setupForRequest at > > _propertySource = (IPropertySource) > servletContext.getAttribute(name); I do not have any good ideas but I recognize the situation (non-tapestry app). In our case the web application was unloaded, replaced with a new version and then re-deployed. Since weblogic was running the whole time the JVM was never interrupted. This caused problems with our property classes. They were static singletons so they were not unloaded when the web application was unloaded. However, the new version of the application changed the property classes. This meant that that the classloader considered the old live instances not the same class as the new versions. So, I guess that a question would be if your problems occurs on a newly started server or only when you have restarted an application? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
