0

I have a JSF page that displays a table from an object called TableQuery that supports stateful pagination, sorting, etc. The bean that accesses the object is a RequestScoped object, and it attempts to preserve the TableQuery by storing it the flash map. The accessor method looks like this:

public TableQuery<SysLog> getQuery() {
    if (query != null) return query;
    Flash flash = FacesContext.getCurrentInstance().
            getExternalContext().getFlash();
    query = (TableQuery) flash.get("Query");
    if (query != null) System.out.println("TableSysLog.getQuery() Got query from flash!");
    if (query == null) {
        query = slc.getNewTableQuery();
        System.out.println("TableSysLog.getQuery() Created new query");
    }
    flash.put("Query", query);
    return query; }

The Links to go between pages are implemented with p:commandLInks. I use Primefaces command link in AJAX mode so just the link gets processed when it is clicked. The action listener looks like this:

public void doNextPage(ActionEvent evt) {
    getQuery().doNextPage();
}

When it doesn't work I get the error message:

WARNING: JSF1095: The response was already committed by the time we tried to set the outgoing cookie for the flash.  Any values stored to the flash will not be available on the next request.

I found this thread when looking up this problem. When I turned of HTTP chunking as the article suggests, the error message went away but the problem remained.

Does anyone know what is going on and how this might be fixed?

UPDATE:

In working with this problem I believe I have uncovered a bug in how the cookie that is used to store the flash object. The cookie it stores is named csfcfc, and the path parameter to the cookie is the root of my application, in my case "/A/".

However when it fails, I get a second csfcfc cookie, this time with the path parameter as "/A//". My working theory is that the cookie generator is sometimes adding an extra "/" to the path parameter, which means that the cookie is not seen on the next request even though the browser sent it.

It is notable that this happens very intermittently. I do NOT always get the JSF1095 message but I do get the extra cookie every time I looked.

I don't know if this is a Mojarra bug or a Glassfish bug, but I am adding the Mojarra tag to this post. I am not familiar with the bug data bases for those pro.ducts, but could someone here comment on what the next step should be?

I would appreciate any suggestions for a work around

Community
  • 1
  • 1
AlanObject
  • 9,613
  • 19
  • 86
  • 142
  • AFAIK you should be (minimal) using a view scoped backing bean for your data table if you want sorting/filtering. Any particular reason why you are using this 'solution'? – siebz0r Sep 22 '12 at 09:12
  • All the state needed to maintain the table on the screen (starting record, sort terms, filter terms, page size, etc) are stored in the TableQuery object. I tried using ViewScoped but it doesn't work -- the backing bean gets re-created with every request. So if the flash scoped variable saves my state from one request until the next I am set. – AlanObject Sep 22 '12 at 16:09
  • I'm not familiar with the flash scope, but doesn't session scope provide what you're looking for? – siebz0r Sep 22 '12 at 18:06
  • Session scope beans would get the behavior I want, but the beans hang around for the whole session. If the user leaves the page and comes back, the state would still be there which is undesirable. Also that consumes unnecessary server resources with thousands of session beans. – AlanObject Sep 23 '12 at 15:46

1 Answers1

0

It turns out the problem is with Glassfish in its protocol hander as suggested by the link provided in the question. If HTML "chunking" mode is turned off, this problem goes away.

Originally I thought that this was not the case, but in fact I had another bug that was causing flash objects to be lost.

AlanObject
  • 9,613
  • 19
  • 86
  • 142