Provide stateless mode for JSF

[eclipse-faces-bot]

As documented and implemented here, a Stateless JSF operation mode would be incredibly useful for high-load applications and architectures:

http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead/#comment-4

This has previously been suggested by Jacob: http://weblogs.java.net/blog/jhook/archive/2006/01/experiment_goin.html

This would help JSF ditch the stigma of "slow and memory hog," and help keep up with current tech trends (statless architectures.)

[eclipse-faces-bot]

@glassfishrobot Commented
Reported by lincolnbaxter

[eclipse-faces-bot]

@glassfishrobot Commented
@arjantijms said:
Strongly in support of this. Internally for my company I have been working on something similar and preparing a proposal, but the referenced article is far more complete than that

For stateless operation, I think it's important to fix some state related bugs like JAVASERVERFACES-2244.

Additionally, some (standard) components make too liberal use of view state for the purpose of caching data. For instance, UIInput puts emptyStringIsNull and validateEmptyFields in view state, but these seem to be global things that don't necessarily belong there.

The simplest case for stateless operation is probably the initial rendering of a view and posting that back. There is often no state there then (besides the state caused by bugs), yet in the current spec posting it back requires view state to be restored, even when that view state appears to be empty (null) later on. This situation could perhaps be easily supported by giving the existing javax.faces.ViewState input element that's rendered a special value like "nostate" or simply leaving it empty?

One concern is that currently the required view state functions as a kind of implicit CSRF protection, so this should perhaps only be done when the user explicitly marks a view as allowed to be accepted without view state?

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
While this is very important, I have to leave the Fix Version for this as "unknown" for now because I haven't figured out how to slot it into the work for JSF 2.2.

[eclipse-faces-bot]

@glassfishrobot Commented
@arjantijms said:
Although principally asking for a different thing, #776 is somewhat related to this.

#478, #879 and #1056 are likely affected by this topic as well.

Maybe interesting that historically #139 seems related to this.

[eclipse-faces-bot]

@glassfishrobot Commented
rajkumar.w93 said:
Is this going to be there in JSF 2.2 ?

[eclipse-faces-bot]

@glassfishrobot Commented
ertiop93 said:
+1 for this superb thought!

Btw, when is this expected to be available ?

[eclipse-faces-bot]

@glassfishrobot Commented
dueni said:
I think a proposed stateless mode should work also in a mixed mode to allow e.g. stateless templates to be reused from stateful page content. Of course it should also be possible to have fully stateless views.

[eclipse-faces-bot]

@glassfishrobot Commented
ertiop93 said:
Any progress on this ?

Can we have the fix version stated for this issue ? We wish to see it implemented soon

[eclipse-faces-bot]

@glassfishrobot Commented
@arjantijms said:

Can we have the fix version stated for this issue ? We wish to see it implemented soon

Much as I would love this to be available today, my guess is this will be rather hard to still stuff into 2.2. As this is such an important issues (IMHO, one of the most important issues), it should be given the attention such a fundamental new feature needs.

[eclipse-faces-bot]

@glassfishrobot Commented
exabrial said:
Since this is a major items and the LOE is bigger... instead could we perhaps prioritize tickets like the following:

http://java.net/jira/browse/JAVASERVERFACES-2244 UIInput and UIData create unnecessary state array

My thoughts are if we can't eliminate state quite yet, can a review be conducted of existing classes so that they uses state and partial state more efficiently?

[eclipse-faces-bot]

@glassfishrobot Commented
@arjantijms said:

Since this is a major items and the LOE is bigger... instead could we perhaps prioritize tickets like the following:

Well at least JAVASERVERFACES-2244 has been closed, yah! Many thanks to Manfred

There are definitely some implementation issues regarding state that could get some more attention, like those I mentioned above in JAVASERVERFACES_SPEC_PUBLIC-1055#325459

[eclipse-faces-bot]

@glassfishrobot Commented
bohl_-. said:
f:viewParam breaks in Stateless JSF mode. There is a line in RestoreViewPhase.java which causes all phases after RestoreViewPhase to get skipped. After removing it, f:viewParam worked as expected. Does anyone know what the following line is supposed to do:

if (!facesContext.isPostback()) {facesContext.renderResponse();}

(line 158 in rev. 10973 of RestoreViewPhase.java) See also https://github.com/methylene/futil-square-validator/tree/jsfun

[eclipse-faces-bot]

@glassfishrobot Commented
vjsingh said:
Briefly as per Java EE 6 tutorial:

The lifecycle handles two kinds of requests: initial requests and postbacks. An initial request
occurs when a user makes a request for a page for the first time. A postback request occurs when
a user submits the form contained on a page that was previously loaded into the browser as a
result of executing an initial request.
When the lifecycle handles an initial request, it executes only the Restore View and Render
Response phases, because there is no user input or actions to process. Conversely, when the
lifecycle handles a postback, it executes all of the phases.

[eclipse-faces-bot]

@glassfishrobot Commented
exabrial said:
The goal of this ticket is to reduce overhead of the restore view, because it doesn't scale very well.

