[ 
https://issues.jboss.org/browse/RF-11093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brian Leathem updated RF-11093:
-------------------------------

    Description: 
I am encountering a reentrance problem with 
org.richfaces.component.UIDataAdaptor (using it as a dataTable).

I need to perform a visit of the component tree while executing an action on a 
command link in one row of the same table.

{code}
<rich:dataTable value="#{listOfItems}" var="myItem" >
        ... some stuff here ...
                <commandLink here>
        ... some stuff here ...
</rich:dataTable>
{code}

After the action on the command link has visited the component tree, myItem is 
no longer available in context.

When the UIDataAdaptor sets or resets the "myItem" context variable, it backs 
up any previous value by calling captureOrigValue(FacesContext), and later 
restores it by calling restoreOrigValue(FacesContext), but it looks as if the 
visit backs the variable up twice (in a nested fashion), and it erases myItem 
between the two backups :

- backup variable (old value is correctly backed up) (in visitTree(VisitContext 
visitContext, VisitCallback callback))
- erase variable (setRowKey(facesContext, null) in same function)
- erase variable (doVisitChildren(VisitContext context, boolean visitRows))
- erase variable (visitTree(VisitContext visitContext, VisitCallback callback))
- backup variable (erases backed up value) (walk(FacesContext faces, 
DataVisitor visitor, Object argument))
- ...
- restore value  (restores null) (walk(FacesContext faces, DataVisitor visitor, 
Object argument))
- restore value  (restores null) (in visitTree(VisitContext visitContext, 
VisitCallback callback))

etc.

The problem can be solved by *stacking* backed up variables, instead of storing 
them in a simple attribute, to allow for any kind of reentrance.

(I do not say that this is the best possible patch, but it has solved the 
problem for me).

  was:
I am encountering a reentrance problem with 
org.richfaces.component.UIDataAdaptor (using it as a dataTable).

I need to perform a visit of the component tree while executing an action on a 
command link in one row of the same table.

<rich:dataTable value="#{listOfItems}" var="myItem" >
        ... some stuff here ...
                <commandLink here>
        ... some stuff here ...
</rich:dataTable>

After the action on the command link has visited the component tree, myItem is 
no longer available in context.

When the UIDataAdaptor sets or resets the "myItem" context variable, it backs 
up any previous value by calling captureOrigValue(FacesContext), and later 
restores it by calling restoreOrigValue(FacesContext), but it looks as if the 
visit backs the variable up twice (in a nested fashion), and it erases myItem 
between the two backups :

- backup variable (old value is correctly backed up) (in visitTree(VisitContext 
visitContext, VisitCallback callback))
- erase variable (setRowKey(facesContext, null) in same function)
- erase variable (doVisitChildren(VisitContext context, boolean visitRows))
- erase variable (visitTree(VisitContext visitContext, VisitCallback callback))
- backup variable (erases backed up value) (walk(FacesContext faces, 
DataVisitor visitor, Object argument))
- ...
- restore value  (restores null) (walk(FacesContext faces, DataVisitor visitor, 
Object argument))
- restore value  (restores null) (in visitTree(VisitContext visitContext, 
VisitCallback callback))

etc.

The problem can be solved by *stacking* backed up variables, instead of storing 
them in a simple attribute, to allow for any kind of reentrance.

(I do not say that this is the best possible patch, but it has solved the 
problem for me).






> UIDataAdaptor context variable backup broken (reentrance problem)
> -----------------------------------------------------------------
>
>                 Key: RF-11093
>                 URL: https://issues.jboss.org/browse/RF-11093
>             Project: RichFaces
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: component-tables
>    Affects Versions: 4.0.0.Final
>         Environment:  Windows XP, Java 6, Tomcat 6.0.24, Mojarra 2.0.2.
>            Reporter: Yannick Valot
>             Fix For: 5-Future
>
>         Attachments: UIDataAdaptor.java.patch
>
>
> I am encountering a reentrance problem with 
> org.richfaces.component.UIDataAdaptor (using it as a dataTable).
> I need to perform a visit of the component tree while executing an action on 
> a command link in one row of the same table.
> {code}
> <rich:dataTable value="#{listOfItems}" var="myItem" >
>       ... some stuff here ...
>               <commandLink here>
>       ... some stuff here ...
> </rich:dataTable>
> {code}
> After the action on the command link has visited the component tree, myItem 
> is no longer available in context.
> When the UIDataAdaptor sets or resets the "myItem" context variable, it backs 
> up any previous value by calling captureOrigValue(FacesContext), and later 
> restores it by calling restoreOrigValue(FacesContext), but it looks as if the 
> visit backs the variable up twice (in a nested fashion), and it erases myItem 
> between the two backups :
> - backup variable (old value is correctly backed up) (in 
> visitTree(VisitContext visitContext, VisitCallback callback))
> - erase variable (setRowKey(facesContext, null) in same function)
> - erase variable (doVisitChildren(VisitContext context, boolean visitRows))
> - erase variable (visitTree(VisitContext visitContext, VisitCallback 
> callback))
> - backup variable (erases backed up value) (walk(FacesContext faces, 
> DataVisitor visitor, Object argument))
> - ...
> - restore value  (restores null) (walk(FacesContext faces, DataVisitor 
> visitor, Object argument))
> - restore value  (restores null) (in visitTree(VisitContext visitContext, 
> VisitCallback callback))
> etc.
> The problem can be solved by *stacking* backed up variables, instead of 
> storing them in a simple attribute, to allow for any kind of reentrance.
> (I do not say that this is the best possible patch, but it has solved the 
> problem for me).



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
_______________________________________________
richfaces-issues mailing list
richfaces-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/richfaces-issues

Reply via email to