We migrate from TomEE 9 to TomEE 10, and the Faces 4.0 part causes us troubles. We already use faces-4.0.10-snapshot library due to a patched composite component issue. It seems that the "#{request}" is not available as Implicit Object in Expression Language, but "facesContext", "externalContext" and similar are available as described in .0/jakarta-faces-4.0#a2830 "5.6.2.1. Implicit Objects for Facelets and Programmatic Access". It seems the other ones are available and work - which would be also a "working but not so nice" work-around e.g.

#{externalContext.request.contextPath} - works
#{facesContext.externalContext.requestContextPath} - works
#{facesContext.externalContext.request.contextPath} - works

to debug it, I tried below line, which gives the same class as in TomEE 9

#{request.toString()} = .apache.catalina.core.ApplicationHttpRequest@37482850

But finally

<h:outputText value="request.contextPath=#{request.contextPath}"/>

gives below exception (property contextPath not found for type...)

SEVERE .primefaces.application.exceptionhandler.PrimeExceptionHandler * Die Eigenschaft [contextPath] wurde für den Typ [.apache.webbeans.custom.Object$$OwbNormalScopeProxy6949990480] nicht gefunden
jakarta.el.PropertyNotFoundException: Die Eigenschaft [contextPath] wurde für den Typ [.apache.webbeans.custom.Object$$OwbNormalScopeProxy6949990480] nicht gefunden
    at jakarta.el.BeanELResolver$BeanProperties.get(BeanELResolver.java:261)
    at jakarta.el.BeanELResolver.property(BeanELResolver.java:330)
    at jakarta.el.BeanELResolver.getValue(BeanELResolver.java:99)
    at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:139)
    at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:164)
    at .apache.el.parser.AstValue.getValue(AstValue.java:161)
    at .apache.el.parser.AstDeferredExpression.getValue(AstDeferredExpression.java:42)
    at .apache.el.parser.AstCompositeExpression.getValue(AstCompositeExpression.java:47)
    at .apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:152)
    at .apache.webbeans.el22.WrappedValueExpression.getValue(WrappedValueExpression.java:67)

Possible related topics and bug reports:

• Jakarta Faces 4 / TomEE 10 - Nested composites, same attribute name causes StackoverflowError

We migrate from TomEE 9 to TomEE 10, and the Faces 4.0 part causes us troubles. We already use faces-4.0.10-snapshot library due to a patched composite component issue. It seems that the "#{request}" is not available as Implicit Object in Expression Language, but "facesContext", "externalContext" and similar are available as described in https://jakarta.ee/specifications/faces/4.0/jakarta-faces-4.0#a2830 "5.6.2.1. Implicit Objects for Facelets and Programmatic Access". It seems the other ones are available and work - which would be also a "working but not so nice" work-around e.g.

#{externalContext.request.contextPath} - works
#{facesContext.externalContext.requestContextPath} - works
#{facesContext.externalContext.request.contextPath} - works

to debug it, I tried below line, which gives the same class as in TomEE 9

#{request.toString()} = .apache.catalina.core.ApplicationHttpRequest@37482850

But finally

<h:outputText value="request.contextPath=#{request.contextPath}"/>

gives below exception (property contextPath not found for type...)

SEVERE .primefaces.application.exceptionhandler.PrimeExceptionHandler * Die Eigenschaft [contextPath] wurde für den Typ [.apache.webbeans.custom.Object$$OwbNormalScopeProxy6949990480] nicht gefunden
jakarta.el.PropertyNotFoundException: Die Eigenschaft [contextPath] wurde für den Typ [.apache.webbeans.custom.Object$$OwbNormalScopeProxy6949990480] nicht gefunden
    at jakarta.el.BeanELResolver$BeanProperties.get(BeanELResolver.java:261)
    at jakarta.el.BeanELResolver.property(BeanELResolver.java:330)
    at jakarta.el.BeanELResolver.getValue(BeanELResolver.java:99)
    at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:139)
    at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:164)
    at .apache.el.parser.AstValue.getValue(AstValue.java:161)
    at .apache.el.parser.AstDeferredExpression.getValue(AstDeferredExpression.java:42)
    at .apache.el.parser.AstCompositeExpression.getValue(AstCompositeExpression.java:47)
    at .apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:152)
    at .apache.webbeans.el22.WrappedValueExpression.getValue(WrappedValueExpression.java:67)

Possible related topics and bug reports:

• Jakarta Faces 4 / TomEE 10 - Nested composites, same attribute name causes StackoverflowError
• https://github/eclipse-ee4j/mojarra/issues/5561
• https://github/jakartaee/faces/issues/1564#issuecomment-2650774352

• jsf
• jakarta-ee
• apache-tomee

• @BalusC sorry to disturb, maybe you can support here with your expert know-how? – cyanotyp Commented Feb 11 at 13:05
• 1 I already posted this comment a minute before yours github/jakartaee/faces/issues/1564#issuecomment-2650774352 :) – BalusC Commented Feb 11 at 13:07
• you're simply too fast :) will check there, just let me know if I can support with further usecases etc – cyanotyp Commented Feb 11 at 13:12
• Hello @BalusC any news on the 4.0.11 bugfix release ? – cyanotyp Commented Mar 4 at 7:39
• 1 PR was yday finally approved so I just merged it and started the 4.0.11 release process :) – BalusC Commented Mar 8 at 12:14

1 Answer 1

This has been fixed in Mojarra 4.0.11 as per issue 5561 and TomEE 10.0.1 release includes this bugfix.

It appears there's confusion in CDI wrt the purpose of Bean#getBeanClass():

The bean class of the managed bean or session bean or of the bean that declares the producer method or field.

In Faces, the #{request}, #{session}, etc are produced by CDI producers. So the getBeanClass() returns the class of the bean class having the producer method. This works fine in Weld, the reference implementation of CDI. However, it unfortunately doesn't work in OpenWebBeans, the alternative implementation of CDI.

See also issue 5457. Right now Mojarra basically does this in CdiProducer in order to satisfy the both CDI implementations:

protected CdiProducer<T> beanClass(BeanManager beanManager, Class<?> beanClass) {
    if (CdiUtils.isWeld(beanManager)) {
        this.beanClass = CdiExtension.class; // See #5457 and #5157
    } else {
        this.beanClass = beanClass;
    }

    return this;
}