So on a completely different note, since we're dealing with component trees and recursive traversals, has anyone given thought to perhaps parallelizing the build/restore lifecycle phases? Seems like this could potentially be passed off to the fork/join framework. I know this wouldn't reduce the overhead, but it could make them more bearable.

[eclipse-faces-bot]

@glassfishrobot Commented
bohl_-. said:
It appears that, in case the view contains an f:metadata tag, all 6 lifecycle phases are executed, even on an initial request. I updated the SJSF demo project, it now has a PhaseListener to track the executed lifecycle phases and display that information. Also added a new branch to highlight the default JSF behaviour, without SJSF

[eclipse-faces-bot]

@glassfishrobot Commented
adynn93 said:
I believe, this feature is the major & most important need of JSF for high performance applications. It is simply a waste to save state redundantly when there is no difference across the views saved for a page in different user sessions. For most developers looking for a high performance framework, JSF is turn downed because of its forced stateful behaviour. However in any application not all pages need to be stateful, even more commonly there are more no of applications with pages demanding stateless behavior. If JSF has to survive & excel it has to satisfy those justified needs.

Unfortunately, we had to reject JSF, after year after just because it consumed too much resources & degraded its performance because of its forced stateful behavior. Great to see that this feature is being worked on in JSF & but I wish that we can see this in JSF soon rather than hanging ourselves with forced stateful behaviour for another couple of years. Can't wait to use stateless JSF for my upcoming projects!

And yes, I think this is perhaps the most voted issue on JSF project, so the JSF spec designers should deal with this issue in an expedited manner

[eclipse-faces-bot]

@glassfishrobot Commented
gabz90 said:
This feature is essential to JSF. Whenever I vote to use JSF as our front end framework, the development team in my projects brings up this issue. Will this make it to JSF 2.2? It is causing JSF to lose market to other frameworks that are stateless. I'd rather see this feature implemented than a ton of nice smaller ones.

Only last week our new project was close to adopting JSF however the team decided to go a different way over this stateless vs. stateful issue.

This is an issue with a ton of votes and watchers, and my fear is that with the competitive market of web development frameworks out there, is it really wise to push back this feature until the next JSF specification version?

It also brings out unnecessary exceptions which are a pain to handle sometimes. It gives me headaches to get a "ViewExpiredException" when I didn't need any state for that view anyway.

[eclipse-faces-bot]

@glassfishrobot Commented
vjsingh said:
I completely agree. I have been working on JSF for some time now and loved the framework but had to drop it for another side-project of mine which is facing the web and needed a stateless architecture. Believe me, it's only going to be used in enterprises and not on public web facing applications because of the statefull architecture.

[eclipse-faces-bot]

@glassfishrobot Commented
lu4242 said:
I have been working on this possibility for a long time, but the evidence suggest it is better to keep the concept outside JSF.

In MyFaces land this discussion was open some weeks ago.

http://markmail.org/message/pc42cbcvvhlboivb

The central point is it is possible to improve JSF performance and keep its stateful nature without go into concepts done by "stateless" frameworks like view pooling and so on. With a proper design and implementation it is possible to make the difference between pool a JSF view and create it from scratch relatively small. So, at the end the additional complexity does not really worth to do it, it is better to have a stateful view and let JSF deal with the details (keep view size small, reuse objects and so on).

This topic is controversial, but if you ask me, in my opinion and based on the experimental work done from more than a year over this topic is things are not what they seem to be.

[eclipse-faces-bot]

@glassfishrobot Commented
tommy.a said:
Please try Mojarra 2.1.19. Its out with stateless mode.

see here:
http://java.net/jira/browse/JAVASERVERFACES-2731

http://balusc.blogspot.de/2013/02/stateless-jsf.html

[eclipse-faces-bot]

@glassfishrobot Commented
gabz90 said:
Perfect! Thanks! will definitely try it out.

[eclipse-faces-bot]

@glassfishrobot Commented
ertiop93 said:
@tommy.a: Thanks a lot for the absolutely great news!
Will definitely try it out!!

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
I just sent this to jsr344-experts.

EB> Hello Volunteers,
EB> You may have seen Manfred Riem's blog entry about stateless JSF. [1] I
EB> wonder what you think about adding this for 2.2? Here are the spec
EB> changes we would need for this minimal, yet effective approach.

EB> * Expose existing transient attribute on UIComponent on VDLDoc for
EB> <f:view>.

EB> The text of the attribute will be based on UIComponent.isTransient():

EB> If true, the component (and therefore the children of the component)
EB> must not participate in state saving or restoring.

EB> * In section 7.7.2.8 ViewDeclarationLanguage.restoreView(), change the
EB> text to be the following.

EB> The JSP implementation must:

EB> [include the existing text of the section.]

EB> The Facelet implementation must:

EB> Call ResponseStateManager.isStateless(). If true, take the
EB> following action (I will put this in English rather than code).

EB> ViewDeclarationLanguage vdl = vdlFactory.getViewDeclarationLanguage(viewId);
EB> viewRoot = vdl.createView(context, viewId);
EB> @@ -543,9 +547,9 @@
EB> ViewDeclarationLanguage vdl = vdlFactory.getViewDeclarationLanguage(viewId);
EB> viewRoot = vdl.getViewMetadata(context, viewId).createMetadataView(context);
EB> context.setViewRoot(viewRoot);

