NullPointer on managed FacesConverters if both forClass and value is set

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

NullPointer on managed FacesConverters if both forClass and value is set

Juri Berlanda
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 | Threaded
Open this post in threaded view
|

Re: NullPointer on managed FacesConverters if both forClass and value is set

Thomas Andraschko-4
Hi,

seems like a bug, yes.
It would be great if you could create a jira + attach a unit test.
Even better would be if you can provide a patch to solve the issue.

Regards,
Thomas

2018-04-23 16:23 GMT+02:00 Juri Berlanda <[hidden email]>:

> 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.ge
> tAsString(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 | Threaded
Open this post in threaded view
|

Re: NullPointer on managed FacesConverters if both forClass and value is set

Juri Berlanda
Hello again,

I think I jumped the gun... While poking around a little more I noticed
the following being printed by Mojarra on startup:

WARNING [RMI TCP Connection(4)-127.0.0.1]
com.sun.faces.application.annotation.ConverterConfigHandler.collect
@FacesConverter is using both value and forClass, only value will be
applied.

So it seems FacesConverters are actually meant to be used with either
value, or forClass, but not both at the same time. That would also mean
the behavior I see in MyFaces 2.3.0 is actually due to an undefined
state, caused by our FacesConverters being out-of-spec, and not a by bug
in MyFaces. Yet handling it more gracefully as Mojarra does seems to be
a good idea.

I'll see what I can do for fixing this by mimicking Mojarra's behavior.
Though I didn't work on MyFaces before, so no guarantees for neither
good code, nor the patch being available soon :)

Regards,
Juri

On 04/23/2018 04:29 PM, Thomas Andraschko wrote:

> Hi,
>
> seems like a bug, yes.
> It would be great if you could create a jira + attach a unit test.
> Even better would be if you can provide a patch to solve the issue.
>
> Regards,
> Thomas
>
> 2018-04-23 16:23 GMT+02:00 Juri Berlanda <[hidden email]>:
>
>> 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.ge
>> tAsString(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
>>