1

our customer doesn't want to have session handling with cookies and it also will cause problems with an Apache/mod_rewrite gateway, so i tried to use 

<tracking-mode>URL</tracking-mode>

in our web.xml. That should be all with Glassfish3/Servlet 3.0. However now i get ViewExpiredExceptions when trying to log in(it's not an AJAX request):

<p:commandButton id="submit"
                 value="${msg['Login.submit.label']}"
                 action="#{loginBean.login}"
                 ajax="false"/>

I also tried to save the session on the client side, than i can see the JSESSIONID in the URL but that throws NotSerializableExceptions for my @EJBs. Any ideas? Do i miss something? It used to work fine with the cookies.

UPDATE: LoginBean.login returns "Home.xhtml?faces-redirect=true", expected behaviour when clicking the commandButton: POST on Login.xhtml, my login page, redirect and GET on Home.xhtml.

SECOND UPDATE: Looks like my action never gets called, i'm directly getting the ViewExpiredException and a HTTP 500 error code.

THIRD UPDATE: Looks like the HttpSession is always null with tracking mode set to URL, with cookies the HttpSession is correctly created. Shouldn't the FacesServlet create a session and append the JSESSIONID in the URL if there is no session?

ANOTHER UPDATE: With

<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>

the session will be created on postback. But than i'm running into 

java.io.NotSerializableException

.

Hendrik Donner
  • 31
  • 5

2 Answers2

0

The other option is to set restore view compability to true.

Edit your web.xml and add following code and try. 

<context-param>
    <param-name>com.sun.faces.enableRestoreView11Compatibility</param-name>
    <param-value>true</param-value>
</context-param>

Updated:

Reference

com.sun.faces.enableRestoreView11Compatibility is a JSF 1.2 setting that tells JSF 1.2 to behave like JSF 1.1.

com.sun.faces.enableRestoreView11Compatibility == true means "do not throw a ViewExpiredException; instead, just create a new view if the old one has expired."

The IBM notes on the JSF 1.1 behaviour say:

This can have adverse behaviors because it is a new view, and items that are usually in the view, such as state, are no longer be there.

The default JSF 1.2 behaviour is defined in the spec as this:

If the request is a postback, call ViewHandler.restoreView(), passing the FacesContext instance for the current request and the view identifier, and returning a UIViewRoot for the restored view. If the return from ViewHandler.restoreView() is null, throw a ViewExpiredException with an appropriate error message. javax.faces.application.ViewExpiredException is a FacesException` that must be thrown to signal to the application that the expected view was not returned for the view identifier. An application may choose to perform some action based on this exception.

To have a ViewExpiredException thrown when the view expires, remove the com.sun.faces.enableRestoreView11Compatibility parameter or set it to false.

The com.sun namespace suggests that the parameter is a Sun/Mojarra and derived implementation-specific setting, so it probably will not work with all JSF implementations.

Community
  • 1
  • 1
Makky
  • 17,117
  • 17
  • 63
  • 86
  • What does that parameter imply? Any drawbacks/implication i should be aware of? This sounds more like a workaround, does that mean i'm doing everything right but i'm running into some bug? – Hendrik Donner May 29 '13 at 16:57
  • It is a work-around see my updated answer for more informatoin. – Makky May 29 '13 at 20:24
  • Unfortunately that does not help, i'm now staying on my login page without getting redirected to the home page. LoginBean.login returns "/Home.xhtml?faces-redirect=true" but i can't see the redirect, only a POST on Login.xhtml, my login page. – Hendrik Donner May 31 '13 at 06:18
  • Updated the original question with additional information. @BalusC – Hendrik Donner Jun 03 '13 at 07:41
  • Hendrik, I didn't answer this question, I just edited the answer and fixed some bad formatting. Look, my name is after "edited" and not after "answered". Anything which I did can be seen by clicking the "edited" link. – BalusC Jun 04 '13 at 11:39
  • @BalusC You still might have known something about the problem, otherwise you wouldn't even have had a look at the question right? Anyway problem is solved now, sorry for the noise. – Hendrik Donner Jun 04 '13 at 13:38
0

Fixed by updating Mojarra. My Glassfish 3.1.2.2 came with Mojarra 2.1.6 and this bug:

https://java.net/jira/browse/JAVASERVERFACES-2143

Updated to 2.1.22 and everything works.

Hendrik Donner
  • 31
  • 5