Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 1.2
    • Component/s: Uncategorized
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      272
    • Status Whiteboard:
      Hide

      EGTop5 effort_hard

      Show
      EGTop5 effort_hard

      Description

      Umbrella issue for state management revision in JSF 2.0.

        Issue Links

          Activity

          Hide
          Ed Burns added a comment -

          Add dependencies.

          Show
          Ed Burns added a comment - Add dependencies.
          Hide
          Ed Burns added a comment -

          >>>>> On Fri, 27 Jul 2007 15:47:00 -0700, Igor Shabalov <ishabalov@EXADEL.COM> said:

          IS> This is just another reason why we need to separate State from Component
          IS> and threat it more granularly. With granular State we will have:
          IS> 1. Nice separation between stateless (and there fore thread safe)
          IS> portion of component, Request scope (tread local) and again thread safe
          IS> state and - finally View Scope portion that must be synchronized.
          IS> 2. Locks/synchronization can be used if only required, for example view
          IS> can be locked only if some component need to save state till the end of
          IS> request, so if some parallel request with partial update of other
          IS> portion of same page does not have any statefull part - it will be not
          IS> queued.

          IS> Of course I'm not talking about Data Model concurrency - it's a separate
          IS> story.

          Show
          Ed Burns added a comment - >>>>> On Fri, 27 Jul 2007 15:47:00 -0700, Igor Shabalov <ishabalov@EXADEL.COM> said: IS> This is just another reason why we need to separate State from Component IS> and threat it more granularly. With granular State we will have: IS> 1. Nice separation between stateless (and there fore thread safe) IS> portion of component, Request scope (tread local) and again thread safe IS> state and - finally View Scope portion that must be synchronized. IS> 2. Locks/synchronization can be used if only required, for example view IS> can be locked only if some component need to save state till the end of IS> request, so if some parallel request with partial update of other IS> portion of same page does not have any statefull part - it will be not IS> queued. IS> Of course I'm not talking about Data Model concurrency - it's a separate IS> story.
          Hide
          Ed Burns added a comment -

          MM> Shouldn't we synchronize on whatever scope we invent that is the
          MM> view-scope? Only one request may access the view (or its state,
          MM> depending on how this is gonna change in implementation after we're
          MM> through with 2.0) at a certain point of time, that's it.

          AW> That's by far the simplest approach. This does cause major
          AW> UI issues if you rely on it for AJAX requests, since one
          AW> slow request (server/DB/network) blocks all subsequent requests.

          IS> And now I think we should count separately Ajax vs regular requests.

          AW> In terms of which? View scope, or state saving?
          AW> If the former, I don't see why, if the latter,
          AW> absolutely, in fact see:

          AW> http://issues.apache.org/jira/browse/TRINIDAD-116
          AW> PPR + State Management: reuse state tokens while PPRing to avoid flushing
          the cache

          AW> It's a big win for state longevity (or for memory use,
          AW> if you use it to crank down the size of the state cache).

          Show
          Ed Burns added a comment - MM> Shouldn't we synchronize on whatever scope we invent that is the MM> view-scope? Only one request may access the view (or its state, MM> depending on how this is gonna change in implementation after we're MM> through with 2.0) at a certain point of time, that's it. AW> That's by far the simplest approach. This does cause major AW> UI issues if you rely on it for AJAX requests, since one AW> slow request (server/DB/network) blocks all subsequent requests. IS> And now I think we should count separately Ajax vs regular requests. AW> In terms of which? View scope, or state saving? AW> If the former, I don't see why, if the latter, AW> absolutely, in fact see: AW> http://issues.apache.org/jira/browse/TRINIDAD-116 AW> PPR + State Management: reuse state tokens while PPRing to avoid flushing the cache AW> It's a big win for state longevity (or for memory use, AW> if you use it to crank down the size of the state cache).
          Hide
          Ed Burns added a comment -

          Some questions.

          What is the granularity of state management?

          attribute, component, sub-tree, other?

          For saving, are we using push or pull?

          For restoring, are we using push or pull?

          Show
          Ed Burns added a comment - Some questions. What is the granularity of state management? attribute, component, sub-tree, other? For saving, are we using push or pull? For restoring, are we using push or pull?
          Hide
          Ed Burns added a comment -

          dependency

          Show
          Ed Burns added a comment - dependency
          Hide
          Ed Burns added a comment -

          >>>>> On Wed, 19 Mar 2008, David M Johnson said:

          DJ> I think the goal should be to make JSF applications RESTful by
          DJ> default, with proper use of GET and POST, i.e. only use POST when
          DJ> application data is changing, not for component state. Another goal
          DJ> should be clean, book-markable URLs that only carry path-info and
          DJ> parameters needed by the application logic.

          DJ> That's easy and the default situation with Rail, Grails, Struts, etc.
          DJ> How hard would it be to redesign JSF along those lines? Would it
          DJ> require EJB2 -> EJB3 level changes to JSF?

          Show
          Ed Burns added a comment - >>>>> On Wed, 19 Mar 2008, David M Johnson said: DJ> I think the goal should be to make JSF applications RESTful by DJ> default, with proper use of GET and POST, i.e. only use POST when DJ> application data is changing, not for component state. Another goal DJ> should be clean, book-markable URLs that only carry path-info and DJ> parameters needed by the application logic. DJ> That's easy and the default situation with Rail, Grails, Struts, etc. DJ> How hard would it be to redesign JSF along those lines? Would it DJ> require EJB2 -> EJB3 level changes to JSF?
          Hide
          pmuir added a comment -

          Add view expiry issue

          Show
          pmuir added a comment - Add view expiry issue
          Hide
          Ed Burns added a comment -

          wb

          Show
          Ed Burns added a comment - wb
          Hide
          Ed Burns added a comment -

          Fix checked in.

          Show
          Ed Burns added a comment - Fix checked in.
          Hide
          Ed Burns added a comment -

          Prepare to delete "spec" subcomponent.

          Show
          Ed Burns added a comment - Prepare to delete "spec" subcomponent.
          Hide
          Ed Burns added a comment -

          Move all to 1.2

          Show
          Ed Burns added a comment - Move all to 1.2
          Hide
          Manfred Riem added a comment -

          Closing resolved issue out

          Show
          Manfred Riem added a comment - Closing resolved issue out

            People

            • Assignee:
              Ed Burns
              Reporter:
              Ed Burns
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: