cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works via Jackson's ObjectMapperm anyway)
Date Tue, 23 Jul 2013 14:31:18 GMT
I made it work though I need to make sure no side-effects are introduced.
Basically, Jackson gets confused if it is not provided a proper 
ParameterizedType, example if we have List<Book> and we offer Book.class 
as a Type, it won't properly add a 'class' property, but that is OK, we 
can make it work. Technically Jackson is correct, if a given object is 
Collection then Type must be ParameterizedType.

What I don't get is why it fails to parse the sequence if no 'class' is 
there - looks like if a given class has JsonTypeInfo then the read 
operation will fail unless a sequence has this property - a bit too 
strict I'd say. Not that CXF JSONProvider has no issues of its own, but 
it can be capable enough :-)

Either way I think we are very close now to making it all work :-)
Cheers. Sergey
On 23/07/13 14:44, Francesco Chicchiriccò wrote:
> On 23/07/2013 14:19, Sergey Beryozkin wrote:
>> Hi
>> On 23/07/13 13:12, Francesco Chicchiriccò wrote:
>>> On 23/07/2013 10:59, Sergey Beryozkin wrote:
>>>> Hi Francesco
>>>> On 23/07/13 08:55, Francesco Chicchiriccò wrote:
>>>>> Hi Sergey,
>>>>> with your latest fix things work much better but still not completely.
>>>>>
>>>> Good news,
>>>>> Basically, with CXF 2.7.7-SNAPSHOT (and @JsonTypeInfo in
>>>>> AbstractSchemaTO) Jackson is able to handle List<T> as in
>>>>>
>>>>> <T extends AbstractSchemaTO> List<T> list()
>>>>>
>>>>> but unfortunately not
>>>>>
>>>>> <T extends AbstractSchemaTO> T read()
>>>>>
>>>>> Any idea?
>>>>>
>>>> Did you mean the other way around ? The latter option is being tested
>>>> in CXF (except that a test 'Book' class is instead of
>>>> 'AbstractSchemaTO'), but I've no a test for the
>>>> '<T extends AbstractSchemaTO> List<T> list()' option, I'll check
>>>
>>> I confirm that List<T> is working while <T> is not.
>>>
>>> I have AbstractSchemaTO annotated as
>>>
>>> @JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, include =
>>> JsonTypeInfo.As.PROPERTY, property = "@class")
>>>
>>> but I have noticed that JSON payload does not contain @class attribute
>>> when asking for List<T>, while it does in case of <T> (example of
>>> singleton list follows):
>>>
>>> Payload: [{"name":"virtualdata","readonly":false}]
>>>
>>> Payload:
>>> {"@class":"org.apache.syncope.common.to.VirSchemaTO","name":"virtualdata","readonly":false}
>>>
>>>
>>>
>>> I am using Jackson 2.2.2: could this be the problem?
>
> I must have messed up my local repo with 2.7.7-SNAPSHOT: after some
> cleanings, I have now <T> working (as expected):
>
>          System.out.println(schemaService.read(AttributableType.USER,
> SchemaType.VIRTUAL, "virtualdata"));
>
> Unfortunately, I have not finished yet because I still get payloads as
> reported above (e.g. JSON array does not contain "@class"): as a result,
> List<T> is only apparently working:
>
>          List<VirSchemaTO> schemas =
> schemaService.list(AttributableType.USER, SchemaType.VIRTUAL);
>          for (VirSchemaTO schema : schemas) {
>              System.out.println(schema);
>          }
>
> The foreach statements throws:
>
> java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to
> org.apache.syncope.common.to.VirSchemaTO
>
> Hence now I have to understand why the server does not put "@class" on
> JSON array elements.
>
> Regards.
>
>>> Could you give me a pointer to the SVN location of the example mentioned
>>> above about Book?
>>>
>> Sure, have a look at
>> http://svn.apache.org/r1505692
>>
>> Cheers, Sergey
>>
>>> Regards.
>>>
>>>>> Thanks again for your priceless support.
>>>> You are too kind :-), thanks a mill for stressing the client runtime...
>>>> Cheers, Sergey
>>>>> Regards.
>>>>>
>>>>> On 22/07/2013 16:04, Sergey Beryozkin wrote:
>>>>>> Sorry for a noise, you were right :-), I was somehow expecting to
>>>>>> login first. Now I'm able to commit
>>>>>>
>>>>>> Cheers, Sergey
>>>>>> On 22/07/13 13:35, Sergey Beryozkin wrote:
>>>>>>> Hi, does not work for me right now, looks like it is a bit late
at
>>>>>>> this
>>>>>>> stage, I guess I'll wait a bit :-)
>>>>>>> Thanks for a tip anyway
>>>>>>> Cheers, Sergey
>>>>>>>
>>>>>>> On 22/07/13 13:27, Francesco Chicchiriccò wrote:
>>>>>>>> On 22/07/2013 14:26, Sergey Beryozkin wrote:
>>>>>>>>> On 22/07/13 13:21, Francesco Chicchiriccò wrote:
>>>>>>>>>> On 22/07/2013 14:12, Sergey Beryozkin wrote:
>>>>>>>>>>> Hi Francesco,
>>>>>>>>>>>
>>>>>>>>>>> I'm realizing I've typed a lot of nonsense to
do with typed
>>>>>>>>>>> proxies
>>>>>>>>>>> :-), the underlying issue is to do with the proxy
>>>>>>>>>>> implementation not
>>>>>>>>>>> unwrapping TypeVariable.
>>>>>>>>>>>
>>>>>>>>>>> The fix will go in as soon as the current Apache
LDAP issues get
>>>>>>>>>>> resolved.
>>>>>>>>>>
>>>>>>>>>> OT: resetting your password via https://id.apache.org
should fix.
>>>>>>>>>
>>>>>>>>> Useful to know, thanks. May be I'll wait a bit longer
though, it
>>>>>>>>> took
>>>>>>>>> me awhile to memorize my current password :-)
>>>>>>>>
>>>>>>>> This morning I've reset with the same old value :-)
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Note though, you'd still need to add @JsonTypeInfo
to
>>>>>>>>>>> AbstractSchemaTO
>>>>>>>>>>> if you need to access the specific subtype's
info in the client
>>>>>>>>>>> code,
>>>>>>>>>>> otherwise Jackson will not be able to create
subtype instances
>>>>>>>>>>> from
>>>>>>>>>>> the payload.
>>>>>>>>>>
>>>>>>>>>> Understood.
>>>>>>>>>>
>>>>>>>>>> Regards.
>>>>>>>>>>
>>>>>>>>>>> On 19/07/13 09:26, Francesco Chicchiriccò wrote:
>>>>>>>>>>>> On 18/07/2013 23:44, Andrei Shakirin wrote:
>>>>>>>>>>>>> Hi Francesco,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am not 100% sure that is a solution
for your case, but I
>>>>>>>>>>>>> have
>>>>>>>>>>>>> used
>>>>>>>>>>>>> Jackson specific annotation in AbstractSchemaTO:
>>>>>>>>>>>>> @JsonTypeInfo(use=Id.CLASS, include=As.PROPERTY,
>>>>>>>>>>>>> property="class").
>>>>>>>>>>>>>
>>>>>>>>>>>>> Annotation is currently deactivated,
because it causes
>>>>>>>>>>>>> conflicts
>>>>>>>>>>>>> with
>>>>>>>>>>>>> Syncope Spring MVC Rest implementation.
>>>>>>>>>>>>> The annotation forces client to send
concrete class name in
>>>>>>>>>>>>> JSON
>>>>>>>>>>>>> representation, as a result service has
more information to
>>>>>>>>>>>>> construct
>>>>>>>>>>>>> concrete class.
>>>>>>>>>>>>> As I can remember, I have tested this
code for JSON using CXF
>>>>>>>>>>>>> JAX-RS
>>>>>>>>>>>>> client and service.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Could you try to activate it and retest?
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Andrei,
>>>>>>>>>>>> when adding such Jackson annotation to AbstractSchemaTO,
the
>>>>>>>>>>>> JSON
>>>>>>>>>>>> payload actually adds the expected attribute:
>>>>>>>>>>>>
>>>>>>>>>>>> {
>>>>>>>>>>>>    "class": "org.apache.syncope.common.to.SchemaTO",
>>>>>>>>>>>>    "name": "fullname",
>>>>>>>>>>>>    "type": "String",
>>>>>>>>>>>>    "mandatoryCondition": "true",
>>>>>>>>>>>>    "enumerationValues": null,
>>>>>>>>>>>>    "enumerationKeys": null,
>>>>>>>>>>>>    "multivalue": false,
>>>>>>>>>>>>    "uniqueConstraint": true,
>>>>>>>>>>>>    "readonly": false,
>>>>>>>>>>>>    "conversionPattern": null,
>>>>>>>>>>>>    "validatorClass": null
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> However, this still generates the (same)
exception:
>>>>>>>>>>>>
>>>>>>>>>>>> java.lang.ClassCastException: java.util.LinkedHashMap
cannot be
>>>>>>>>>>>> cast to
>>>>>>>>>>>> org.apache.syncope.common.to.AbstractSchemaTO
>>>>>>>>>>>>
>>>>>>>>>>>> BTW, I have verified via debug that in ProviderBase
>>>>>>>>>>>> (ancestor of
>>>>>>>>>>>> JacksonJaxbJsonProvider), the method readFrom()
is invoked with
>>>>>>>>>>>> parameters
>>>>>>>>>>>>
>>>>>>>>>>>> Class<Object> type => class
>>>>>>>>>>>> org.apache.syncope.common.to.AbstractSchemaTO
>>>>>>>>>>>> Type genericType => T, with name
>>>>>>>>>>>> ""org.apache.syncope.common.to.AbstractSchemaTO"
>>>>>>>>>>>>
>>>>>>>>>>>> Regards.
>

Mime
View raw message