Hello,

we recently upgraded to MyFaces 2.3.0 from 2.2.12 and after adding the managed=true to our FacesConverters we noticed a weird NullPointer if they are used from EL.

In detail:
The following converter (just as an example. This doesn't need CDI support, but our Converters do)

@ApplicationScoped @FacesConverter(value="dtoConverter", forClass = 
DtoToConvert.class, managed =true)
public class DtoConverterimplements Converter<DtoToConvert>  {
    public DtoToConvertgetAsObject(FacesContext context, UIComponent component, 
String value)throws ConverterException {
        return new DtoToConvert(value); }

    public StringgetAsString(FacesContext context, UIComponent component, 
DtoToConvert value)throws ConverterException {
        return value.getName(); }
}


being used in JSF like

<h:outputText value="#{dtoModel.dtoToConvert}"> <f:converter converterId="dtoConverter"/></h:outputText>


throws a NullPointerException at

org.apache.myfaces.cdi.converter.FacesConverterCDIWrapper.getAsString(FacesConverterCDIWrapper.java:62)


Removing the

forClass = DtoToConvert.class


fixes the problem. Under Mojarra 2.3.4 everything works, even with the forClass. So I'm not sure whether this is a misuse of FacesConverters on our side, or if this is actually a bug in MyFaces. The only clue I found is:

What happens behind the scenes now is that when JSF needs a converter it simply 
asks the CDI bean manager for a bean
that implements Converter with a qualifier @FacesValidator that has the 
"managed" attribute set to true and the value
(coverterId) or forClass attribute set to the right value (which is why it's 
important that these attributes are all binding).


But that does not explicitly state, that value and forClass may not be used together. Can someone help me out? If needed I can provide a test project targeting Tomcat 8.5 showing the problem in MyFaces 2.3.0 and the thingy working in Mojarra 2.3.4.

Cheers,
Juri

Reply via email to