SearchExpressionResolver: @id always uses visitTree ?

[melloware]

Original PrimeFaces Discussion and Analysis: https://github.com/orgs/primefaces/discussions/2350

Brief Overview

PF13- used to have its own @id resolver that always walked the component tree and was working. In PF14 that was removed to rely on JSF 2.3+ ID resolver which behaves differently. We are doing render="@root:@id(growl)" inside a Datatable row.

Code

The question is I don't see how it can ever get to the branch where it walks the component instead of using visitTree

mojarra/impl/src/main/java/com/sun/faces/component/search/SearchKeywordResolverImplId.java

Lines 42 to 47 in 2a0e8fc

	if (isHintSet(searchKeywordContext.getSearchExpressionContext(), SearchExpressionHint.SKIP_VIRTUAL_COMPONENTS)) {
	// Avoid visit tree because in this case we need real component instances.
	// This means components inside UIData will not be scanned.
	findWithId(facesContext, id, current, searchKeywordContext.getCallback());
	} else {
	current.visitTree(VisitContext.createVisitContext(facesContext, null, searchKeywordContext.getSearchExpressionContext().getVisitHints()),

I have grepped the code base and I never see SearchExpressionHint.SKIP_VIRTUAL_COMPONENTS actually ever set and the note even mentions..

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

Question

So how does the branch that doesn't use visitTree ever get executed? Right now I had to inject the old PF @id resolver to fix this issue and have the code work like it did before using the PF findWithId type code.

[BalusC]

Problem is understood but a concrete reproducer is really welcome (preferably without any PrimeFaces deps). I can't reproduce using the reproducer at https://github.com/orgs/primefaces/discussions/2350 After removing all the things JPA and providing a hardcoded stub in a non-lazy model, it works just fine for me in Mojarra 4.0.8 as well as 2.3.21 (i.e. the column values render all just fine).

[melloware]

Hmmm as you said this will be difficult to reproduce without using PrimeFaces LazyModel. I think the LazyModel is key to the issue.

[BalusC]

Oh wow ok. Well ok I might take a second look then.

[melloware]

so in that reproducer i know its using our JPA LAzy Model it definitely shows the issue. And when you debug it fails the find and render any column after the @id is used. So the only way i have found to fix it is to put PF's old resolver back so when I compare our resolver to your resolver the big difference is the visitTree vs what ours was doing before.

[BalusC]

Can you at least reproduce it in a plain LazyDataModel returning a hardcoded list?

[melloware]

let me try that.

[melloware]

OK now this has me thinking its something with WildFly 7.4.12 as I can't seem to reproduce it in any other environment than that. I even put Mojarra 2.3.21 into my WildFly to make sure it was the latest and it still happens. So now I am starting to be stumped but we have 70+ apps running in WildFly 7.4.12 and it was happening to them all on the upgrade from PF13 to 14 which ripped out its custom KeywordResolvers. I guess feel free to close because I don't know how to reliably reproduce this issue.