Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

View not destroyed when closing browser tab on page backed by omnifaces @ViewScoped #208

Closed
wfsaxton opened this issue Feb 11, 2016 · 6 comments
Closed

View not destroyed when closing browser tab on page backed by omnifaces @ViewScoped #208

wfsaxton opened this issue Feb 11, 2016 · 6 comments

Comments

@wfsaxton
Copy link

I set the view/logical view limits to 3 and deployed a simple JSF page with omnifaces ViewScoped backing bean. Closing tabs does not appear to do anything. I would have expected the secondary beans to have been destroyed so that the first bean is never automatically expired.

I'm using GF 4.1, JSF 2.2, Omnifaces 2.2

Steps to reproduce:

  1. Open viewBean.xhtml in one tab
  2. Open viewBean.xhtml in another tab, close the tab
  3. Open viewBean.xhtml in another tab, close the tab
  4. Open viewBean.xhtml in another tab, close the tab
  5. Open viewBean.xhtml in another tab, close the tab
  6. On the original tab, click the button. Get the following error:

javax.faces.application.ViewExpiredException: viewId:/viewBean.jsf - View /viewBean.jsf could not be restored.

web.xml:

    <context-param>
        <param-name>com.sun.faces.numberOfViewsInSession</param-name>
        <param-value>3</param-value>
    </context-param>

    <context-param>
        <param-name>com.sun.faces.numberOfLogicalViews</param-name>
        <param-value>3</param-value>
    </context-param>

ViewBean.java:

package com.example.zunload;

import java.io.Serializable;
import javax.inject.Named;
import org.omnifaces.cdi.ViewScoped;

@Named
@ViewScoped
public class ViewBean implements Serializable {

    String testString = "Hello World";

    public ViewBean() {
    }

    public String getTestString() {
        return testString;
    }

    public void listener() {
        System.out.println("Do this");
    }
}

viewBean.xhtml:

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://xmlns.jcp.org/jsf/html">
    <h:head>
        <title>TODO supply a title</title>
        <meta name="viewport" content="width=device-width, initial-scale=1.0"/>
    </h:head>
    <h:body>
        <div>#{viewBean.testString}</div>

        <h:form>
            <h:commandButton value="Submit" actionListener="#{viewBean.listener}"/>
        </h:form>
    </h:body>
</html>
@wfsaxton wfsaxton changed the title View not destroyed when closing browser tab on page using @ViewScoped View not destroyed when closing browser tab on page backed by omnifaces @ViewScoped Feb 11, 2016
BalusC pushed a commit that referenced this issue Feb 11, 2016
#208: Fire PreDestroyViewMapEvent instead of manually calling it.
b79fe6b 
Unfortunately neither Mojarra nor MyFaces would clean up server side
view state on this, but this is at least a start.
@BalusC
Copy link
Member

BalusC commented Feb 11, 2016

Reproduced. Nice find. Unfortunately, neither Mojarra nor MyFaces keeps server side view state "in sync" with PreDestroyViewMapEvent, so those server side view states still stick around. Your best bet is using client side state saving instead.

Theoretically, we could solve this by providing our own server side state manager, but this is not a trivial task. I'd rather first look how the JSF API itself can be improved with regard to this.

BalusC pushed a commit that referenced this issue Feb 11, 2016
#208: add hack to explicitly remove Mojarra server side view state.
e5925c1
@BalusC
Copy link
Member

BalusC commented Feb 11, 2016

For now, I added a hack to explicitly remove Mojarra's server side view state. Your use case now works fine for me. It's available in today's 2.3 snapshot.

Will look at MyFaces later.

@wfsaxton
Copy link
Author

Thank you, @BalusC I assume no release date for 2.3 as it will be released "when its good and ready" !

@BalusC
Copy link
Member

BalusC commented Feb 12, 2016

When I'm 100% satisfied with o:socket. It's getting close :)

BalusC pushed a commit that referenced this issue Feb 12, 2016
#208: MyFaces has sometimes URL-invalid chars in view state id
576bc8b
BalusC pushed a commit that referenced this issue Feb 12, 2016
#208: add hack to explicitly remove MyFaces server side view state
c54d004
@BalusC
Copy link
Member

BalusC commented Feb 12, 2016

MyFaces way of keeping track of views is kind of convoluted (see last commit), but your use case now also works fine for me in MyFaces.

@BalusC
Copy link
Member

BalusC commented Feb 12, 2016

It's available in today's 2.3 snapshot.

@BalusC BalusC closed this as completed Feb 12, 2016
BalusC pushed a commit that referenced this issue Feb 12, 2016
#208: tested and further improved MyFaces view state destroy
b881269
BalusC pushed a commit that referenced this issue Feb 13, 2016
#208 refactor deep nested structure
3921fce
BalusC pushed a commit that referenced this issue Feb 15, 2016
#208: Further improved view scope destroy, it will now also destroy any
174f21c 
JSF own view scoped beans (javax.faces.bean/view.ViewScoped) associated
with the view (only if the view has an OmniFaces CDI view scoped of
course). Also, any component event listeners on UIViewRoot will be
restored and those listening on PreDestroyViewMapEvent will be invoked.
BalusC pushed a commit that referenced this issue Feb 15, 2016
#208: extra safety checks on state structure
97c4378
BalusC pushed a commit that referenced this issue Mar 8, 2016
#208: make it work with h:commandLink (worked with h:commandButton only)
6576254
BalusC pushed a commit that referenced this issue Mar 8, 2016
#208: tested showcase on MyFaces, fixed a corner case with unload script
f97b741 
(MyFaces autogenerated an ID which wasn't re-generated in postback,
causing corrupted view state during unload)
BalusC pushed a commit that referenced this issue Mar 15, 2016
#208: Fixed corner case bug when stateless JSF is used with @ViewScoped
56c9700 
(though using @ViewScoped beans in stateless JSF doesn't make sense)
BalusC pushed a commit that referenced this issue Mar 18, 2016
#208: document 2.3 changes as to @ViewScoped unload
7b345ef
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@BalusC @wfsaxton