Re: FasterXml Jackson 2.2.0 Provider no longer works with CXF JAX-RS

[Sergey Beryozkin <sb...@gmail.com>]

Fixed now - thanks
Sergey
On 30/04/13 20:23, wizpar@yahoo.com wrote:
> Okay thanks Sergey..
> yes for now we are on 2.1.4 so it's fine and if we must move to 2.2.0 then I'll just have a wrapper for the
> jackson provider by extending it myself and adding implements message reader and writer to it..
>
> thanks,
> parwiz
>
>
> ________________________________
>   From: Sergey Beryozkin <sb...@gmail.com>
> To: users@cxf.apache.org
> Sent: Tuesday, April 30, 2013 5:28 AM
> Subject: Re: FasterXml Jackson 2.2.0 Provider no longer works with CXF JAX-RS
>
>
> Hi
>
> Thanks for the analysis, comments in the end of the message,
> On 30/04/13 08:45, wizpar@yahoo.com wrote:
>> hey guys,
>> I recently wanted to upgrade to fasterxml jackson 2.2.0 (was on 2.1.4)
>> and noticed the changes they have made to their Provider breaks
>> how current ProviderFactory in cxf jax-rs looks up a message writer/reader.
>>
>> Here are the details and I would like to hear what you guys think
>> on how to procede with this.
>> I'm using cxf 2.7.4
>>
>> first up let's look at Providerfactory and specifically
>>
>>
>> private static Type[] getGenericInterfaces(Class<?>  cls) {
>>            if (Object.class == cls) {
>>                return new Type[]{};
>>            }
>>            Type genericSuperCls = cls.getGenericSuperclass();
>>            if (genericSuperCls instanceof ParameterizedType) {
>>                return new Type[]{genericSuperCls};
>>            }
>>            Type[] types = cls.getGenericInterfaces();
>>            if (types.length>  0) {
>>                return types;
>>            }
>>            return getGenericInterfaces(cls.getSuperclass());
>>        }
>>
>> which is called from handleMapper(...);
>>
>> on fasterxml jackson 2.1.4 it works fine because here is how the class is declared in there
>> com.fasterxml.jackson.jaxrs.json.JacksonJsonProvider:
>>
>> @Provider
>> @Consumes(MediaType.WILDCARD) // NOTE: required to support "non-standard" JSON variants
>> @Produces(MediaType.WILDCARD)
>> public class JacksonJsonProvider
>>        implements
>>            MessageBodyReader<Object>,
>>            MessageBodyWriter<Object>,
>>            Versioned
>> {
>>
>> this leads to grabbing the generic interfaces and since Object is handled it can handle
>> writing your models fine.
>>
>>
>> now in 2.2.0 it's been modified to be like this
>> @Provider
>> @Consumes(MediaType.WILDCARD) // NOTE: required to support "non-standard" JSON variants
>> @Produces(MediaType.WILDCARD)
>> public class JacksonJsonProvider
>>        extends ProviderBase<JacksonJsonProvider,
>>            ObjectMapper,
>>            JsonEndpointConfig, JsonMapperConfigurator>
>> {
>>
>> it's been refactored to extend ProviderBase which is delcared as so:
>> public abstract class ProviderBase<
>>        THIS extends ProviderBase<THIS, MAPPER, EP_CONFIG, MAPPER_CONFIG>,
>>        MAPPER extends ObjectMapper,
>>        EP_CONFIG extends EndpointConfigBase<EP_CONFIG>,
>>        MAPPER_CONFIG extends MapperConfiguratorBase<MAPPER_CONFIG,MAPPER>
>>>
>>        implements
>>            MessageBodyReader<Object>,
>>            MessageBodyWriter<Object>,
>>            Versioned
>> {
>>
>>
>> now what happens when getGenericInterfaces(...) is called now we hit this:
>>
>> Type genericSuperCls = cls.getGenericSuperclass();
>>            if (genericSuperCls instanceof ParameterizedType) {
>>                return new Type[]{genericSuperCls};
>>            }
>>
>> and in handleMapper we end up grabbing the parameterized types
>> which in this case are<JacksonJsonProvider, ObjectMapper, JsonEndpointConfig, JsonMapperConfigurator>
>> and end up having no match for a body writer/reader.
>>
>> Shouldn't getGenericInterfaces been fixed so as to also return the actual interfaces of the class/superclass
>> in this case
>>      implements
>>            MessageBodyReader<Object>,
>>            MessageBodyWriter<Object>,
>>            Versioned
>>
>> It seems to me that only looking at ParameterizedType and returning early
>> leaves out the actual interfaces that a Provider normally implements.
>>
>> For now we are back on 2.1.4 of fasterxml jackson and cxf 2.7.4 but
>> eventually we would like to move 2.2.+
> We can probably introduce a contextual property for the factory to even
> avoid checking all those type variables, to be able to work-around the
> cases like this one, with the complex class hierarchies, and also save
> the time (example, if a user knows a Jackson provider is registered then
> just let it be selected).
>
> Thee other simple workaround is to register a custom JSONProvider which
> simply wraps Jackson 2.2.0.
>
> The actual fix will also need to be done but I probably won't have time
> to do it for 2.7.5 (due shortly), as this fix will be quite sensitive
>
> Thanks, Sergey
>>
>> thanks,
>> parwiz
>>
>
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com