[
https://issues.apache.org/jira/browse/MYFACES-2607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846045#action_12846045
]
Jakob Korherr commented on MYFACES-2607:
----------------------------------------
After some digging I found out that it is totally OK for the second
FunctionMapper to be null at this place, because on Facelets the
FunctionMappers are created from the xmlns definitions and thus via the
NamespaceHandlers. And the first NamespaceHandler just has no other
FunctionMapper available yet, thus it sets null in CompositeFunctionMapper.
This means my committed null-check is totally ok, because the second
FunctionMapper really can be null. In this scenario we just have to ignore it!
Furthermore a black-box test of Mojarra revealed that they install a
NoopFunctionMapper to circumvent the NPE. Adding the null-check as I did is
just another way to deal with this problem.
> Ugly NPE in CompositeFunctionMapper.resolveFunction() if second
> FunctionMapper is null
> --------------------------------------------------------------------------------------
>
> Key: MYFACES-2607
> URL: https://issues.apache.org/jira/browse/MYFACES-2607
> Project: MyFaces Core
> Issue Type: Task
> Components: JSR-314
> Affects Versions: 2.0.0-beta-3
> Reporter: Jakob Korherr
> Assignee: Jakob Korherr
> Priority: Minor
> Fix For: 2.0.0-beta-3
>
>
> The class CompositeFunctionMapper gets two FunctionMappers in the constructor
> which it uses to resolve EL functions in its method resolveFunction().
> Currently the first FunctionMapper is always NamespaceHandler and the second
> one is the one from the ELContext, which is null at all times. I think this
> is also a problem, but at first I want to get rid of this ugly NPE.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
