cc.attrs cannot be passed to nested composite (OWB)

[aleshi]

Describe the bug

This issue was originally discovered in Tomee10, but I was able to isolate it to mojarra+openwebbeans combination.
I have parent CompositeTest.xhtml that has showSomeText attribute. And I have nested component NestedCompositeTest.xhtml with showSomeText2 attribute. I need to pass showSomeText from parent to showSomeText2 of nested component.

CompositeTest.xhtml

<ui:component
        xmlns="http://www.w3.org/1999/xhtml"
        xmlns:cc="jakarta.faces.composite"
        xmlns:ui="jakarta.faces.facelets"
        xmlns:search="jakarta.faces.composite/components" >

    <cc:interface>
        <cc:attribute name="showSomeText" default="#{true}" type="boolean" />
    </cc:interface>

    <cc:implementation>
        <p>
            CompositeTest.xhtml: showSomeText is #{cc.attrs.showSomeText}
        </p>
        <search:NestedCompositeTest showSomeText2="#{cc.attrs.showSomeText}">
        </search:NestedCompositeTest>
    </cc:implementation>
</ui:component>

NestedCompositeTest.xhtml

<ui:component
        xmlns="http://www.w3.org/1999/xhtml"
        xmlns:c="jakarta.tags.core"
        xmlns:cc="jakarta.faces.composite"
        xmlns:ui="jakarta.faces.facelets">

    <cc:interface>
        <cc:attribute name="showSomeText2" default="#{true}" type="boolean" />
    </cc:interface>
    <cc:implementation>
        <div>
            <p>
                NestedCompositeTest.xhtml: showSomeText2 is #{cc.attrs.showSomeText2}
            </p>
            <p>
                <c:if test="#{cc.attrs.showSomeText2}">
                    some text
                </c:if>
            </p>
        </div>
    </cc:implementation>
</ui:component>

The issue is that the value of showSomeText2 is always false. This assignment doesn't work: showSomeText2="#{cc.attrs.showSomeText}".

It gets even more interesting when I use the same attribute name in parent and nested components. Then I get StackOverflowError.

I was able to debug it to the point when https://github.com/apache/openwebbeans/blob/openwebbeans-4.0.2/webbeans-el22/src/main/java/org/apache/webbeans/el22/WebBeansELResolver.java is trying to get value for cc bean and instead of CompositeTest.xhtml, it takes the one that belongs to nested NestedCompositeTest.xhtml.

The same example works fine with Weld.

To Reproduce

Build war file from this repo and deploy it to tomcat: https://github.com/aleshi/mojarra_openwebbeans_issue
Open: http://localhost:8080/jsf_cdi_and_ejb_war/test.jsf
The page prints:

CompositeTest.xhtml: showSomeText is true

NestedCompositeTest.xhtml: showSomeText2 is false

Expected behavior

CompositeTest.xhtml: showSomeText is true

NestedCompositeTest.xhtml: showSomeText2 is true

Additional context
Mojarra version: 4.0.8
Openwebbeans version: 4.0.2
Tomcat version: 10.1.31

[aleshi]

In Mojarra 4.0, ImplicitObjectELResolver was replaced with CDI. Now the cc implicit object is handled by CDI and CompositeComponentProducer.

This creates an issue with nested components and OWB. When a child component tries to resolve #{cc.attrs.showSomeText2}, it also needs to access the parent component’s #{cc.attrs.showSomeText}. Parent assigns child's showSomeText2 attribute with parent's showSomeText attribute.

The child component (cc) resolves correctly, but the parent component cc ends up being resolved to the child instead. The issue seems to come from a caching mechanism in OWB’s WebBeansELResolver.java.

You can see the relevant code here:
https://github.com/apache/openwebbeans/blob/44eac7ee246db0f90dcbe68f545620be4e38099a/webbeans-el22/src/main/java/org/apache/webbeans/el22/WebBeansELResolver.java#L118-L127

I worked around this by overriding the WebBeansELResolver class and disabling caching for implicit objects.

I’d appreciate any feedback or thoughts from experts on this issue. No idea if it's Mojarra or OWB issue.

Thanks!

[BalusC]

Related: https://stackoverflow.com/questions/79393943/jakarta-faces-4-tomee-10-nested-composites-same-attribute-name-causes-stack

@arjantijms as you're the CDI expert, can you point out if the issue is in Mojarra or in OWB or even in CDI? This appears to be the consequence of replacing ImplicitObjectELResolver with CompositeComponentProducer. To reiterate, everything works fine when using Weld 5 instead of OWB 4 and also when using MyFaces 4 instead of Mojarra 4.

For reference, this is the StackOverflowError I reproduced in TomEE 10.0.0 Plume based on the code provided in the SO question:

java.lang.StackOverflowError
	java.base/java.util.HashMap.hash(HashMap.java:338)
	java.base/java.util.HashMap.getNode(HashMap.java:576)
	java.base/java.util.HashMap.get(HashMap.java:564)
	org.apache.webbeans.el.ELContextStore.findBeanByName(ELContextStore.java:89)
	org.apache.webbeans.el22.WebBeansELResolver.getValue(WebBeansELResolver.java:122)
	com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:139)
	com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:164)
	org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:94)
	org.apache.el.parser.AstValue.getValue(AstValue.java:134)
[repeat]
	org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:152)
	org.apache.webbeans.el22.WrappedValueExpression.getValue(WrappedValueExpression.java:67)
	com.sun.faces.facelets.el.ContextualCompositeValueExpression.getValue(ContextualCompositeValueExpression.java:111)
	com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:73)
	jakarta.faces.component.UIComponentBase$AttributesMap.get(UIComponentBase.java:1976)
	com.sun.faces.el.CompositeComponentAttributesELResolver$ExpressionEvalMap.get(CompositeComponentAttributesELResolver.java:331)
	jakarta.el.MapELResolver.getValue(MapELResolver.java:66)
	com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:139)
	com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:164)
	org.apache.el.parser.AstValue.getValue(AstValue.java:161)
[/repeat]

[BalusC]

See also jakartaee/faces#1564. We should probably restore ImplicitObjectELResolver in Mojarra 4.

[BalusC]

Confirmed fixed in TomEE Plume 10.0.0 when swapping out its lib/jakarta.faces-4.0.8.jar for the current jakarta.faces.4.0.10-SNAPSHOT.

[cyanotyp]

Hi BalusC, thanks a lot! and sorry if it sounds like a beginners questions but how/where can I access this snapshot build ?

[BalusC]

Mojarra snapshots are currently unfortunately not deployed to Jakarta's Sonatype Maven repo. So for the time being you'll have to build your own:

1. git clone [email protected]:eclipse-ee4j/mojarra.git
2. cd mojarra/impl
3. git checkout issue_5515 (or git checkout 4.0 once it's merged)
4. mvn clean install -DskipTests=true
5. you'll find the jakarta.faces-4.0.X-SNAPSHOT.jar file in target subfolder

[cyanotyp]

Ok wanted to avoid to start a custom build ;)
EDIT: But I'm to curious about it, built it and currently trying my app :)
Since I know now the way to go, I can also wait some more days. The most important info with me is that there IS a solution

@BalusC one more question: will your bugfix be automatically taken to the next TomEE 10.0.x bugfix release, or does someone (me?) have to create a Bug Issue in their JIRA as well

[jgallimore]

@cyanotyp We'll update TomEE to pull this in once it is released. I'm imagine we'll want to get a TomEE release done fairly soon after that update to get this resolved.