Provide stateless mode for JSF #1055
Comments
Reported by lincolnbaxter |
Issue-Links: |
@arjantijms said: 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? |
@edburns said: |
rajkumar.w93 said: |
ertiop93 said: Btw, when is this expected to be available ? |
dueni said: |
@arjantijms said:
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. |
exabrial said: 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? |
@arjantijms said:
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 |
bohl_-. said:
(line 158 in rev. 10973 of RestoreViewPhase.java) See also https://github.com/methylene/futil-square-validator/tree/jsfun |
vjsingh said: The lifecycle handles two kinds of requests: initial requests and postbacks. An initial request |
exabrial said: 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. |
bohl_-. said: |
gabz90 said: 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. |
vjsingh said: |
lu4242 said: 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. |
tommy.a said: |
gabz90 said: |
@edburns said: EB> Hello Volunteers, EB> * Expose existing transient attribute on UIComponent on VDLDoc for 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> * In section 7.7.2.8 ViewDeclarationLanguage.restoreView(), change the 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> ViewDeclarationLanguage vdl = vdlFactory.getViewDeclarationLanguage(viewId); EB> and return, otherwise [...include existing text of the section]. EB> * In ResponseStateManager.writeState(), if the UIViewRoot is transient, EB> * Spec for new method ResponseStateManager.isStateless(). If the EB> Thanks, EB> Ed EB> [1] http://weblogs.java.net/blog/mriem/archive/2013/02/08/jsf-going-stateless |
@edburns said: |
@edburns said:
|
kito75 said: |
Marked as fixed on Thursday, February 28th 2013, 8:30:08 am |
exabrial said: |
ertiop93 said: It would be good if viewscope works in stateless mode or otherwise there is some appropriate substitute for replacing viewscope. |
@arjantijms said:
No, it explicitly doesn't work. If you try it JSF will throw a specific exception to warn you about this.
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. |
This issue was imported from java.net JIRA JAVASERVERFACES_SPEC_PUBLIC-1055 |
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.)
The text was updated successfully, but these errors were encountered: