You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shale.apache.org by Richard Eggert <re...@proteus-technologies.com> on 2007/08/10 18:48:42 UTC

Anomalies with @Prerender

I've been seeing weird problems with the invocation of @Prerender/prerender() methods and the handling of request-scoped backing beans.  

I have a HTML-templated page rendered with Clay, and a corresponding request-scoped backing bean annotated with @View.  The backing bean has a method annotated with @Prerender that extracts a value from the request parameter Map.  If the value has been set (via a URL parameter), the method uses it to initialize a property of the backing bean.  For postbacks to the page, the value is preserved using a Tomahawk saveState component.

We have four developers each running their own development instance of WebLogic Server 9.2.  For two of us, everything works perfectly.  However, for the other two, if the user loads the page twice in a row in different windows (or the same window) with different values for the URL parameter (or even the same value), the @Prerender-annotated method is only called during the first load, and the second instance of the page ends up with the same bean property values as the first.  A custom PhaseListener that has been set up to run before the RENDER_RESPONSE phase in order to set values in the HTTP response header does run both times, however.  Additionally, loading a separate page before loading this page the second time causes the @Prerender to work properly.

In other words:

Load pageA?param=1 in window 1.
Load pageA?param=2 in window 2.
Window 2 contains the same content as window 1, and checking the log reveals that prerender was called for window 1 but not for window 2.

Load pageA?param=1 in window 1.
Load pageB in window 3.
Load pageA?param=2 in window 2.
Window 2 contains content relevant to param=2, and checking the log reveals that prerender was called for both windows.

Getting rid of the @View and @Prerender annonations and having the backing bean extend AbstractViewController had no effect, so the problem does not appear to be with shale-tiger's ViewController support (unless it is somehow interfering with the regular non-tiger ViewController support).  

Changing the STATE_SAVING_METHOD from "server" to "client" seems to fix the problem.

We are using MyFaces 1.1.4 and Shale 1.0.4.

Any idea of what might be causing this behavior?

Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com