DataTable: Row stops rendering when Command in column has update="@id"

[melloware]

@tandraschko @Rapster thought this would be easier to put in a discussion. first I am trying everything to reproduce this issue but so far i have not been able to combine the magic but have narrowed down what is happening.

Note

This code works fine in 13.0.10 and does not in 14.0.2 with no other changes to the server.

Environment

Jboss EAP 7.4.12, Java 11, Mojarra 2.3.14

Scenario

A datatable that has a CommandButton or link with update="@root:@id(growl)" causes the row var to go NULL and the rest of the columns stop rendering. NO ERROR in any logs. Example:

<p:commandButton value="ClickMe" update="@root:@id(growl)" />

The screen renders like this:

Any column after the link is empty now and in debugging the var="row" of the Datatable is verified to be NULL like somehow it gets lost.

Solution I Can't Explain

Changing the update="" to not use @root:@id and use a plain expression like this...

<p:commandButton value="ClickMe" update=":frmEntity:growl" />

This fixes it and now the table renders properly.

Conclusion

The only thing I know is its related to the update="@root:@id()" but what I can't explain is...

1. I can't reproduce it in a PF Test
2. It seems related to SearchExpressions since 13.0.10 uses PF custom expressions and 14.0.0 delegates to Mojarra/MyFaces?
3. ???

I was really hoping if someone did a thought excersize why this blows up with no error but stops rendering the datatable and row var is definitely NULL.

[tandraschko]

@id uses visitTree, maybe something isnt restored correctly in DataTable/UIData#visit, dont know.

[Rapster]

@melloware Can you attach a reproducer even though you can't produce ?

[melloware]

@Rapster here is my shot at reproducer:
discussion-2350.zip

I have run it with Mojarra 2.3.9-2.3.21 to rule out Mojarra and I did the same with my Jboss app I upgraded from Mojarra 2.3.14 to latest 2.3.21 with no difference. That is what makes me think it might be a PF subtle bug.

@tandraschko that is a great hint I didn't realize one used visitTree and the other flavor doesn't.

[melloware]

Besides an an exception, it's hard to tell... Another way is to check when setRowIndex is set to -1 and see if that's expected...

OK I did some more debugging. I put a breakpoint on getUpdate() of the CommandLink with the @root on it and here is where it is in the stack.

What is interesting the AjaxRequestBuilder builds the exact same update whether its @root:@id or `:frm:panel".

It evaluates to the following for both

u:"frmControls:pnlEntityTable"

So now it has me thinking its somewhere in the Mojarra code for SearchExpressions. We call this in our PF code.

private AjaxRequestBuilder addExpressions(UIComponent component, String expressions, String key, Set<SearchExpressionHint> hints,
            boolean skipUnredered) {
        if (LangUtils.isNotBlank(expressions)) {
            String resolvedExpressions = SearchExpressionUtils.resolveClientIdsAsString(context, component, expressions, hints,
                    skipUnredered ? ComponentUtils.VISIT_HINTS_SKIP_UNRENDERED : null);
            buffer.append(",").append(key).append(":\"").append(resolvedExpressions).append("\"");
        }

        return this;
    }

Which delegates to Mojarra in this line:

 List<String> clientIds = context.getApplication().getSearchExpressionHandler().resolveClientIds(
                SearchExpressionContext.createSearchExpressionContext(context, component, hints, visitHints),
                expression);

Let me see if I can debug into that.

[melloware]

OK so I think it worked in PF13- is because of our custom IdResolver for @root:@id did not do VisitTree it walked the components:

https://github.com/primefaces/primefaces/blob/348f3e09758766b9d00d850985563293795c2461/primefaces/src/main/java/org/primefaces/expression/impl/IdExpressionResolver.java#L45

[tandraschko]

Thats what i said already
Either our UIData is broken but i cant help without reproducer

[melloware]

I totally understand i can't reproduce it anywhere but in my production app. VERY FRUSTRATING! But I was able to fix it for my client by adding this to their code and now everything goes back to working. @tandraschko not sure if this is worth putting in to PF core or not since I can't reproduce it.

import java.util.regex.Matcher;
import java.util.regex.Pattern;

import javax.faces.FacesException;
import javax.faces.component.UIComponent;
import javax.faces.component.search.SearchExpressionContext;
import javax.faces.component.search.SearchKeywordContext;
import javax.faces.component.search.SearchKeywordResolver;

import org.primefaces.util.ComponentTraversalUtils;

public class IdExpressionResolver extends SearchKeywordResolver {

   private static final Pattern PATTERN = Pattern.compile("id\\(([\\w-]+)\\)");

   @Override
   public void resolve(final SearchKeywordContext searchKeywordContext, final UIComponent current,
            final String keyword) {
      searchKeywordContext.invokeContextCallback(ComponentTraversalUtils.firstWithId(extractId(keyword), current));
   }

   @Override
   public boolean isResolverForKeyword(final SearchExpressionContext searchExpressionContext, final String keyword) {
      return keyword != null && keyword.startsWith("id(");
   }

   protected String extractId(final String expression) {
      try {
         final Matcher matcher = PATTERN.matcher(expression);

         if (matcher.matches()) {
            return matcher.group(1);
         } else {
            throw new FacesException(
                     "Expression does not match following pattern @id(id). Expression: \"" + expression + "\"");
         }
      } catch (final Exception e) {
         throw new FacesException(
                  "Expression does not match following pattern @id(id). Expression: \"" + expression + "\"", e);
      }
   }
}

[tandraschko]

No its just a hack around a not reproduceable bug 😅

[melloware]

10000% hack!

[melloware]

@tandraschko @Rapster i got to the bottom of it but can't explain why it doesn't ALWAYS happen but i think its a bug in Mojarra/MyFaces.

The bug is right here: https://github.com/eclipse-ee4j/mojarra/blob/2a0e8fce6edb5d5c0e74771ddf249f152ec84f8a/impl/src/main/java/com/sun/faces/component/search/SearchKeywordResolverImplId.java#L42-L47

The javadoc even says...

// Avoid visit tree because in this case we need real component instances.
// This means components inside UIData will not be scanned.

However I have grepped both MyFaces and Mojarra and cannot find a single instance of where SearchExpressionHint.SKIP_VIRTUAL_COMPONENTS is ever used to tell it that this is a UIData?

Stepping through the debugger i verify it never hits that first block and it always uses visitTree...