ClassCastException in AbstractEngine.setupForRequest()

[Werner Lehmann <le...@media-interactive.de>]

Hi,

we still have a problem with ClassCastExceptions thrown in 
AbstractEngine.setupForRequest(). The problem appears only at a customer 
- and we cannot reproduce it here. The situation becomes more and more 
desperate :-(

This is the offending line:

>  _propertySource = (IPropertySource) servletContext.getAttribute(name);

...and the respective stack trace:

> 2005-06-09 15:06:44,015 WARN  [ExecuteThread: '9' for queue: 'weblogic.kernel.Default'] org.apache.tapestry.engine.AbstractEngine(508) - Tapestry unable to begin processing request.
> java.lang.ClassCastException
> 	at org.apache.tapestry.engine.AbstractEngine.setupForRequest(AbstractEngine.java:1288)
> 	at org.apache.tapestry.engine.AbstractEngine.service(AbstractEngine.java:841)
> 	at org.apache.tapestry.ApplicationServlet.doService(ApplicationServlet.java:198)
> 	at org.apache.tapestry.ApplicationServlet.doGet(ApplicationServlet.java:159)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> 	at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:971)
> 	at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:402)
> 	at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28)
> 	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
> 	at org.apache.tapestry.RedirectFilter.doFilter(RedirectFilter.java:106)
> 	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
> 	at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6356)
> 	at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
> 	at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
> 	at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3635)
> 	at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2585)
> 	at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
> 	at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)

This is with the 3.0.3 tapestry release (line numbers in AbstractEngine 
do not match because we added some log output). According to additional 
logs this same code is executing _just fine_ for 4 hours. Then suddenly, 
the exception is thrown. The main suspect on this issue is something 
related to the class loader. However, the log output shows which 
classloader (and classloader instance) is used and it did not change all 
the hours before the exception comes up.

For what it's worth: according to the log, the object to be casted, 
servletContext.getAttribute(name), returns this for getClass().getName():

> org.apache.tapestry.util.DelegatingPropertySource

And its class loader, provided by getClass().getClassLoader(), is this:

> weblogic.utils.classloaders.ChangeAwareClassLoader

The log also contains the hashcode, e.g. @1c719bd for the attribute and 
@1ce6303 for the class loader and both did not change for hours.

I am not sure but... do all of our persistent component & page 
properties need to be serializable? As this is currently not the case 
for each and every one of them.

Could this be related to WebLogic 8.1 Sp2? As the problem does not occur 
on a plain Tomcat 4... The WebLogic docs state this:

> When your applications stores data in an HTTP session object, the data must be serializable.

So, are those tapestry persistent properties on components and pages 
stored into the HTTP session object and must therefore be serializable?

Any ideas on how to proceed on this are greatly appreciated!

Werner

PS: this is a follow up on
http://mail-archives.apache.org/mod_mbox/jakarta-tapestry-user/200505.mbox/
%3cE1DShpU-0007II-00@mrelayng.kundenserver.de%3e
(mind the word wrap)


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org

Re: Tapestry framework and thread issues on pages

[Pablo Ruggia <pr...@gmail.com>]

Same page can get activated to many different users, but you can make 
properties "persistents", so that property will be stored for some user, and 
only this user. If that user gets a different page instance, the property 
value will still be the same.



On 6/13/05, sarah.simbad@women-at-work.org <sa...@women-at-work.org> 
wrote:
> 
> >It's thread safe. But it will NOT WORK. The same user for different
> >request can get different Page instances. And different users can get
> >the same page instance.
> 
> So whats the point of the tapestry framework then? I thought this
> was exactly the kind of "plumbing work", Tapestry wants to avoid ?
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> 
>

Tapestry framework and thread issues on pages

[sa...@women-at-work.org]

>It's thread safe. But it will NOT WORK. The same user for different 
>request can get different Page instances. And different users can get 
>the same page instance. 

So whats the point of the tapestry framework then? I thought this
was exactly the kind of "plumbing work", Tapestry wants to avoid ?

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org