Messages posted by: greg.dick  XML
Profile for greg.dick -> Messages posted by greg.dick [36] Go to Page: 1, 2, 3 Next 
Author Message
This is an issue with Spring Webflow version 2.3.0. Starting at version 2.1.0-b3 or thereabouts, JSF introduced several new methods in FacesContext whose default implementation was to throw this exception.

Spring has not yet released a new version of webflow to override these methods, but a new version is coming soon (ish?).


Can you describe you error in more detail? JSFUnit uses a special version of the FacesContext that sticks a reference to itself into the session with a specific key. The intent is for other code from outside the server to have access to this instance of the FacesContext used during the lifecycle.

This mechanism has worked in the past and we have used JSFUnit with ICEFaces since March '09, although we don't find it much more useful than regular HTMLUnit.


I'm looking at the posted code in an effort to introduce this into the codebase and I'm wondering why the isSpringSecurityEnvironment method in SeamUtilities checks for the existence of an initialized security context? Is it not enough to just determine the presence of Spring security classes? Is it likely that Spring security classes will be present without an active security context?

There is an onPageUnload handler in the bridge javascript that sends a request similar to the following whenever the page is unloaded: leaving the app, exiting the browser, and reloading are all examples of this. If automated load testing tools are testing things like reload, it's important for their scripts to be written to include this type of view disposal request as a regular part of the transaction.

 POST /auctionMonitor/block/dispose-views HTTP/1.1
 Host: localhost:9090
 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2009021910 Firefox/3.0.7
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 Accept-Language: en-us,en;q=0.5
 Accept-Encoding: gzip,deflate
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
 Keep-Alive: 300
 Connection: keep-alive
 Content-Type: application/x-www-form-urlencoded; charset=UTF-8
 Referer: http://localhost:9090/auctionMonitor/
 Content-Length: 50
 Cookie: JSESSIONID=088E8BBE275E65FD6FF64CB69239C357; ice.sessions=CchB5-ZMfvzdM93zBlcqvA#1; updates=; ice.lease=1244578670462; bconn=CchB5-ZMfvzdM93zBlcqvA:1:acquired
 Pragma: no-cache
 Cache-Control: no-cache

The client sends the above message for each View opened by the client and the request body contains the following:

Have you defined any of the following context-params in your web.xml?

If you are using a load testing client with concurrentDOMViews= true, you will need to support the dispose views mechanism otherwise resources will accumulate on page reload. Let me know what settings you have and I can run a quick profiling session to check things out.


We have found HtmlUnit works very well. JSFUnit uses a special FacesContext to get the FacesContext from the server to the client side test code. There was an issue with FacesContext delegation (fixed in 1.8.0) that addressed this.

Can you provide a little bit more detail about your application and about when you see this issue? I gather it's an asynchronous facelets application... does the problem occur only after restarting the server with existing clients visiting the application, or do you see it at other times as well?

If you clear the Authenticated Session cache (in Firefox) do the missing ice.session messages stop?

In the logging section you provided above, can you estimate how many clients you have running? I'm curious because of the number of error messages seen in each second.

The component behaviour is expected. If the tabset is maintaining state in the component itself (rather than a session scoped backing bean) when the component is recreated because of the GET/reload the state will be lost. This is similar to stock JSF 1.2.

What is curious is the null ViewRoot. What gets rendered in this case? Can you go back a bit and describe this:

The PhaseListener reads getParameters, injects values into beans and navigates to the corresponding tabPage and removes getParameters with the help of a redirecting navigationCase.  

in a bit more detail.

The ViewRoot definitely will be populated at that point, it has to be in order for the components to be rendered. The component hierarchy will be reconstructed in the RestoreView phase.

Are you fetching the ViewRoot from the current FacesContext for the request when necessary?

I think you'll also want to release the FacesContext thread local as well in your releaseState method. I think this is why (as mentioned in the Jira) the FacesContext variable is not showing up null.

I just read your comment in the Jira. You are still finding the thread there never completes?

The components do not send the action field on partial submit, as the protocol capture shows. I don't think you really want to send this particular event to the server in any case. Using the action attribute is, of course, a shortcut to define the navigation outcome without returning it from the actionListener, but you don't want to navigate based on partial submit. Partial submit is a way of submitting values from certain components in a form without validating the other component values from the same form.

An example of this would be submitting a single character from a city input text field to do city lookups in a database without executing JSF validation on the rest of the fields in the form. To use this to generate navigable outcomes would be a misuse of the feature since validation wouldn't occur on the rest of your fields.

I saw your note in the Jira. Perhaps it is my test that is too simple. The ThreadLocal instance of FacesContext (which is what FacesContext.getCurrentInstance() fetches) should have been released and should be null if called outside a JSF lifecycle. My actionHandler for a button that I press just starts a thread and when the thread runs, the FacesContext instance is always null until I call execute() from that thread.

Your action handler then, does it inherit ThreadLocals from the request thread or something?
I've created a Jira for this issue: http://jira.icefaces.org/browse/ICE-4251

The problem lies in there not being a JSF lifecycle running during the processing of these calls. This restores the View normally and is required for all server push operations, which operate in the absence of a user request.

Your workaround solves this problem for the purposes of navigation, but I can't promise that it will work for any/all types of interaction you might try to do with/to the framework from your long running thread. I'm a little bit astonished that you have a FacesContext.

I did some investigation into 2.0.5 compatibility and we've opened a Jira http://jira.icefaces.org/browse/ICE-4200 for this issue.

I found a workaround that allows the booking example to work. It involves adding a FlowViewHandler to the application faces-config.xml file as follows:

         <!--#4200 define another Spring ViewHandler -->

This workaround works in 2.0.3 as well. Admittedly it does instantiate a second FlowViewHandler which is a bit of a problem with framework builders putting faces-config.xml files in their distribution jars (which we do as well).

There are also a few tips at http://jira.icefaces.org/browse/ICE-4186 about the correct setting for the redirect-on-pause setting.

Perhaps someone could try this workaround?

In general, there's no need to set the partial submit flag to true on either a single input field or the last input field in a sequence of fields. If you have a series of fields of input it would be valid to have the partial submit flag set to true for all but the last. This could be used to trigger server validation of all fields as they are entered and tabbed out of.

Doing this for the last field in a set, or a single field serves no real purpose and can be turned off.
Profile for greg.dick -> Messages posted by greg.dick [36] Go to Page: 1, 2, 3 Next 
Go to:   
Powered by JForum 2.1.7ice © JForum Team