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.

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

Add sessionless @ViewScoped #330

Closed
instantiationexception opened this Issue Nov 19, 2016 · 6 comments

Comments

Projects
None yet
3 participants
@instantiationexception

instantiationexception commented Nov 19, 2016

When using state saving method client, JSF 2.2 has very unpleasant surprise: @ViewScoped beans are stored in session. For good user experience it is unacceptable. It would be great if application using @ViewScoped and state saving method client behaved like normal web application - user opens some page, goes out for a walk, returns to computer and everything just works. It would help a lot of people if OmniFaces @ViewScoped had some attribute to control this behavior or OmniFaces had some servlet context parameter.

For me it is real blocker because I architected nontrivial application believing that JSF stores nothing in session when state saving method is set to client. I am not sure if I would pick JSF for a project knowing about this issue.

StackOverflow answer about this behavior: http://stackoverflow.com/a/10508127/371676
Comment in JIRA: https://java.net/jira/browse/JAVASERVERFACES-2561?focusedCommentId=368722&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-368722

@BalusC

This comment has been minimized.

Show comment
Hide comment
@BalusC

BalusC Nov 25, 2016

Member

In other words, when javax.faces.STATE_SAVING_METHOD is set to client, you'd like to have @ViewScoped beans physically stored in JSF view state rather than in HTTP session.

This is certainly understandable and indeed doable via some @ViewScoped annotation attribute. It will only require a big blinking warning that you shouldn't be storing "too much" data in the view scoped bean in question. The bean's data should be carefully reviewed and if necessary mark it transient or split into another bean which isn't stored in view state. E.g. the data of a lazy loaded datatable doesn't need to be saved in JSF state. Really only UI state things like ajax-controlled rendered/disabled/readonly/hidden attributes.

Member

BalusC commented Nov 25, 2016

In other words, when javax.faces.STATE_SAVING_METHOD is set to client, you'd like to have @ViewScoped beans physically stored in JSF view state rather than in HTTP session.

This is certainly understandable and indeed doable via some @ViewScoped annotation attribute. It will only require a big blinking warning that you shouldn't be storing "too much" data in the view scoped bean in question. The bean's data should be carefully reviewed and if necessary mark it transient or split into another bean which isn't stored in view state. E.g. the data of a lazy loaded datatable doesn't need to be saved in JSF state. Really only UI state things like ajax-controlled rendered/disabled/readonly/hidden attributes.

@instantiationexception

This comment has been minimized.

Show comment
Hide comment
@instantiationexception

instantiationexception Nov 25, 2016

In other words, when javax.faces.STATE_SAVING_METHOD is set to client, you'd like to have @ViewScoped beans physically stored in JSF view state rather than in HTTP session.

Exactly.

It will only require a big blinking warning that you shouldn't be storing "too much" data in the view scoped bean in question.

I am prepared for that.

instantiationexception commented Nov 25, 2016

In other words, when javax.faces.STATE_SAVING_METHOD is set to client, you'd like to have @ViewScoped beans physically stored in JSF view state rather than in HTTP session.

Exactly.

It will only require a big blinking warning that you shouldn't be storing "too much" data in the view scoped bean in question.

I am prepared for that.

@arjantijms

This comment has been minimized.

Show comment
Hide comment
@arjantijms

arjantijms Nov 26, 2016

Member

For what it's worth, this exact issue was also discussed for JSF 2.3, but severely lacking resources nobody took this up.

One approach that we briefly explored was having a distinction between cache and state. State attributes would be saved (in the client state), cache attributes would not, and could be session based with some dedicated method to restore them.

In how far existing mechanisms (transient, loader methods and postconstruct among others) are already sufficient to implement such pattern was left open to investigate.

Member

arjantijms commented Nov 26, 2016

For what it's worth, this exact issue was also discussed for JSF 2.3, but severely lacking resources nobody took this up.

One approach that we briefly explored was having a distinction between cache and state. State attributes would be saved (in the client state), cache attributes would not, and could be session based with some dedicated method to restore them.

In how far existing mechanisms (transient, loader methods and postconstruct among others) are already sufficient to implement such pattern was left open to investigate.

@instantiationexception

This comment has been minimized.

Show comment
Hide comment
@instantiationexception

instantiationexception Nov 26, 2016

One approach that we briefly explored was having a distinction between cache and state. State attributes would be saved (in the client state), cache attributes would not, and could be session based with some dedicated method to restore them.

Sounds great, but at the beginning even the simplest solution is better than nothing :)

instantiationexception commented Nov 26, 2016

One approach that we briefly explored was having a distinction between cache and state. State attributes would be saved (in the client state), cache attributes would not, and could be session based with some dedicated method to restore them.

Sounds great, but at the beginning even the simplest solution is better than nothing :)

@BalusC BalusC closed this in fe73ed1 Dec 18, 2016

@BalusC

This comment has been minimized.

Show comment
Hide comment
@BalusC

BalusC Dec 18, 2016

Member

Use @ViewScoped(saveInViewState=true) to activate this.

Important consideration is that those beans will never expire (this is technically not controllable from server side on due to e.g. client side caching/copies/target=_blank/etc) and therefore @PreDestroy will also never be invoked on those beans.

Noted should be that the integration test has a HttpSessionListener which should cause an IT fail when a session has unintentionally been created during the test. In other words, this is proven to be entirely sessionless.

Member

BalusC commented Dec 18, 2016

Use @ViewScoped(saveInViewState=true) to activate this.

Important consideration is that those beans will never expire (this is technically not controllable from server side on due to e.g. client side caching/copies/target=_blank/etc) and therefore @PreDestroy will also never be invoked on those beans.

Noted should be that the integration test has a HttpSessionListener which should cause an IT fail when a session has unintentionally been created during the test. In other words, this is proven to be entirely sessionless.

@instantiationexception

This comment has been minimized.

Show comment
Hide comment
@instantiationexception

instantiationexception commented Dec 19, 2016

Great! Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment