[JAVASERVERFACES_SPEC_PUBLIC-139] "Mostly Stateles" state saving Created: 06/Feb/06  Updated: 01/Aug/14  Resolved: 24/Nov/09

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.2 Sprint 8
Fix Version/s: 2.0

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: All
Platform: Sun

Attachments: Text File 139-mods.zip     Zip Archive 139-mods.zip     Text File changebundle.txt     Text File changebundle.txt     Text File state-change-bundle.txt    
Issue Links:
blocks JAVASERVERFACES_SPEC_PUBLIC-272 StateManagementRevision Closed
Issuezilla Id: 139
Status Whiteboard:

EGTop5 effort_hard


JH> 2. Also, I would really like the EG to look at redoing the UIComponent
JH> state-saving. Given the plain of available components and amount of
JH> unecessary state saved for each user, I think we would be better off
JH> following EJB 3's tail with some kind of annotation for state saving and
JH> treat stateless (as in request scope) as the normal mode of operation.
JH> I've been able to test returning nothing for state and simply creating a
JH> new component tree within restoreView-- leaving all components to
JH> request scope and removing the need to preserve state. I fully realize
JH> this doesn't work for all cases, but again, those cases are the minority
JH> for JSF and always have been.

Comment by Ed Burns [ 06/Feb/06 ]


Comment by Ed Burns [ 22/Apr/08 ]

For component tree I think we may simplify it life-cycle, but to make it
completely static is probably too much for me. I'd rather fix binding to
allow component tree segments relay on normal scope rules. That imply
introduction of some explicit Component Context to hold "variable"
portion of Component data (like submitted value etc.).

By default tree go to Application scope, however, if it have binding,
than it goes to the scope of that bean, created lazy once per bean life
cycle and stay there. Component Context created/saved/restored at every
request and used by component instead of member variables to store local

For example:
<view ....> - implicitly create bean in application scope
... some children here ... effectively are in application scope
<panelGrid binding="#

{a}" ...>
if "a" is session scope, than (1) component instance put onto bean
"a" in session scope following normal bean resolving rules (lazy
initialization), (2) special delegate put between children of <view>
with reference to "#{a}

. That delegate relay all actual activity to real
component from session scope.
... all children of <panelGrid ...> are effectively in session
scope. And so on.

This way we will keep it simple, but still allow great flexibility for
application developers. Again, all we need is to separate "static"
portion of component from it "variable" part. I guess majority of
components will not have any "variable" part, so there Context will be
null. Nothing to keep in view state.


Comment by Ed Burns [ 22/Apr/08 ]


Comment by rogerk [ 20/Aug/08 ]
      • Issue 96 has been marked as a duplicate of this issue. ***
Comment by driscoll [ 20/Aug/08 ]
      • Issue 252 has been marked as a duplicate of this issue. ***
Comment by rogerk [ 22/Aug/08 ]

Status whiteboard

Comment by Ed Burns [ 12/Sep/08 ]


Comment by Ed Burns [ 12/Sep/08 ]

change target_milestone to 2.0

Comment by Ed Burns [ 14/Nov/08 ]


Make sure this fits in as well.

Comment by Ed Burns [ 22/Jan/09 ]

Re-enable UIData testcases:


Comment by Ed Burns [ 22/Jan/09 ]

Created an attachment (id=190)
Excluded tests, pre merge to trunk@HEAD

Comment by Ed Burns [ 29/Jan/09 ]

Created an attachment (id=194)
checkpoint, just for archive.

Comment by Ed Burns [ 05/Feb/09 ]

Created an attachment (id=199)
Fix for this bug, second iteration, including automated test.

Comment by Ed Burns [ 05/Feb/09 ]

Created an attachment (id=200)
checkpoint manifest, just for archive

Comment by Ed Burns [ 05/Feb/09 ]

Created an attachment (id=201)
checkpoint in lieu of checkin

Comment by Ed Burns [ 28/Jul/09 ]

I worked on this, and it's fixed, so I'm marking it fixed.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out

Generated at Mon May 25 02:39:51 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.