Hint: I already posted a question about this on Stackoverflow: jsf - Omnifaces Taglib not found within EL in CustomComponent - Stack Overflow
I am currently upgrading a webapp from JBoss 7.1 to Wildfly 10.1, where I stumbled over a rather tricky problem concerning taglib resolution within an expression language within a custom component.
I managed to isolate the problem, which apparently boils down to the fact, that JSFs ExpressionBuilder cannot find the correct name spaces defined in my custom component and therefore complains that it does not know anything about the Omnifaces taglib:
javax.el.ELException: Function 'of:format1' not found
at com.sun.el.lang.ExpressionBuilder.visit(ExpressionBuilder.java:275)
at com.sun.el.parser.SimpleNode.accept(SimpleNode.java:172)
at com.sun.el.lang.ExpressionBuilder.prepare(ExpressionBuilder.java:227)
at com.sun.el.lang.ExpressionBuilder.build(ExpressionBuilder.java:238)
at com.sun.el.lang.ExpressionBuilder.createValueExpression(ExpressionBuilder.java:295)
at com.sun.el.ExpressionFactoryImpl.createValueExpression(ExpressionFactoryImpl.java:112)
at org.jboss.weld.util.el.ForwardingExpressionFactory.createValueExpression(ForwardingExpressionFactory.java:53)
at org.jboss.weld.el.WeldExpressionFactory.createValueExpression(WeldExpressionFactory.java:48)
at org.jboss.weld.util.el.ForwardingExpressionFactory.createValueExpression(ForwardingExpressionFactory.java:53)
at org.jboss.weld.el.WeldExpressionFactory.createValueExpression(WeldExpressionFactory.java:48)
at com.sun.faces.facelets.el.ELText.parse(ELText.java:411) at com.sun.faces.facelets.el.ELText.parse(ELText.java:342)
Funny enough, that only happens if I inline the evaluation of a nested EL expression within of:format1.
A minimal example, where the problem can be reproduced, can be found at a Bitbucket repository, but here's the relevant code of my custom component:
<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:c="http://java.sun.com/jsp/jstl/core"
xmlns:cc="http://xmlns.jcp.org/jsf/composite"
xmlns:of="http://omnifaces.org/functions">
<h:head>
<title>Testing EL</title>
</h:head>
<h:body>
<cc:interface>
<cc:attribute name="model" type="sandbox.eltest.model.Entity" required="true" />
</cc:interface>
<cc:implementation>
<div id="#{cc.clientId}">
<c:set var="value" value="#{cc.attrs.model.value}" />
#{of:format1('Hello {0}', value)} <!-- Prints "Hello World" correctly -->
#{of:format1('Hello {0}', cc.attrs.model.value)} <!-- THROWS javax.el.ELException -->
</div>
</cc:implementation>
</h:body>
</html>
The second version with the inlined cc.attrs.model.value works in JBoss 7.1 (which uses a patched version of Mojarra 1.2.15) but fails on Wildfly 10.1. Wildfly originally ships with a patched version of Mojarra 2.2.13, but the EL fails to evaluate even after upgrading to 2.2.14.
User BalusC on SO has hinted, that this might be a Mojarra bug handling XML namespaces. I debugged into the ExpressionBuilder and can also confirm that the builder has lost all references to namespaces declared within the custom component after evaluating cc.attrs.model.value
This is rather annoying, because it currently blocks our migration.