Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.2
    • Component/s: None
    • Labels:
      None

      Description

      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.)

        Issue Links

          Activity

          Hide
          arjan tijms added a comment -

          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?

          Show
          arjan tijms added a comment - 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?
          Hide
          Ed Burns added a comment -

          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.

          Show
          Ed Burns added a comment - 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.
          Hide
          arjan tijms added a comment -

          Although principally asking for a different thing, JAVASERVERFACES_SPEC_PUBLIC-776 is somewhat related to this.

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

          Maybe interesting that historically JAVASERVERFACES_SPEC_PUBLIC-139 seems related to this.

          Show
          arjan tijms added a comment - Although principally asking for a different thing, JAVASERVERFACES_SPEC_PUBLIC-776 is somewhat related to this. JAVASERVERFACES_SPEC_PUBLIC-478 , JAVASERVERFACES_SPEC_PUBLIC-879 and JAVASERVERFACES_SPEC_PUBLIC-1056 are likely affected by this topic as well. Maybe interesting that historically JAVASERVERFACES_SPEC_PUBLIC-139 seems related to this.
          Hide
          Raj added a comment -

          Is this going to be there in JSF 2.2 ?

          Show
          Raj added a comment - Is this going to be there in JSF 2.2 ?
          Hide
          Ertio lew added a comment -

          +1 for this superb thought!

          Btw, when is this expected to be available ?

          Show
          Ertio lew added a comment - +1 for this superb thought! Btw, when is this expected to be available ?
          Hide
          Hanspeter Duennenberger added a comment -

          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.

          Show
          Hanspeter Duennenberger added a comment - 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.
          Hide
          Ertio lew added a comment -

          Any progress on this ?

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

          Show
          Ertio lew added a comment - Any progress on this ? Can we have the fix version stated for this issue ? We wish to see it implemented soon
          Hide
          arjan tijms added a comment -

          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.

          Show
          arjan tijms added a comment - 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.
          Hide
          exabrial added a comment -

          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?

          Show
          exabrial added a comment - 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?
          Hide
          arjan tijms added a comment -

          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

          Show
          arjan tijms added a comment - 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
          Hide
          bohl_-. added a comment -

          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

          Show
          bohl_-. added a comment - 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
          Hide
          vjsingh added a comment -

          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.

          Show
          vjsingh added a comment - 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.
          Hide
          exabrial added a comment -

          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.

          Show
          exabrial added a comment - 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.
          Hide
          bohl_-. added a comment -

          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

          Show
          bohl_-. added a comment - 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
          Hide
          Aditya added a comment - - edited

          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

          Show
          Aditya added a comment - - edited 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
          Hide
          gabz90 added a comment -

          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.

          Show
          gabz90 added a comment - 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.
          Hide
          vjsingh added a comment -

          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.

          Show
          vjsingh added a comment - 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.
          Hide
          lu4242 added a comment -

          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.

          Show
          lu4242 added a comment - 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.
          Hide
          tommy.a added a comment -

          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

          Show
          tommy.a added a comment - 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
          Hide
          gabz90 added a comment -

          Perfect! Thanks! will definitely try it out.

          Show
          gabz90 added a comment - Perfect! Thanks! will definitely try it out.
          Hide
          Ertio lew added a comment -

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

          Show
          Ertio lew added a comment - @tommy.a: Thanks a lot for the absolutely great news! Will definitely try it out!!
          Hide
          Ed Burns added a comment -

          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

          Show
          Ed Burns added a comment - 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
          Hide
          Ed Burns added a comment -

          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.

          Show
          Ed Burns added a comment - 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.
          Hide
          Ed Burns added a comment -

          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.

          Show
          Ed Burns added a comment - 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.
          Hide
          kito75 added a comment -

          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.

          Show
          kito75 added a comment - 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.
          Hide
          exabrial added a comment -

          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.

          Show
          exabrial added a comment - 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.
          Hide
          kithouna added a comment -

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

          JAVASERVERFACES_SPEC_PUBLIC-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

          Show
          kithouna added a comment - I think I saw this in JIRA somewhere but I can't find the feature request. JAVASERVERFACES_SPEC_PUBLIC-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
          Hide
          Ertio lew added a comment -

          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.

          Show
          Ertio lew added a comment - 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.
          Hide
          arjan tijms added a comment -

          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.

          Show
          arjan tijms added a comment - 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.

            People

            • Assignee:
              Ed Burns
              Reporter:
              lincolnbaxter
            • Votes:
              47 Vote for this issue
              Watchers:
              39 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 4 hours, 3 minutes
                4h 3m