Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 2.0-Beta1
-
Component/s: ICE-Components
-
Labels:None
-
Environment:MyFaces 2 and possibly any of Spring or Portlets.
Description
We ran into an issue with MyFaces 2 integration, where MyFaces was doing state saving and restoration of the component tree, several times per lifecycle. When we made the component fields use transient fields, to only hold state throughout a lifecycle, we assumed that state saving only occurred between lifecycles, not throughout them. What happens is that transient state is then lost within the lifecycle, which causes NPE or other problems.
Apparently, with Spring, they do state saving between every single phase in the lifecycle. Also, in Portlets, the lifecycle is separated into two parts, between which state saving occurs. So this problem may well exist with Spring, and with Portlets, and also with MyFaces 2.
1. We need to come up with a MyFaces 2 test case, with more than one compat component in it, which uses transient fields, and which is currently broken with MyFaces 2, but not Mojarra 2.ICE-5868 is an umbrella jira for some issues that have already been found with the compat component showcase. So, instead of building a test app from the ground up, it's recommended to leverage a MyFaces build of compat component-showcase.
2. Once the error has been duplicated, refactor that component to not use transient fields, and instead state save that field. There may be two classes of scenarios (A) straight-forward uses of transient fields, holding primitive data types, where it's just data being cached, and we can refactor the code to handle the caching going away, and regetting the value, or instead having it state saved. (B) complex data type being referenced, which is non-serializable, and cannot be state saved, which maybe is being cached, and can be regotten if null, but might require extensive refactoring. I recommend we start with panelCollapsible (ICE-5965 ), since it's likely in the easier A scenario.
3. Retest that component in the test application.
If this hypothesis turns out correct, of what the problem and solution is, then proceed to text search for the transient keyword in the source code, to find all transient usage in the component code.
Apparently, with Spring, they do state saving between every single phase in the lifecycle. Also, in Portlets, the lifecycle is separated into two parts, between which state saving occurs. So this problem may well exist with Spring, and with Portlets, and also with MyFaces 2.
1. We need to come up with a MyFaces 2 test case, with more than one compat component in it, which uses transient fields, and which is currently broken with MyFaces 2, but not Mojarra 2.
2. Once the error has been duplicated, refactor that component to not use transient fields, and instead state save that field. There may be two classes of scenarios (A) straight-forward uses of transient fields, holding primitive data types, where it's just data being cached, and we can refactor the code to handle the caching going away, and regetting the value, or instead having it state saved. (B) complex data type being referenced, which is non-serializable, and cannot be state saved, which maybe is being cached, and can be regotten if null, but might require extensive refactoring. I recommend we start with panelCollapsible (
3. Retest that component in the test application.
If this hypothesis turns out correct, of what the problem and solution is, then proceed to text search for the transient keyword in the source code, to find all transient usage in the component code.
Issue Links
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Mark Collette
created issue -
Mark Collette
made changes -
Field | Original Value | New Value |
---|---|---|
Salesforce Case | [] | |
Fix Version/s | 2.0-Beta2 [ 10242 ] | |
Assignee Priority | P3 | |
Assignee | Deryk Sinotte [ deryk.sinotte ] |
Mark Collette
made changes -
Mark Collette
made changes -
Mark Collette
made changes -
Mark Collette
made changes -
Mark Collette
made changes -
Mark Collette
made changes -
Mark Collette
made changes -
Mark Collette
made changes -
Mark Collette
made changes -
Mark Collette
made changes -
Mark Collette
made changes -
Mark Collette
made changes -
Mark Collette
made changes -
Mark Collette
made changes -
Mark Collette
made changes -
Mark Collette
made changes -
Salesforce Case | [] | |
Description |
We ran into an issue with MyFaces 2 integration, where MyFaces was doing state saving and restoration of the component tree, several times per lifecycle. When we made the component fields use transient fields, to only hold state throughout a lifecycle, we assumed that state saving only occurred between lifecycles, not throughout them. What happens is that transient state is then lost within the lifecycle, which causes NPE or other problems. Apparently, with Spring, they do state saving between every single phase in the lifecycle. Also, in Portlets, the lifecycle is separated into two parts, between which state saving occurs. So this problem may well exist with Spring, and with Portlets, and also with MyFaces 2. 1. We need to come up with a MyFaces 2 test case, with more than one compat component in it, which uses transient fields, and which is currently broken with MyFaces 2, but not Mojarra 2. 2. Once the error has been duplicated, refactor that component to not use transient fields, and instead state save that field. There may be two classes of scenarios (A) straight-forward uses of transient fields, holding primitive data types, where it's just data being cached, and we can refactor the code to handle the caching going away, and regetting the value, or instead having it state saved. (B) complex data type being referenced, which is non-serializable, and cannot be state saved, which maybe is being cached, and can be regotten if null, but might require extensive refactoring. I recommend we start with panelCollapsible ( 3. Retest that component in the test application. If this hypothesis turns out correct, of what the problem and solution is, then continue on with first fixing every case found in the umbrella jira |
We ran into an issue with MyFaces 2 integration, where MyFaces was doing state saving and restoration of the component tree, several times per lifecycle. When we made the component fields use transient fields, to only hold state throughout a lifecycle, we assumed that state saving only occurred between lifecycles, not throughout them. What happens is that transient state is then lost within the lifecycle, which causes NPE or other problems. Apparently, with Spring, they do state saving between every single phase in the lifecycle. Also, in Portlets, the lifecycle is separated into two parts, between which state saving occurs. So this problem may well exist with Spring, and with Portlets, and also with MyFaces 2. 1. We need to come up with a MyFaces 2 test case, with more than one compat component in it, which uses transient fields, and which is currently broken with MyFaces 2, but not Mojarra 2. 2. Once the error has been duplicated, refactor that component to not use transient fields, and instead state save that field. There may be two classes of scenarios (A) straight-forward uses of transient fields, holding primitive data types, where it's just data being cached, and we can refactor the code to handle the caching going away, and regetting the value, or instead having it state saved. (B) complex data type being referenced, which is non-serializable, and cannot be state saved, which maybe is being cached, and can be regotten if null, but might require extensive refactoring. I recommend we start with panelCollapsible ( 3. Retest that component in the test application. If this hypothesis turns out correct, of what the problem and solution is, then proceed to text search for the transient keyword in the source code, to find all transient usage in the component code. |
Ken Fyten
made changes -
Salesforce Case | [] | |
Fix Version/s | 2.1 [ 10241 ] | |
Fix Version/s | 2.0-Beta2 [ 10242 ] |
Ted Goddard
made changes -
Ken Fyten
made changes -
Salesforce Case | [] | |
Assignee Priority | P3 |
Deryk Sinotte
made changes -
Deryk Sinotte
made changes -
Salesforce Case | [] | |
Assignee | Deryk Sinotte [ deryk.sinotte ] | Ken Fyten [ ken.fyten ] |
Ken Fyten
made changes -
Status | Open [ 1 ] | Resolved [ 5 ] |
Resolution | Fixed [ 1 ] |
Ken Fyten
made changes -
Fix Version/s | 3.0.RC2 [ 10313 ] |
Ken Fyten
made changes -
Status | Resolved [ 5 ] | Closed [ 6 ] |