EB> and return, otherwise [...include existing text of the section].

EB> * In ResponseStateManager.writeState(), if the UIViewRoot is transient,
EB> take impl specific action to make it so the call to
EB> ResponseStateManager.isStateless() during the the next call, from
EB> ViewDeclarationLanguage.restoreView(), returns true.

EB> * Spec for new method ResponseStateManager.isStateless(). If the
EB> preceding writeState() was stateless, return true. If the preceding
EB> writeState() was statefull return false, otherwise throw
EB> IllegalStateException.

EB> Thanks,

EB> Ed

EB> [1] http://weblogs.java.net/blog/mriem/archive/2013/02/08/jsf-going-stateless

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
Make it so a FacesMessage is logged in the page if ProjectStage is not Production and we find that we have a @ViewScoped bean and the current UIViewRoot returns true from its isTransient() method.

[eclipse-faces-bot]

@glassfishrobot Commented
@edburns said:
SECTION: API changes

M applicationIntegration.fm

• Make 7.7.2.8 be:

The JSP implementation must:

If no viewId could be identified, return null.

Call the restoreView() method of the associated StateManager, passing
the FacesContext instance for the current request and the calculated
viewId, and return the returned UIViewRoot, which may be null.

The Facelets implementation must:

Call ResponseStateManager.isStateless(). If the result is false,
proceed as specified in the JSP implementation. Otherwise, take the
following steps and return.

• Obtain a reference to the ViewDeclarationLanguage from the
  ViewDeclarationLanguageFactory. This is necessary to allow for proper
  decoration. It is not acceptable to simply use the java language this
  keyword.

• Call createView() on the ViewDeclarationLanguage instance, passing the
  context and viewId arguments. Let viewRoot be the result.

• Call FacesContext.setViewRoot(viewRoot).

• Call buildView() on the ViewDeclarationLanguage, passing the context
  and viewRoot.

Return the viewRoot.

• Add new section 7.8.1.1

Version 2.2 of the specification adds support for stateless views. In
such a view, the UIComponent state for the components is not
saved. This feature must be used with full awareness of the
statefulness requirements of the components in the view. If a
component requires state to operate correctly, it must not be used in
a stateless view. Furthermore, it is not required that @ViewScoped
managed beans work at all with stateless views. This feature only
works with Facelet based views, not JSP based views.

To mark a view as stateless, the existing transient property from
UIComponent is exposed to the view author by means of the transient
attribute on the <f:view> tag from the Faces Core tag library. The
following spec sections contain more normative requirements for
stateless views.

• The vdldocs for the Facelet variant of the <f:view> tag.

• The javadocs for ResponseStateManager.writeState(FacesContext, Object)

• The javadocs for ResponseStateManager.isStateless(FacesContext)
  Section 7.7.2.8 "ViewDeclarationLanguage.restoreView()"

• The javadocs for javax.faces.view.ViewScoped

• The javadocs for javax.faces.bean.ViewScoped

M preface.fm

• Add new big ticket feature, Stateless Views, with cross reference to
  overview section 7.8.1.1.

Sending applicationIntegration.fm
Sending preface.fm
Transmitting file data ..
Committed revision 1131.

[eclipse-faces-bot]

@glassfishrobot Commented
kito75 said:
I'd like to see a console warning, not just a FacesMessage. A FacesMessage may not be displayed in production, and doesn't show up in the logs.

[eclipse-faces-bot]

@glassfishrobot Commented
exabrial said:
Hey I know this issue is closed, but on a closely related feature request, could this be extended slightly to specify the state saving method on a per-view basis? So there'd be 'none','server','client'? I think I saw this in JIRA somewhere but I can't find the feature request.

[eclipse-faces-bot]

@glassfishrobot Commented
kithouna said:

I think I saw this in JIRA somewhere but I can't find the feature request.

#1056

It would be great if this too would have been included, but the work for JSF 2.2 has to stop at some point, otherwise there'll never be a release.

I really hope that issue will be one of the first things addressed for 2.3

[eclipse-faces-bot]

@glassfishrobot Commented
ertiop93 said:
Would viewscope work in stateless mode ?

It would be good if viewscope works in stateless mode or otherwise there is some appropriate substitute for replacing viewscope.

[eclipse-faces-bot]

@glassfishrobot Commented
@arjantijms said:

Would viewscope work in stateless mode?

No, it explicitly doesn't work. If you try it JSF will throw a specific exception to warn you about this.

It would be good if viewscope works in stateless mode or otherwise there is some appropriate substitute for replacing viewscope.

There should be something, but personally I think this would only make sense when it's possible to make a distinction between "state" and "cache". In a stateless mode it would defeat the purpose to use a bean that keeps state, but it might very well be used for cache. In this context I then define "state" as unique data and "cache" as data that can be restored somehow.

[eclipse-faces-bot]

• Issue Imported From: Provide stateless mode for JSF javaee/javaserverfaces-spec#1055
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @edburns
• Original Issue Closed By:@glassfishrobot