You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Francesco Chicchiriccò <il...@apache.org> on 2013/07/17 16:20:51 UTC
Cannot deserialize JSON via JacksonJaxbJsonProvider (that works via
Jackson's ObjectMapperm anyway)
Hi all,
I have a quite silly question, probably due to my inexperience with CXF.
Basically, in Syncope we have a set of CXF services producing both XML
and JSON (via Jackson).
At high level, I have troubles when reading JSON payload, via WebClient;
the same input string (received as Payload), when given to a bare
Jackson's ObjectMapper instance, works like a charm.
More in detail, the CXF service configuration is the one at [1].
When issuing, with header "Accept: application/json", an HTTP GET
/syncope/cxf/schemas/user/NORMAL/fullname (e.g. read() as defined at
[2]), it returns
{
"name": "fullname",
"type": "String",
"mandatoryCondition": "true",
"enumerationValues": null,
"enumerationKeys": null,
"multivalue": false,
"uniqueConstraint": true,
"readonly": false,
"conversionPattern": null,
"validatorClass": null
}
which looks correct; in fact I am easily able to deserialize such input via
ObjectMapper mapper = new ObjectMapper();
SchemaTO actual = mapper.readValue(writer.toString(),
SchemaTO.class);
but when I try to use WebClient for accessing the same read() method I
get stuck with
ClassCastException: java.util.LinkedHashMap cannot be cast to
org.apache.syncope.common.to.AbstractSchemaTO
which looks definitely like a Jackson exception.
For additional reference, here is my client's Spring configuration [3]
(see 'restClientFactory') and the AbstractSchemaTO [4] and SchemaTO
classes [5].
Nevertheless to say, switching to "Accept: application/xml" makes
everything work again.
I am using CXF 2.7.6-SNAPSHOT (this in order to be able to use Jackson
2.2.2).
Any hint?
Regards.
[1]
https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/resources/restContext.xml
[2]
https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/SchemaService.java
[3]
https://github.com/ilgrosso/syncopeRestClient/blob/master/src/main/resources/applicationContext.xml
[4]
https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
[5]
https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/SchemaTO.java
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Sergey Beryozkin <sb...@gmail.com>.
See comments below,
On 18/07/13 08:26, Francesco Chicchiriccò wrote:
> On 17/07/2013 18:22, Sergey Beryozkin wrote:
>> Hi,
>> On 17/07/13 16:33, Francesco Chicchiriccò wrote:
>>> On 17/07/2013 17:07, Sergey Beryozkin wrote:
>>>> OK, thanks for the info. I'll have a look asap.
>>>> FYI, I thing this what I believe the original client code can be
>>>> simplified. You may have a much simpler injection code directly with
>>>> jaxrs:client, accept & content-type headers can also be set on
>>>> jaxrs:client, so you only should get either a proxy injected or
>>>> WebClient (set 'serviceClass' attribute to a full WebClient class
>>>> name).
>>>>
>>>> At the moment I suspect that a client proxy may not be providing a
>>>> correct type info to Jackson given a somewhat complex interface
>>>> declaration, I'll check. Please try using WebClient directly in
>>>> meantime
>>>
>>> Thanks for suggestion; this works as expected:
>>>
>>> WebClient client = restClientFactory.createWebClient().
>>> path("http://localhost:9080/syncope/cxf/schemas/user/NORMAL/fullname").
>>> accept(MediaType.APPLICATION_JSON);
>>> SchemaTO schema = client.get(SchemaTO.class);
>>>
>>> Looking forward to see how client code could be simplified (and
>>> working...).
>>>
>>
>> Thanks for the update. I'm pretty sure I know what the problem is.
>
> Good :-)
>
>> When we have a proxy, all it sees is
>>
>> <T extends AbstractSchemaTO> T read(@PathParam("kind")
>> AttributableType kind, @PathParam("type") SchemaType type,
>> @PathParam("name") String schemaName);
>>
>> Now the problem here is that SchemaTO.class is not visible to proxy,
>> so what it reports to Jackson is that it expects an instrance of
>> AbstractSchemaTO.class back (which is all it can find from the
>> signature).
>>
>> I wonder if "T extends AbstractSchemaTO" needs to pushed up from all
>> the methods to the interface declaration, and even after that is done,
>> we probably need to add a new factory method, so that one can do
>>
>> SchemaService<SchemaTO> service = JAXRSClientFactory.create(address,
>> new GenericType<SchemaService<SchemaTO>>(){});
>> (using JAX-RS 2.0 GenericType)
>>
>> So that when we do
>>
>> proxy.read(...), the proxy is capable of passing the correct info to
>> the providers,
>>
>> So, it is an interesting enhancement to deal with :-) (won't make into
>> 2.7.6 though, Dan is busy with doing the release as we speak),
>
> Understand: are you going to open an issue for this?
>
>> but in meantime using WebClient will do
>
> As a proof-of-concept, for sure; however, we need to keep the same CXF
> code for both XML and JSON, hence we will be waiting for the enhancement
> above.
>
I'd like to clarify: it is the combination of two things, the way a
service interface is typed and the fact that a proxy mechanism does not
have any way right now to have typed proxies created that prevents this
test from working.
Support for multiple bindings on the client side can equally be achieved
with WebClient or indeed 2.0 Client/WebTarget (working for support for
the latter now). The point is the proxy-based enhancement will only make
a difference if you decide to keep the same client code which is there
at the moment (the pros is that some of the low-level HTTP code is
hidden away) - but the service interface code will need to be changed as
well.
See https://issues.apache.org/jira/browse/CXF-5140
Hmm... This may still not quite do for you perfectly, such an approach
would do for a case where a proxy supports a specific return type, but
you need many return types, then one would have to create many proxies,
one per every var instantiation
Thanks, Sergey
> Thanks again for your support.
> Regards.
>
>>>> On 17/07/13 15:45, Francesco Chicchiriccò wrote:
>>>>> On 17/07/2013 16:39, Sergey Beryozkin wrote:
>>>>>> Hi Francesco,
>>>>>>
>>>>>> How do you use WebClient, let me know and I'll will check
>>>>>
>>>>> (restClientFactory is injected via Spring)
>>>>>
>>>>> restClientFactory.setServiceClass(SchemaService.class);
>>>>> final T serviceProxy = restClientFactory.create(SchemaService.class);
>>>>> WebClient.client(serviceProxy).type(MediaType.APPLICATION_JSON).accept(MediaType.APPLICATION_JSON);
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> then
>>>>>
>>>>> serviceProxy.read(AttributableType.USER, SchemaType.NORMAL,
>>>>> "firstname"));
>>>>>
>>>>> this last statement throws the exception reported below.
>>>>>
>>>>> These are the last lines of the CXF client logging when executing the
>>>>> code above:
>>>>>
>>>>> 16:13:18.808 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Chain
>>>>> org.apache.cxf.phase.PhaseInterceptorChain@555bc78f was created.
>>>>> Current
>>>>> flow:
>>>>> receive [LoggingInInterceptor]
>>>>> pre-protocol-frontend [ClientResponseFilterInterceptor]
>>>>>
>>>>> 16:13:18.808 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain -
>>>>> Invoking
>>>>> handleMessage on interceptor
>>>>> org.apache.cxf.interceptor.LoggingInInterceptor@2b95b0f5
>>>>> 16:13:18.810 [main] INFO o.a.c.i.LoggingInInterceptor - Inbound
>>>>> Message
>>>>> ----------------------------
>>>>> ID: 1
>>>>> Response-Code: 200
>>>>> Encoding: UTF-8
>>>>> Content-Type: application/json;charset=UTF-8
>>>>> Headers: {content-type=[application/json;charset=UTF-8], Date=[Wed, 17
>>>>> Jul 2013 14:13:18 GMT], Server=[Apache-Coyote/1.1],
>>>>> transfer-encoding=[chunked]}
>>>>> Payload:
>>>>> {"name":"firstname","type":"String","mandatoryCondition":"false","enumerationValues":null,"enumerationKeys":null,"multivalue":false,"uniqueConstraint":false,"readonly":false,"conversionPattern":null,"validatorClass":null}
>>>>>
>>>>>
>>>>>
>>>>> --------------------------------------
>>>>> 16:13:18.810 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain -
>>>>> Invoking
>>>>> handleMessage on interceptor
>>>>> org.apache.cxf.jaxrs.client.spec.ClientResponseFilterInterceptor@7aaa977
>>>>>
>>>>> java.lang.ClassCastException: java.util.LinkedHashMap cannot be
>>>>> cast to
>>>>> org.apache.syncope.common.to.AbstractSchemaTO
>>>>>
>>>>>
>>>>> Thanks for your support!
>>>>> Regards.
>>>>>
>>>>>> On 17/07/13 15:20, Francesco Chicchiriccò wrote:
>>>>>>> Hi all,
>>>>>>> I have a quite silly question, probably due to my inexperience with
>>>>>>> CXF.
>>>>>>>
>>>>>>> Basically, in Syncope we have a set of CXF services producing
>>>>>>> both XML
>>>>>>> and JSON (via Jackson).
>>>>>>>
>>>>>>> At high level, I have troubles when reading JSON payload, via
>>>>>>> WebClient;
>>>>>>> the same input string (received as Payload), when given to a bare
>>>>>>> Jackson's ObjectMapper instance, works like a charm.
>>>>>>>
>>>>>>> More in detail, the CXF service configuration is the one at [1].
>>>>>>>
>>>>>>> When issuing, with header "Accept: application/json", an HTTP GET
>>>>>>> /syncope/cxf/schemas/user/NORMAL/fullname (e.g. read() as defined at
>>>>>>> [2]), it returns
>>>>>>>
>>>>>>> {
>>>>>>> "name": "fullname",
>>>>>>> "type": "String",
>>>>>>> "mandatoryCondition": "true",
>>>>>>> "enumerationValues": null,
>>>>>>> "enumerationKeys": null,
>>>>>>> "multivalue": false,
>>>>>>> "uniqueConstraint": true,
>>>>>>> "readonly": false,
>>>>>>> "conversionPattern": null,
>>>>>>> "validatorClass": null
>>>>>>> }
>>>>>>>
>>>>>>> which looks correct; in fact I am easily able to deserialize such
>>>>>>> input via
>>>>>>>
>>>>>>> ObjectMapper mapper = new ObjectMapper();
>>>>>>> SchemaTO actual = mapper.readValue(writer.toString(),
>>>>>>> SchemaTO.class);
>>>>>>>
>>>>>>> but when I try to use WebClient for accessing the same read()
>>>>>>> method I
>>>>>>> get stuck with
>>>>>>>
>>>>>>> ClassCastException: java.util.LinkedHashMap cannot be cast to
>>>>>>> org.apache.syncope.common.to.AbstractSchemaTO
>>>>>>>
>>>>>>> which looks definitely like a Jackson exception.
>>>>>>>
>>>>>>> For additional reference, here is my client's Spring
>>>>>>> configuration [3]
>>>>>>> (see 'restClientFactory') and the AbstractSchemaTO [4] and SchemaTO
>>>>>>> classes [5].
>>>>>>>
>>>>>>> Nevertheless to say, switching to "Accept: application/xml" makes
>>>>>>> everything work again.
>>>>>>>
>>>>>>> I am using CXF 2.7.6-SNAPSHOT (this in order to be able to use
>>>>>>> Jackson
>>>>>>> 2.2.2).
>>>>>>>
>>>>>>> Any hint?
>>>>>>>
>>>>>>> Regards.
>>>>>>>
>>>>>>> [1]
>>>>>>> https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/resources/restContext.xml
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [2]
>>>>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/SchemaService.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [3]
>>>>>>> https://github.com/ilgrosso/syncopeRestClient/blob/master/src/main/resources/applicationContext.xml
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [4]
>>>>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [5]
>>>>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/SchemaTO.java
>>>>>>>
>>
>
RE: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Andrei Shakirin <as...@talend.com>.
Hi Francesco,
Hmm ... I am was pretty sure that the code has worked.
Will double check and keep you updated.
Regards,
Andrei.
> -----Original Message-----
> From: Francesco Chicchiriccò [mailto:ilgrosso@apache.org]
> Sent: Freitag, 19. Juli 2013 10:27
> To: users@cxf.apache.org
> Subject: Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that
> works via Jackson's ObjectMapperm anyway)
>
> 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.
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~ilgrosso/
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 24/07/13 10:01, Francesco Chicchiriccò wrote:
> On 23/07/2013 18:51, Sergey Beryozkin wrote:
>> Actually, CXF does not unwrap ParameterizedType as far as I can see,
>> if we have ParameterizedType whose actual Type value is not
>> TypeVariable then Jackson works OK, but fails if it happens to be
>> ParameterizedType with TypeVariable so your Jackson issue is valid -
>> so I've added some processing specifically around this case:
>>
>> http://svn.apache.org/r1506150
>>
>> I honestly hope all will work now OK, give it a try please with the
>> snapshots a bit later on
>
> Hi Sergey,
> you did it! It works like a charm now, thanks again.
>
Good stuff, thanks for working with me on resolving it...
Cheers, Sergey
> Regards.
>
>> On 23/07/13 15:31, Sergey Beryozkin wrote:
>>> 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.
>
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 23/07/2013 18:51, Sergey Beryozkin wrote:
> Actually, CXF does not unwrap ParameterizedType as far as I can see,
> if we have ParameterizedType whose actual Type value is not
> TypeVariable then Jackson works OK, but fails if it happens to be
> ParameterizedType with TypeVariable so your Jackson issue is valid -
> so I've added some processing specifically around this case:
>
> http://svn.apache.org/r1506150
>
> I honestly hope all will work now OK, give it a try please with the
> snapshots a bit later on
Hi Sergey,
you did it! It works like a charm now, thanks again.
Regards.
> On 23/07/13 15:31, Sergey Beryozkin wrote:
>> 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.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Sergey Beryozkin <sb...@gmail.com>.
Actually, CXF does not unwrap ParameterizedType as far as I can see, if
we have ParameterizedType whose actual Type value is not TypeVariable
then Jackson works OK, but fails if it happens to be ParameterizedType
with TypeVariable so your Jackson issue is valid - so I've added some
processing specifically around this case:
http://svn.apache.org/r1506150
I honestly hope all will work now OK, give it a try please with the
snapshots a bit later on
Thanks, Sergey
On 23/07/13 15:31, Sergey Beryozkin wrote:
> 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.
>>
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Sergey Beryozkin <sb...@gmail.com>.
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.
>
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 23/07/13 15:34, Francesco Chicchiriccò wrote:
> On 23/07/2013 15:52, Sergey Beryozkin wrote:
>>> Hence now I have to understand why the server does not put "@class" on
>>> JSON array elements.
>>
>> That is something to do with Jackson itself I believe
>
> Definitely: I have prepared a simple project showing off this
> misbehavior and sent a comment to Jackson's attention:
> https://github.com/FasterXML/jackson-databind/issues/23#issuecomment-21417625
Thanks for doing that. As I just commented it looks like CXF JAX-RS can
be to blame in that it does not offer a ParameterizedType on the server
side, it unwraps it. That said - if Jackson could support plain Types
for collections then it would be good I guess
Thanks, Sergey
>
>
> Regards.
>
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 23/07/2013 15:52, Sergey Beryozkin wrote:
>> Hence now I have to understand why the server does not put "@class" on
>> JSON array elements.
>
> That is something to do with Jackson itself I believe
Definitely: I have prepared a simple project showing off this
misbehavior and sent a comment to Jackson's attention:
https://github.com/FasterXML/jackson-databind/issues/23#issuecomment-21417625
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Francesco
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
>
Yes, I'm seeing a test involving a proxy and a list failing (but only
with a proxy) - looking into it
> Hence now I have to understand why the server does not put "@class" on
> JSON array elements.
That is something to do with Jackson itself I believe
Cheers, Sergey
>
> 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.
>
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Francesco Chicchiriccò <il...@apache.org>.
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.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Sergey Beryozkin <sb...@gmail.com>.
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?
>
> 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.
>
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Francesco Chicchiriccò <il...@apache.org>.
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?
Could you give me a pointer to the SVN location of the example mentioned
above about Book?
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.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Sergey Beryozkin <sb...@gmail.com>.
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
> 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.
>
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Francesco Chicchiriccò <il...@apache.org>.
Hi Sergey,
with your latest fix things work much better but still not completely.
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?
Thanks again for your priceless support.
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.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Francesco Chicchiriccò <il...@apache.org>.
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.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 :-)
Cheers, Sergey
>
>> 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.
>
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Francesco Chicchiriccò <il...@apache.org>.
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.
> 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.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Sergey Beryozkin <sb...@gmail.com>.
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.
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.
Thanks, Sergey
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.
>
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Francesco Chicchiriccò <il...@apache.org>.
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.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
RE: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Andrei Shakirin <as...@talend.com>.
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?
Regards,
Andrei.
> -----Original Message-----
> From: Francesco Chicchiriccò [mailto:ilgrosso@apache.org]
> Sent: Donnerstag, 18. Juli 2013 09:26
> To: users@cxf.apache.org
> Subject: Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that
> works via Jackson's ObjectMapperm anyway)
>
> On 17/07/2013 18:22, Sergey Beryozkin wrote:
> > Hi,
> > On 17/07/13 16:33, Francesco Chicchiriccò wrote:
> >> On 17/07/2013 17:07, Sergey Beryozkin wrote:
> >>> OK, thanks for the info. I'll have a look asap.
> >>> FYI, I thing this what I believe the original client code can be
> >>> simplified. You may have a much simpler injection code directly with
> >>> jaxrs:client, accept & content-type headers can also be set on
> >>> jaxrs:client, so you only should get either a proxy injected or
> >>> WebClient (set 'serviceClass' attribute to a full WebClient class
> >>> name).
> >>>
> >>> At the moment I suspect that a client proxy may not be providing a
> >>> correct type info to Jackson given a somewhat complex interface
> >>> declaration, I'll check. Please try using WebClient directly in
> >>> meantime
> >>
> >> Thanks for suggestion; this works as expected:
> >>
> >> WebClient client = restClientFactory.createWebClient().
> >>
> path("http://localhost:9080/syncope/cxf/schemas/user/NORMAL/fullname"
> ).
> >> accept(MediaType.APPLICATION_JSON);
> >> SchemaTO schema = client.get(SchemaTO.class);
> >>
> >> Looking forward to see how client code could be simplified (and
> >> working...).
> >>
> >
> > Thanks for the update. I'm pretty sure I know what the problem is.
>
> Good :-)
>
> > When we have a proxy, all it sees is
> >
> > <T extends AbstractSchemaTO> T read(@PathParam("kind")
> > AttributableType kind, @PathParam("type") SchemaType type,
> > @PathParam("name") String schemaName);
> >
> > Now the problem here is that SchemaTO.class is not visible to proxy,
> > so what it reports to Jackson is that it expects an instrance of
> > AbstractSchemaTO.class back (which is all it can find from the
> > signature).
> >
> > I wonder if "T extends AbstractSchemaTO" needs to pushed up from all
> > the methods to the interface declaration, and even after that is done,
> > we probably need to add a new factory method, so that one can do
> >
> > SchemaService<SchemaTO> service = JAXRSClientFactory.create(address,
> > new GenericType<SchemaService<SchemaTO>>(){});
> > (using JAX-RS 2.0 GenericType)
> >
> > So that when we do
> >
> > proxy.read(...), the proxy is capable of passing the correct info to
> > the providers,
> >
> > So, it is an interesting enhancement to deal with :-) (won't make into
> > 2.7.6 though, Dan is busy with doing the release as we speak),
>
> Understand: are you going to open an issue for this?
>
> > but in meantime using WebClient will do
>
> As a proof-of-concept, for sure; however, we need to keep the same CXF
> code for both XML and JSON, hence we will be waiting for the enhancement
> above.
>
> Thanks again for your support.
> Regards.
>
> >>> On 17/07/13 15:45, Francesco Chicchiriccò wrote:
> >>>> On 17/07/2013 16:39, Sergey Beryozkin wrote:
> >>>>> Hi Francesco,
> >>>>>
> >>>>> How do you use WebClient, let me know and I'll will check
> >>>>
> >>>> (restClientFactory is injected via Spring)
> >>>>
> >>>> restClientFactory.setServiceClass(SchemaService.class);
> >>>> final T serviceProxy =
> >>>> restClientFactory.create(SchemaService.class);
> >>>>
> WebClient.client(serviceProxy).type(MediaType.APPLICATION_JSON).acc
> >>>> ept(MediaType.APPLICATION_JSON);
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> then
> >>>>
> >>>> serviceProxy.read(AttributableType.USER, SchemaType.NORMAL,
> >>>> "firstname"));
> >>>>
> >>>> this last statement throws the exception reported below.
> >>>>
> >>>> These are the last lines of the CXF client logging when executing
> >>>> the code above:
> >>>>
> >>>> 16:13:18.808 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain -
> >>>> Chain org.apache.cxf.phase.PhaseInterceptorChain@555bc78f was
> created.
> >>>> Current
> >>>> flow:
> >>>> receive [LoggingInInterceptor]
> >>>> pre-protocol-frontend [ClientResponseFilterInterceptor]
> >>>>
> >>>> 16:13:18.808 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain -
> >>>> Invoking handleMessage on interceptor
> >>>> org.apache.cxf.interceptor.LoggingInInterceptor@2b95b0f5
> >>>> 16:13:18.810 [main] INFO o.a.c.i.LoggingInInterceptor - Inbound
> >>>> Message
> >>>> ----------------------------
> >>>> ID: 1
> >>>> Response-Code: 200
> >>>> Encoding: UTF-8
> >>>> Content-Type: application/json;charset=UTF-8
> >>>> Headers: {content-type=[application/json;charset=UTF-8], Date=[Wed,
> >>>> 17 Jul 2013 14:13:18 GMT], Server=[Apache-Coyote/1.1],
> >>>> transfer-encoding=[chunked]}
> >>>> Payload:
> >>>> {"name":"firstname","type":"String","mandatoryCondition":"false","e
> >>>> numerationValues":null,"enumerationKeys":null,"multivalue":false,"u
> >>>> niqueConstraint":false,"readonly":false,"conversionPattern":null,"v
> >>>> alidatorClass":null}
> >>>>
> >>>>
> >>>>
> >>>> --------------------------------------
> >>>> 16:13:18.810 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain -
> >>>> Invoking handleMessage on interceptor
> >>>> org.apache.cxf.jaxrs.client.spec.ClientResponseFilterInterceptor@7a
> >>>> aa977
> >>>>
> >>>> java.lang.ClassCastException: java.util.LinkedHashMap cannot be
> >>>> cast to org.apache.syncope.common.to.AbstractSchemaTO
> >>>>
> >>>>
> >>>> Thanks for your support!
> >>>> Regards.
> >>>>
> >>>>> On 17/07/13 15:20, Francesco Chicchiriccò wrote:
> >>>>>> Hi all,
> >>>>>> I have a quite silly question, probably due to my inexperience with
> >>>>>> CXF.
> >>>>>>
> >>>>>> Basically, in Syncope we have a set of CXF services producing
> >>>>>> both XML
> >>>>>> and JSON (via Jackson).
> >>>>>>
> >>>>>> At high level, I have troubles when reading JSON payload, via
> >>>>>> WebClient;
> >>>>>> the same input string (received as Payload), when given to a bare
> >>>>>> Jackson's ObjectMapper instance, works like a charm.
> >>>>>>
> >>>>>> More in detail, the CXF service configuration is the one at [1].
> >>>>>>
> >>>>>> When issuing, with header "Accept: application/json", an HTTP GET
> >>>>>> /syncope/cxf/schemas/user/NORMAL/fullname (e.g. read() as
> defined at
> >>>>>> [2]), it returns
> >>>>>>
> >>>>>> {
> >>>>>> "name": "fullname",
> >>>>>> "type": "String",
> >>>>>> "mandatoryCondition": "true",
> >>>>>> "enumerationValues": null,
> >>>>>> "enumerationKeys": null,
> >>>>>> "multivalue": false,
> >>>>>> "uniqueConstraint": true,
> >>>>>> "readonly": false,
> >>>>>> "conversionPattern": null,
> >>>>>> "validatorClass": null
> >>>>>> }
> >>>>>>
> >>>>>> which looks correct; in fact I am easily able to deserialize such
> >>>>>> input via
> >>>>>>
> >>>>>> ObjectMapper mapper = new ObjectMapper();
> >>>>>> SchemaTO actual = mapper.readValue(writer.toString(),
> >>>>>> SchemaTO.class);
> >>>>>>
> >>>>>> but when I try to use WebClient for accessing the same read()
> >>>>>> method I
> >>>>>> get stuck with
> >>>>>>
> >>>>>> ClassCastException: java.util.LinkedHashMap cannot be cast to
> >>>>>> org.apache.syncope.common.to.AbstractSchemaTO
> >>>>>>
> >>>>>> which looks definitely like a Jackson exception.
> >>>>>>
> >>>>>> For additional reference, here is my client's Spring
> >>>>>> configuration [3]
> >>>>>> (see 'restClientFactory') and the AbstractSchemaTO [4] and
> SchemaTO
> >>>>>> classes [5].
> >>>>>>
> >>>>>> Nevertheless to say, switching to "Accept: application/xml" makes
> >>>>>> everything work again.
> >>>>>>
> >>>>>> I am using CXF 2.7.6-SNAPSHOT (this in order to be able to use
> >>>>>> Jackson
> >>>>>> 2.2.2).
> >>>>>>
> >>>>>> Any hint?
> >>>>>>
> >>>>>> Regards.
> >>>>>>
> >>>>>> [1]
> >>>>>>
> https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/resources/
> restContext.xml
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> [2]
> >>>>>>
> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/o
> rg/apache/syncope/common/services/SchemaService.java
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> [3]
> >>>>>>
> https://github.com/ilgrosso/syncopeRestClient/blob/master/src/main/resou
> rces/applicationContext.xml
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> [4]
> >>>>>>
> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/o
> rg/apache/syncope/common/to/AbstractSchemaTO.java
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> [5]
> >>>>>>
> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/o
> rg/apache/syncope/common/to/SchemaTO.java
> >>>>>>
> >
>
> --
> Francesco Chicchiriccò
>
> ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
> http://people.apache.org/~ilgrosso/
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Sergey Beryozkin <sb...@gmail.com>.
I think I mat've pressed Reply too early, sorry
I'd like to clarify: it is the combination of two things, the way a
service interface is typed and the fact that a proxy mechanism does not
have any way right now to have typed proxies created that prevents this
test from working.
Support for multiple bindings on the client side can equally be achieved
with WebClient or indeed 2.0 Client/WebTarget (working for support for
the latter now). The point is the proxy-based enhancement will only make
a difference if you decide to keep the same client code which is there
at the moment (the pros is that some of the low-level HTTP code is
hidden away) - but the service interface code will need to be changed as
well.
See https://issues.apache.org/jira/browse/CXF-5140
Hmm... This may still not quite do for you perfectly, such an approach
would do for a case where a proxy supports a specific return type, but
you need many return types, then one would have to create many proxies,
one per every var instantiation
Thanks, Sergey
On 18/07/13 16:44, Sergey Beryozkin wrote:
> See comments below,
>
> On 18/07/13 08:26, Francesco Chicchiriccò wrote:
>> On 17/07/2013 18:22, Sergey Beryozkin wrote:
>>> Hi,
>>> On 17/07/13 16:33, Francesco Chicchiriccò wrote:
>>>> On 17/07/2013 17:07, Sergey Beryozkin wrote:
>>>>> OK, thanks for the info. I'll have a look asap.
>>>>> FYI, I thing this what I believe the original client code can be
>>>>> simplified. You may have a much simpler injection code directly with
>>>>> jaxrs:client, accept & content-type headers can also be set on
>>>>> jaxrs:client, so you only should get either a proxy injected or
>>>>> WebClient (set 'serviceClass' attribute to a full WebClient class
>>>>> name).
>>>>>
>>>>> At the moment I suspect that a client proxy may not be providing a
>>>>> correct type info to Jackson given a somewhat complex interface
>>>>> declaration, I'll check. Please try using WebClient directly in
>>>>> meantime
>>>>
>>>> Thanks for suggestion; this works as expected:
>>>>
>>>> WebClient client = restClientFactory.createWebClient().
>>>> path("http://localhost:9080/syncope/cxf/schemas/user/NORMAL/fullname").
>>>> accept(MediaType.APPLICATION_JSON);
>>>> SchemaTO schema = client.get(SchemaTO.class);
>>>>
>>>> Looking forward to see how client code could be simplified (and
>>>> working...).
>>>>
>>>
>>> Thanks for the update. I'm pretty sure I know what the problem is.
>>
>> Good :-)
>>
>>> When we have a proxy, all it sees is
>>>
>>> <T extends AbstractSchemaTO> T read(@PathParam("kind")
>>> AttributableType kind, @PathParam("type") SchemaType type,
>>> @PathParam("name") String schemaName);
>>>
>>> Now the problem here is that SchemaTO.class is not visible to proxy,
>>> so what it reports to Jackson is that it expects an instrance of
>>> AbstractSchemaTO.class back (which is all it can find from the
>>> signature).
>>>
>>> I wonder if "T extends AbstractSchemaTO" needs to pushed up from all
>>> the methods to the interface declaration, and even after that is done,
>>> we probably need to add a new factory method, so that one can do
>>>
>>> SchemaService<SchemaTO> service = JAXRSClientFactory.create(address,
>>> new GenericType<SchemaService<SchemaTO>>(){});
>>> (using JAX-RS 2.0 GenericType)
>>>
>>> So that when we do
>>>
>>> proxy.read(...), the proxy is capable of passing the correct info to
>>> the providers,
>>>
>>> So, it is an interesting enhancement to deal with :-) (won't make into
>>> 2.7.6 though, Dan is busy with doing the release as we speak),
>>
>> Understand: are you going to open an issue for this?
>>
>>> but in meantime using WebClient will do
>>
>> As a proof-of-concept, for sure; however, we need to keep the same CXF
>> code for both XML and JSON, hence we will be waiting for the enhancement
>> above.
>>
> I'd like to clarify: it is the combination of two things, the way a
> service interface is typed and the fact that a proxy mechanism does not
> have any way right now to have typed proxies created that prevents this
> test from working.
>
> Support for multiple bindings on the client side can equally be achieved
> with WebClient or indeed 2.0 Client/WebTarget (working for support for
> the latter now). The point is the proxy-based enhancement will only make
> a difference if you decide to keep the same client code which is there
> at the moment (the pros is that some of the low-level HTTP code is
> hidden away) - but the service interface code will need to be changed as
> well.
>
>
>
> I'll keep you up to date,
> Sergey
>
>> Thanks again for your support.
>> Regards.
>>
>>>>> On 17/07/13 15:45, Francesco Chicchiriccò wrote:
>>>>>> On 17/07/2013 16:39, Sergey Beryozkin wrote:
>>>>>>> Hi Francesco,
>>>>>>>
>>>>>>> How do you use WebClient, let me know and I'll will check
>>>>>>
>>>>>> (restClientFactory is injected via Spring)
>>>>>>
>>>>>> restClientFactory.setServiceClass(SchemaService.class);
>>>>>> final T serviceProxy = restClientFactory.create(SchemaService.class);
>>>>>> WebClient.client(serviceProxy).type(MediaType.APPLICATION_JSON).accept(MediaType.APPLICATION_JSON);
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> then
>>>>>>
>>>>>> serviceProxy.read(AttributableType.USER, SchemaType.NORMAL,
>>>>>> "firstname"));
>>>>>>
>>>>>> this last statement throws the exception reported below.
>>>>>>
>>>>>> These are the last lines of the CXF client logging when executing the
>>>>>> code above:
>>>>>>
>>>>>> 16:13:18.808 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Chain
>>>>>> org.apache.cxf.phase.PhaseInterceptorChain@555bc78f was created.
>>>>>> Current
>>>>>> flow:
>>>>>> receive [LoggingInInterceptor]
>>>>>> pre-protocol-frontend [ClientResponseFilterInterceptor]
>>>>>>
>>>>>> 16:13:18.808 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain -
>>>>>> Invoking
>>>>>> handleMessage on interceptor
>>>>>> org.apache.cxf.interceptor.LoggingInInterceptor@2b95b0f5
>>>>>> 16:13:18.810 [main] INFO o.a.c.i.LoggingInInterceptor - Inbound
>>>>>> Message
>>>>>> ----------------------------
>>>>>> ID: 1
>>>>>> Response-Code: 200
>>>>>> Encoding: UTF-8
>>>>>> Content-Type: application/json;charset=UTF-8
>>>>>> Headers: {content-type=[application/json;charset=UTF-8],
>>>>>> Date=[Wed, 17
>>>>>> Jul 2013 14:13:18 GMT], Server=[Apache-Coyote/1.1],
>>>>>> transfer-encoding=[chunked]}
>>>>>> Payload:
>>>>>> {"name":"firstname","type":"String","mandatoryCondition":"false","enumerationValues":null,"enumerationKeys":null,"multivalue":false,"uniqueConstraint":false,"readonly":false,"conversionPattern":null,"validatorClass":null}
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --------------------------------------
>>>>>> 16:13:18.810 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain -
>>>>>> Invoking
>>>>>> handleMessage on interceptor
>>>>>> org.apache.cxf.jaxrs.client.spec.ClientResponseFilterInterceptor@7aaa977
>>>>>>
>>>>>>
>>>>>> java.lang.ClassCastException: java.util.LinkedHashMap cannot be
>>>>>> cast to
>>>>>> org.apache.syncope.common.to.AbstractSchemaTO
>>>>>>
>>>>>>
>>>>>> Thanks for your support!
>>>>>> Regards.
>>>>>>
>>>>>>> On 17/07/13 15:20, Francesco Chicchiriccò wrote:
>>>>>>>> Hi all,
>>>>>>>> I have a quite silly question, probably due to my inexperience with
>>>>>>>> CXF.
>>>>>>>>
>>>>>>>> Basically, in Syncope we have a set of CXF services producing
>>>>>>>> both XML
>>>>>>>> and JSON (via Jackson).
>>>>>>>>
>>>>>>>> At high level, I have troubles when reading JSON payload, via
>>>>>>>> WebClient;
>>>>>>>> the same input string (received as Payload), when given to a bare
>>>>>>>> Jackson's ObjectMapper instance, works like a charm.
>>>>>>>>
>>>>>>>> More in detail, the CXF service configuration is the one at [1].
>>>>>>>>
>>>>>>>> When issuing, with header "Accept: application/json", an HTTP GET
>>>>>>>> /syncope/cxf/schemas/user/NORMAL/fullname (e.g. read() as
>>>>>>>> defined at
>>>>>>>> [2]), it returns
>>>>>>>>
>>>>>>>> {
>>>>>>>> "name": "fullname",
>>>>>>>> "type": "String",
>>>>>>>> "mandatoryCondition": "true",
>>>>>>>> "enumerationValues": null,
>>>>>>>> "enumerationKeys": null,
>>>>>>>> "multivalue": false,
>>>>>>>> "uniqueConstraint": true,
>>>>>>>> "readonly": false,
>>>>>>>> "conversionPattern": null,
>>>>>>>> "validatorClass": null
>>>>>>>> }
>>>>>>>>
>>>>>>>> which looks correct; in fact I am easily able to deserialize such
>>>>>>>> input via
>>>>>>>>
>>>>>>>> ObjectMapper mapper = new ObjectMapper();
>>>>>>>> SchemaTO actual = mapper.readValue(writer.toString(),
>>>>>>>> SchemaTO.class);
>>>>>>>>
>>>>>>>> but when I try to use WebClient for accessing the same read()
>>>>>>>> method I
>>>>>>>> get stuck with
>>>>>>>>
>>>>>>>> ClassCastException: java.util.LinkedHashMap cannot be cast to
>>>>>>>> org.apache.syncope.common.to.AbstractSchemaTO
>>>>>>>>
>>>>>>>> which looks definitely like a Jackson exception.
>>>>>>>>
>>>>>>>> For additional reference, here is my client's Spring
>>>>>>>> configuration [3]
>>>>>>>> (see 'restClientFactory') and the AbstractSchemaTO [4] and SchemaTO
>>>>>>>> classes [5].
>>>>>>>>
>>>>>>>> Nevertheless to say, switching to "Accept: application/xml" makes
>>>>>>>> everything work again.
>>>>>>>>
>>>>>>>> I am using CXF 2.7.6-SNAPSHOT (this in order to be able to use
>>>>>>>> Jackson
>>>>>>>> 2.2.2).
>>>>>>>>
>>>>>>>> Any hint?
>>>>>>>>
>>>>>>>> Regards.
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/resources/restContext.xml
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> [2]
>>>>>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/SchemaService.java
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> [3]
>>>>>>>> https://github.com/ilgrosso/syncopeRestClient/blob/master/src/main/resources/applicationContext.xml
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> [4]
>>>>>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> [5]
>>>>>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/SchemaTO.java
>>>>>>>>
>>>>>>>>
>>>
>>
>
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 17/07/2013 18:22, Sergey Beryozkin wrote:
> Hi,
> On 17/07/13 16:33, Francesco Chicchiriccò wrote:
>> On 17/07/2013 17:07, Sergey Beryozkin wrote:
>>> OK, thanks for the info. I'll have a look asap.
>>> FYI, I thing this what I believe the original client code can be
>>> simplified. You may have a much simpler injection code directly with
>>> jaxrs:client, accept & content-type headers can also be set on
>>> jaxrs:client, so you only should get either a proxy injected or
>>> WebClient (set 'serviceClass' attribute to a full WebClient class
>>> name).
>>>
>>> At the moment I suspect that a client proxy may not be providing a
>>> correct type info to Jackson given a somewhat complex interface
>>> declaration, I'll check. Please try using WebClient directly in
>>> meantime
>>
>> Thanks for suggestion; this works as expected:
>>
>> WebClient client = restClientFactory.createWebClient().
>> path("http://localhost:9080/syncope/cxf/schemas/user/NORMAL/fullname").
>> accept(MediaType.APPLICATION_JSON);
>> SchemaTO schema = client.get(SchemaTO.class);
>>
>> Looking forward to see how client code could be simplified (and
>> working...).
>>
>
> Thanks for the update. I'm pretty sure I know what the problem is.
Good :-)
> When we have a proxy, all it sees is
>
> <T extends AbstractSchemaTO> T read(@PathParam("kind")
> AttributableType kind, @PathParam("type") SchemaType type,
> @PathParam("name") String schemaName);
>
> Now the problem here is that SchemaTO.class is not visible to proxy,
> so what it reports to Jackson is that it expects an instrance of
> AbstractSchemaTO.class back (which is all it can find from the
> signature).
>
> I wonder if "T extends AbstractSchemaTO" needs to pushed up from all
> the methods to the interface declaration, and even after that is done,
> we probably need to add a new factory method, so that one can do
>
> SchemaService<SchemaTO> service = JAXRSClientFactory.create(address,
> new GenericType<SchemaService<SchemaTO>>(){});
> (using JAX-RS 2.0 GenericType)
>
> So that when we do
>
> proxy.read(...), the proxy is capable of passing the correct info to
> the providers,
>
> So, it is an interesting enhancement to deal with :-) (won't make into
> 2.7.6 though, Dan is busy with doing the release as we speak),
Understand: are you going to open an issue for this?
> but in meantime using WebClient will do
As a proof-of-concept, for sure; however, we need to keep the same CXF
code for both XML and JSON, hence we will be waiting for the enhancement
above.
Thanks again for your support.
Regards.
>>> On 17/07/13 15:45, Francesco Chicchiriccò wrote:
>>>> On 17/07/2013 16:39, Sergey Beryozkin wrote:
>>>>> Hi Francesco,
>>>>>
>>>>> How do you use WebClient, let me know and I'll will check
>>>>
>>>> (restClientFactory is injected via Spring)
>>>>
>>>> restClientFactory.setServiceClass(SchemaService.class);
>>>> final T serviceProxy = restClientFactory.create(SchemaService.class);
>>>> WebClient.client(serviceProxy).type(MediaType.APPLICATION_JSON).accept(MediaType.APPLICATION_JSON);
>>>>
>>>>
>>>>
>>>>
>>>> then
>>>>
>>>> serviceProxy.read(AttributableType.USER, SchemaType.NORMAL,
>>>> "firstname"));
>>>>
>>>> this last statement throws the exception reported below.
>>>>
>>>> These are the last lines of the CXF client logging when executing the
>>>> code above:
>>>>
>>>> 16:13:18.808 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Chain
>>>> org.apache.cxf.phase.PhaseInterceptorChain@555bc78f was created.
>>>> Current
>>>> flow:
>>>> receive [LoggingInInterceptor]
>>>> pre-protocol-frontend [ClientResponseFilterInterceptor]
>>>>
>>>> 16:13:18.808 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain -
>>>> Invoking
>>>> handleMessage on interceptor
>>>> org.apache.cxf.interceptor.LoggingInInterceptor@2b95b0f5
>>>> 16:13:18.810 [main] INFO o.a.c.i.LoggingInInterceptor - Inbound
>>>> Message
>>>> ----------------------------
>>>> ID: 1
>>>> Response-Code: 200
>>>> Encoding: UTF-8
>>>> Content-Type: application/json;charset=UTF-8
>>>> Headers: {content-type=[application/json;charset=UTF-8], Date=[Wed, 17
>>>> Jul 2013 14:13:18 GMT], Server=[Apache-Coyote/1.1],
>>>> transfer-encoding=[chunked]}
>>>> Payload:
>>>> {"name":"firstname","type":"String","mandatoryCondition":"false","enumerationValues":null,"enumerationKeys":null,"multivalue":false,"uniqueConstraint":false,"readonly":false,"conversionPattern":null,"validatorClass":null}
>>>>
>>>>
>>>>
>>>> --------------------------------------
>>>> 16:13:18.810 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain -
>>>> Invoking
>>>> handleMessage on interceptor
>>>> org.apache.cxf.jaxrs.client.spec.ClientResponseFilterInterceptor@7aaa977
>>>>
>>>> java.lang.ClassCastException: java.util.LinkedHashMap cannot be
>>>> cast to
>>>> org.apache.syncope.common.to.AbstractSchemaTO
>>>>
>>>>
>>>> Thanks for your support!
>>>> Regards.
>>>>
>>>>> On 17/07/13 15:20, Francesco Chicchiriccò wrote:
>>>>>> Hi all,
>>>>>> I have a quite silly question, probably due to my inexperience with
>>>>>> CXF.
>>>>>>
>>>>>> Basically, in Syncope we have a set of CXF services producing
>>>>>> both XML
>>>>>> and JSON (via Jackson).
>>>>>>
>>>>>> At high level, I have troubles when reading JSON payload, via
>>>>>> WebClient;
>>>>>> the same input string (received as Payload), when given to a bare
>>>>>> Jackson's ObjectMapper instance, works like a charm.
>>>>>>
>>>>>> More in detail, the CXF service configuration is the one at [1].
>>>>>>
>>>>>> When issuing, with header "Accept: application/json", an HTTP GET
>>>>>> /syncope/cxf/schemas/user/NORMAL/fullname (e.g. read() as defined at
>>>>>> [2]), it returns
>>>>>>
>>>>>> {
>>>>>> "name": "fullname",
>>>>>> "type": "String",
>>>>>> "mandatoryCondition": "true",
>>>>>> "enumerationValues": null,
>>>>>> "enumerationKeys": null,
>>>>>> "multivalue": false,
>>>>>> "uniqueConstraint": true,
>>>>>> "readonly": false,
>>>>>> "conversionPattern": null,
>>>>>> "validatorClass": null
>>>>>> }
>>>>>>
>>>>>> which looks correct; in fact I am easily able to deserialize such
>>>>>> input via
>>>>>>
>>>>>> ObjectMapper mapper = new ObjectMapper();
>>>>>> SchemaTO actual = mapper.readValue(writer.toString(),
>>>>>> SchemaTO.class);
>>>>>>
>>>>>> but when I try to use WebClient for accessing the same read()
>>>>>> method I
>>>>>> get stuck with
>>>>>>
>>>>>> ClassCastException: java.util.LinkedHashMap cannot be cast to
>>>>>> org.apache.syncope.common.to.AbstractSchemaTO
>>>>>>
>>>>>> which looks definitely like a Jackson exception.
>>>>>>
>>>>>> For additional reference, here is my client's Spring
>>>>>> configuration [3]
>>>>>> (see 'restClientFactory') and the AbstractSchemaTO [4] and SchemaTO
>>>>>> classes [5].
>>>>>>
>>>>>> Nevertheless to say, switching to "Accept: application/xml" makes
>>>>>> everything work again.
>>>>>>
>>>>>> I am using CXF 2.7.6-SNAPSHOT (this in order to be able to use
>>>>>> Jackson
>>>>>> 2.2.2).
>>>>>>
>>>>>> Any hint?
>>>>>>
>>>>>> Regards.
>>>>>>
>>>>>> [1]
>>>>>> https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/resources/restContext.xml
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> [2]
>>>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/SchemaService.java
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> [3]
>>>>>> https://github.com/ilgrosso/syncopeRestClient/blob/master/src/main/resources/applicationContext.xml
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> [4]
>>>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> [5]
>>>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/SchemaTO.java
>>>>>>
>
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi,
On 17/07/13 16:33, Francesco Chicchiriccò wrote:
> On 17/07/2013 17:07, Sergey Beryozkin wrote:
>> OK, thanks for the info. I'll have a look asap.
>> FYI, I thing this what I believe the original client code can be
>> simplified. You may have a much simpler injection code directly with
>> jaxrs:client, accept & content-type headers can also be set on
>> jaxrs:client, so you only should get either a proxy injected or
>> WebClient (set 'serviceClass' attribute to a full WebClient class name).
>>
>> At the moment I suspect that a client proxy may not be providing a
>> correct type info to Jackson given a somewhat complex interface
>> declaration, I'll check. Please try using WebClient directly in meantime
>
> Thanks for suggestion; this works as expected:
>
> WebClient client = restClientFactory.createWebClient().
> path("http://localhost:9080/syncope/cxf/schemas/user/NORMAL/fullname").
> accept(MediaType.APPLICATION_JSON);
> SchemaTO schema = client.get(SchemaTO.class);
>
> Looking forward to see how client code could be simplified (and
> working...).
>
Thanks for the update. I'm pretty sure I know what the problem is.
When we have a proxy, all it sees is
<T extends AbstractSchemaTO> T read(@PathParam("kind") AttributableType
kind, @PathParam("type") SchemaType type, @PathParam("name") String
schemaName);
Now the problem here is that SchemaTO.class is not visible to proxy, so
what it reports to Jackson is that it expects an instrance of
AbstractSchemaTO.class back (which is all it can find from the signature).
I wonder if "T extends AbstractSchemaTO" needs to pushed up from all the
methods to the interface declaration, and even after that is done, we
probably need to add a new factory method, so that one can do
SchemaService<SchemaTO> service = JAXRSClientFactory.create(address, new
GenericType<SchemaService<SchemaTO>>(){});
(using JAX-RS 2.0 GenericType)
So that when we do
proxy.read(...), the proxy is capable of passing the correct info to the
providers,
So, it is an interesting enhancement to deal with :-) (won't make into
2.7.6 though, Dan is busy with doing the release as we speak), but in
meantime using WebClient will do
Thanks, Sergey
> Regards.
>
>> On 17/07/13 15:45, Francesco Chicchiriccò wrote:
>>> On 17/07/2013 16:39, Sergey Beryozkin wrote:
>>>> Hi Francesco,
>>>>
>>>> How do you use WebClient, let me know and I'll will check
>>>
>>> (restClientFactory is injected via Spring)
>>>
>>> restClientFactory.setServiceClass(SchemaService.class);
>>> final T serviceProxy = restClientFactory.create(SchemaService.class);
>>> WebClient.client(serviceProxy).type(MediaType.APPLICATION_JSON).accept(MediaType.APPLICATION_JSON);
>>>
>>>
>>>
>>> then
>>>
>>> serviceProxy.read(AttributableType.USER, SchemaType.NORMAL,
>>> "firstname"));
>>>
>>> this last statement throws the exception reported below.
>>>
>>> These are the last lines of the CXF client logging when executing the
>>> code above:
>>>
>>> 16:13:18.808 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Chain
>>> org.apache.cxf.phase.PhaseInterceptorChain@555bc78f was created. Current
>>> flow:
>>> receive [LoggingInInterceptor]
>>> pre-protocol-frontend [ClientResponseFilterInterceptor]
>>>
>>> 16:13:18.808 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Invoking
>>> handleMessage on interceptor
>>> org.apache.cxf.interceptor.LoggingInInterceptor@2b95b0f5
>>> 16:13:18.810 [main] INFO o.a.c.i.LoggingInInterceptor - Inbound Message
>>> ----------------------------
>>> ID: 1
>>> Response-Code: 200
>>> Encoding: UTF-8
>>> Content-Type: application/json;charset=UTF-8
>>> Headers: {content-type=[application/json;charset=UTF-8], Date=[Wed, 17
>>> Jul 2013 14:13:18 GMT], Server=[Apache-Coyote/1.1],
>>> transfer-encoding=[chunked]}
>>> Payload:
>>> {"name":"firstname","type":"String","mandatoryCondition":"false","enumerationValues":null,"enumerationKeys":null,"multivalue":false,"uniqueConstraint":false,"readonly":false,"conversionPattern":null,"validatorClass":null}
>>>
>>>
>>> --------------------------------------
>>> 16:13:18.810 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Invoking
>>> handleMessage on interceptor
>>> org.apache.cxf.jaxrs.client.spec.ClientResponseFilterInterceptor@7aaa977
>>> java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to
>>> org.apache.syncope.common.to.AbstractSchemaTO
>>>
>>>
>>> Thanks for your support!
>>> Regards.
>>>
>>>> On 17/07/13 15:20, Francesco Chicchiriccò wrote:
>>>>> Hi all,
>>>>> I have a quite silly question, probably due to my inexperience with
>>>>> CXF.
>>>>>
>>>>> Basically, in Syncope we have a set of CXF services producing both XML
>>>>> and JSON (via Jackson).
>>>>>
>>>>> At high level, I have troubles when reading JSON payload, via
>>>>> WebClient;
>>>>> the same input string (received as Payload), when given to a bare
>>>>> Jackson's ObjectMapper instance, works like a charm.
>>>>>
>>>>> More in detail, the CXF service configuration is the one at [1].
>>>>>
>>>>> When issuing, with header "Accept: application/json", an HTTP GET
>>>>> /syncope/cxf/schemas/user/NORMAL/fullname (e.g. read() as defined at
>>>>> [2]), it returns
>>>>>
>>>>> {
>>>>> "name": "fullname",
>>>>> "type": "String",
>>>>> "mandatoryCondition": "true",
>>>>> "enumerationValues": null,
>>>>> "enumerationKeys": null,
>>>>> "multivalue": false,
>>>>> "uniqueConstraint": true,
>>>>> "readonly": false,
>>>>> "conversionPattern": null,
>>>>> "validatorClass": null
>>>>> }
>>>>>
>>>>> which looks correct; in fact I am easily able to deserialize such
>>>>> input via
>>>>>
>>>>> ObjectMapper mapper = new ObjectMapper();
>>>>> SchemaTO actual = mapper.readValue(writer.toString(),
>>>>> SchemaTO.class);
>>>>>
>>>>> but when I try to use WebClient for accessing the same read() method I
>>>>> get stuck with
>>>>>
>>>>> ClassCastException: java.util.LinkedHashMap cannot be cast to
>>>>> org.apache.syncope.common.to.AbstractSchemaTO
>>>>>
>>>>> which looks definitely like a Jackson exception.
>>>>>
>>>>> For additional reference, here is my client's Spring configuration [3]
>>>>> (see 'restClientFactory') and the AbstractSchemaTO [4] and SchemaTO
>>>>> classes [5].
>>>>>
>>>>> Nevertheless to say, switching to "Accept: application/xml" makes
>>>>> everything work again.
>>>>>
>>>>> I am using CXF 2.7.6-SNAPSHOT (this in order to be able to use Jackson
>>>>> 2.2.2).
>>>>>
>>>>> Any hint?
>>>>>
>>>>> Regards.
>>>>>
>>>>> [1]
>>>>> https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/resources/restContext.xml
>>>>>
>>>>>
>>>>>
>>>>> [2]
>>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/SchemaService.java
>>>>>
>>>>>
>>>>>
>>>>> [3]
>>>>> https://github.com/ilgrosso/syncopeRestClient/blob/master/src/main/resources/applicationContext.xml
>>>>>
>>>>>
>>>>>
>>>>> [4]
>>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>>>>>
>>>>>
>>>>>
>>>>> [5]
>>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/SchemaTO.java
>>>>>
>>>>>
>>>
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 17/07/2013 17:07, Sergey Beryozkin wrote:
> OK, thanks for the info. I'll have a look asap.
> FYI, I thing this what I believe the original client code can be
> simplified. You may have a much simpler injection code directly with
> jaxrs:client, accept & content-type headers can also be set on
> jaxrs:client, so you only should get either a proxy injected or
> WebClient (set 'serviceClass' attribute to a full WebClient class name).
>
> At the moment I suspect that a client proxy may not be providing a
> correct type info to Jackson given a somewhat complex interface
> declaration, I'll check. Please try using WebClient directly in meantime
Thanks for suggestion; this works as expected:
WebClient client = restClientFactory.createWebClient().
path("http://localhost:9080/syncope/cxf/schemas/user/NORMAL/fullname").
accept(MediaType.APPLICATION_JSON);
SchemaTO schema = client.get(SchemaTO.class);
Looking forward to see how client code could be simplified (and working...).
Regards.
> On 17/07/13 15:45, Francesco Chicchiriccò wrote:
>> On 17/07/2013 16:39, Sergey Beryozkin wrote:
>>> Hi Francesco,
>>>
>>> How do you use WebClient, let me know and I'll will check
>>
>> (restClientFactory is injected via Spring)
>>
>> restClientFactory.setServiceClass(SchemaService.class);
>> final T serviceProxy = restClientFactory.create(SchemaService.class);
>> WebClient.client(serviceProxy).type(MediaType.APPLICATION_JSON).accept(MediaType.APPLICATION_JSON);
>>
>>
>>
>> then
>>
>> serviceProxy.read(AttributableType.USER, SchemaType.NORMAL,
>> "firstname"));
>>
>> this last statement throws the exception reported below.
>>
>> These are the last lines of the CXF client logging when executing the
>> code above:
>>
>> 16:13:18.808 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Chain
>> org.apache.cxf.phase.PhaseInterceptorChain@555bc78f was created. Current
>> flow:
>> receive [LoggingInInterceptor]
>> pre-protocol-frontend [ClientResponseFilterInterceptor]
>>
>> 16:13:18.808 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Invoking
>> handleMessage on interceptor
>> org.apache.cxf.interceptor.LoggingInInterceptor@2b95b0f5
>> 16:13:18.810 [main] INFO o.a.c.i.LoggingInInterceptor - Inbound Message
>> ----------------------------
>> ID: 1
>> Response-Code: 200
>> Encoding: UTF-8
>> Content-Type: application/json;charset=UTF-8
>> Headers: {content-type=[application/json;charset=UTF-8], Date=[Wed, 17
>> Jul 2013 14:13:18 GMT], Server=[Apache-Coyote/1.1],
>> transfer-encoding=[chunked]}
>> Payload:
>> {"name":"firstname","type":"String","mandatoryCondition":"false","enumerationValues":null,"enumerationKeys":null,"multivalue":false,"uniqueConstraint":false,"readonly":false,"conversionPattern":null,"validatorClass":null}
>>
>>
>> --------------------------------------
>> 16:13:18.810 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Invoking
>> handleMessage on interceptor
>> org.apache.cxf.jaxrs.client.spec.ClientResponseFilterInterceptor@7aaa977
>> java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to
>> org.apache.syncope.common.to.AbstractSchemaTO
>>
>>
>> Thanks for your support!
>> Regards.
>>
>>> On 17/07/13 15:20, Francesco Chicchiriccò wrote:
>>>> Hi all,
>>>> I have a quite silly question, probably due to my inexperience with
>>>> CXF.
>>>>
>>>> Basically, in Syncope we have a set of CXF services producing both XML
>>>> and JSON (via Jackson).
>>>>
>>>> At high level, I have troubles when reading JSON payload, via
>>>> WebClient;
>>>> the same input string (received as Payload), when given to a bare
>>>> Jackson's ObjectMapper instance, works like a charm.
>>>>
>>>> More in detail, the CXF service configuration is the one at [1].
>>>>
>>>> When issuing, with header "Accept: application/json", an HTTP GET
>>>> /syncope/cxf/schemas/user/NORMAL/fullname (e.g. read() as defined at
>>>> [2]), it returns
>>>>
>>>> {
>>>> "name": "fullname",
>>>> "type": "String",
>>>> "mandatoryCondition": "true",
>>>> "enumerationValues": null,
>>>> "enumerationKeys": null,
>>>> "multivalue": false,
>>>> "uniqueConstraint": true,
>>>> "readonly": false,
>>>> "conversionPattern": null,
>>>> "validatorClass": null
>>>> }
>>>>
>>>> which looks correct; in fact I am easily able to deserialize such
>>>> input via
>>>>
>>>> ObjectMapper mapper = new ObjectMapper();
>>>> SchemaTO actual = mapper.readValue(writer.toString(),
>>>> SchemaTO.class);
>>>>
>>>> but when I try to use WebClient for accessing the same read() method I
>>>> get stuck with
>>>>
>>>> ClassCastException: java.util.LinkedHashMap cannot be cast to
>>>> org.apache.syncope.common.to.AbstractSchemaTO
>>>>
>>>> which looks definitely like a Jackson exception.
>>>>
>>>> For additional reference, here is my client's Spring configuration [3]
>>>> (see 'restClientFactory') and the AbstractSchemaTO [4] and SchemaTO
>>>> classes [5].
>>>>
>>>> Nevertheless to say, switching to "Accept: application/xml" makes
>>>> everything work again.
>>>>
>>>> I am using CXF 2.7.6-SNAPSHOT (this in order to be able to use Jackson
>>>> 2.2.2).
>>>>
>>>> Any hint?
>>>>
>>>> Regards.
>>>>
>>>> [1]
>>>> https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/resources/restContext.xml
>>>>
>>>>
>>>>
>>>> [2]
>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/SchemaService.java
>>>>
>>>>
>>>>
>>>> [3]
>>>> https://github.com/ilgrosso/syncopeRestClient/blob/master/src/main/resources/applicationContext.xml
>>>>
>>>>
>>>>
>>>> [4]
>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>>>>
>>>>
>>>>
>>>> [5]
>>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/SchemaTO.java
>>>>
>>>>
>>
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Sergey Beryozkin <sb...@gmail.com>.
OK, thanks for the info. I'll have a look asap.
FYI, I thing this what I believe the original client code can be
simplified. You may have a much simpler injection code directly with
jaxrs:client, accept & content-type headers can also be set on
jaxrs:client, so you only should get either a proxy injected or
WebClient (set 'serviceClass' attribute to a full WebClient class name).
At the moment I suspect that a client proxy may not be providing a
correct type info to Jackson given a somewhat complex interface
declaration, I'll check. Please try using WebClient directly in meantime
Thanks, Sergey
On 17/07/13 15:45, Francesco Chicchiriccò wrote:
> On 17/07/2013 16:39, Sergey Beryozkin wrote:
>> Hi Francesco,
>>
>> How do you use WebClient, let me know and I'll will check
>
> (restClientFactory is injected via Spring)
>
> restClientFactory.setServiceClass(SchemaService.class);
> final T serviceProxy = restClientFactory.create(SchemaService.class);
> WebClient.client(serviceProxy).type(MediaType.APPLICATION_JSON).accept(MediaType.APPLICATION_JSON);
>
>
> then
>
> serviceProxy.read(AttributableType.USER, SchemaType.NORMAL, "firstname"));
>
> this last statement throws the exception reported below.
>
> These are the last lines of the CXF client logging when executing the
> code above:
>
> 16:13:18.808 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Chain
> org.apache.cxf.phase.PhaseInterceptorChain@555bc78f was created. Current
> flow:
> receive [LoggingInInterceptor]
> pre-protocol-frontend [ClientResponseFilterInterceptor]
>
> 16:13:18.808 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Invoking
> handleMessage on interceptor
> org.apache.cxf.interceptor.LoggingInInterceptor@2b95b0f5
> 16:13:18.810 [main] INFO o.a.c.i.LoggingInInterceptor - Inbound Message
> ----------------------------
> ID: 1
> Response-Code: 200
> Encoding: UTF-8
> Content-Type: application/json;charset=UTF-8
> Headers: {content-type=[application/json;charset=UTF-8], Date=[Wed, 17
> Jul 2013 14:13:18 GMT], Server=[Apache-Coyote/1.1],
> transfer-encoding=[chunked]}
> Payload:
> {"name":"firstname","type":"String","mandatoryCondition":"false","enumerationValues":null,"enumerationKeys":null,"multivalue":false,"uniqueConstraint":false,"readonly":false,"conversionPattern":null,"validatorClass":null}
>
> --------------------------------------
> 16:13:18.810 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Invoking
> handleMessage on interceptor
> org.apache.cxf.jaxrs.client.spec.ClientResponseFilterInterceptor@7aaa977
> java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to
> org.apache.syncope.common.to.AbstractSchemaTO
>
>
> Thanks for your support!
> Regards.
>
>> On 17/07/13 15:20, Francesco Chicchiriccò wrote:
>>> Hi all,
>>> I have a quite silly question, probably due to my inexperience with CXF.
>>>
>>> Basically, in Syncope we have a set of CXF services producing both XML
>>> and JSON (via Jackson).
>>>
>>> At high level, I have troubles when reading JSON payload, via WebClient;
>>> the same input string (received as Payload), when given to a bare
>>> Jackson's ObjectMapper instance, works like a charm.
>>>
>>> More in detail, the CXF service configuration is the one at [1].
>>>
>>> When issuing, with header "Accept: application/json", an HTTP GET
>>> /syncope/cxf/schemas/user/NORMAL/fullname (e.g. read() as defined at
>>> [2]), it returns
>>>
>>> {
>>> "name": "fullname",
>>> "type": "String",
>>> "mandatoryCondition": "true",
>>> "enumerationValues": null,
>>> "enumerationKeys": null,
>>> "multivalue": false,
>>> "uniqueConstraint": true,
>>> "readonly": false,
>>> "conversionPattern": null,
>>> "validatorClass": null
>>> }
>>>
>>> which looks correct; in fact I am easily able to deserialize such
>>> input via
>>>
>>> ObjectMapper mapper = new ObjectMapper();
>>> SchemaTO actual = mapper.readValue(writer.toString(),
>>> SchemaTO.class);
>>>
>>> but when I try to use WebClient for accessing the same read() method I
>>> get stuck with
>>>
>>> ClassCastException: java.util.LinkedHashMap cannot be cast to
>>> org.apache.syncope.common.to.AbstractSchemaTO
>>>
>>> which looks definitely like a Jackson exception.
>>>
>>> For additional reference, here is my client's Spring configuration [3]
>>> (see 'restClientFactory') and the AbstractSchemaTO [4] and SchemaTO
>>> classes [5].
>>>
>>> Nevertheless to say, switching to "Accept: application/xml" makes
>>> everything work again.
>>>
>>> I am using CXF 2.7.6-SNAPSHOT (this in order to be able to use Jackson
>>> 2.2.2).
>>>
>>> Any hint?
>>>
>>> Regards.
>>>
>>> [1]
>>> https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/resources/restContext.xml
>>>
>>>
>>> [2]
>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/SchemaService.java
>>>
>>>
>>> [3]
>>> https://github.com/ilgrosso/syncopeRestClient/blob/master/src/main/resources/applicationContext.xml
>>>
>>>
>>> [4]
>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>>>
>>>
>>> [5]
>>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/SchemaTO.java
>>>
>
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 17/07/2013 16:39, Sergey Beryozkin wrote:
> Hi Francesco,
>
> How do you use WebClient, let me know and I'll will check
(restClientFactory is injected via Spring)
restClientFactory.setServiceClass(SchemaService.class);
final T serviceProxy = restClientFactory.create(SchemaService.class);
WebClient.client(serviceProxy).type(MediaType.APPLICATION_JSON).accept(MediaType.APPLICATION_JSON);
then
serviceProxy.read(AttributableType.USER, SchemaType.NORMAL, "firstname"));
this last statement throws the exception reported below.
These are the last lines of the CXF client logging when executing the
code above:
16:13:18.808 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Chain
org.apache.cxf.phase.PhaseInterceptorChain@555bc78f was created. Current
flow:
receive [LoggingInInterceptor]
pre-protocol-frontend [ClientResponseFilterInterceptor]
16:13:18.808 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Invoking
handleMessage on interceptor
org.apache.cxf.interceptor.LoggingInInterceptor@2b95b0f5
16:13:18.810 [main] INFO o.a.c.i.LoggingInInterceptor - Inbound Message
----------------------------
ID: 1
Response-Code: 200
Encoding: UTF-8
Content-Type: application/json;charset=UTF-8
Headers: {content-type=[application/json;charset=UTF-8], Date=[Wed, 17
Jul 2013 14:13:18 GMT], Server=[Apache-Coyote/1.1],
transfer-encoding=[chunked]}
Payload:
{"name":"firstname","type":"String","mandatoryCondition":"false","enumerationValues":null,"enumerationKeys":null,"multivalue":false,"uniqueConstraint":false,"readonly":false,"conversionPattern":null,"validatorClass":null}
--------------------------------------
16:13:18.810 [main] DEBUG o.a.cxf.phase.PhaseInterceptorChain - Invoking
handleMessage on interceptor
org.apache.cxf.jaxrs.client.spec.ClientResponseFilterInterceptor@7aaa977
java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to
org.apache.syncope.common.to.AbstractSchemaTO
Thanks for your support!
Regards.
> On 17/07/13 15:20, Francesco Chicchiriccò wrote:
>> Hi all,
>> I have a quite silly question, probably due to my inexperience with CXF.
>>
>> Basically, in Syncope we have a set of CXF services producing both XML
>> and JSON (via Jackson).
>>
>> At high level, I have troubles when reading JSON payload, via WebClient;
>> the same input string (received as Payload), when given to a bare
>> Jackson's ObjectMapper instance, works like a charm.
>>
>> More in detail, the CXF service configuration is the one at [1].
>>
>> When issuing, with header "Accept: application/json", an HTTP GET
>> /syncope/cxf/schemas/user/NORMAL/fullname (e.g. read() as defined at
>> [2]), it returns
>>
>> {
>> "name": "fullname",
>> "type": "String",
>> "mandatoryCondition": "true",
>> "enumerationValues": null,
>> "enumerationKeys": null,
>> "multivalue": false,
>> "uniqueConstraint": true,
>> "readonly": false,
>> "conversionPattern": null,
>> "validatorClass": null
>> }
>>
>> which looks correct; in fact I am easily able to deserialize such
>> input via
>>
>> ObjectMapper mapper = new ObjectMapper();
>> SchemaTO actual = mapper.readValue(writer.toString(),
>> SchemaTO.class);
>>
>> but when I try to use WebClient for accessing the same read() method I
>> get stuck with
>>
>> ClassCastException: java.util.LinkedHashMap cannot be cast to
>> org.apache.syncope.common.to.AbstractSchemaTO
>>
>> which looks definitely like a Jackson exception.
>>
>> For additional reference, here is my client's Spring configuration [3]
>> (see 'restClientFactory') and the AbstractSchemaTO [4] and SchemaTO
>> classes [5].
>>
>> Nevertheless to say, switching to "Accept: application/xml" makes
>> everything work again.
>>
>> I am using CXF 2.7.6-SNAPSHOT (this in order to be able to use Jackson
>> 2.2.2).
>>
>> Any hint?
>>
>> Regards.
>>
>> [1]
>> https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/resources/restContext.xml
>>
>>
>> [2]
>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/SchemaService.java
>>
>>
>> [3]
>> https://github.com/ilgrosso/syncopeRestClient/blob/master/src/main/resources/applicationContext.xml
>>
>>
>> [4]
>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>>
>>
>> [5]
>> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/SchemaTO.java
>>
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: Cannot deserialize JSON via JacksonJaxbJsonProvider (that works
via Jackson's ObjectMapperm anyway)
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Francesco,
How do you use WebClient, let me know and I'll will check
Cheers, Sergey
On 17/07/13 15:20, Francesco Chicchiriccò wrote:
> Hi all,
> I have a quite silly question, probably due to my inexperience with CXF.
>
> Basically, in Syncope we have a set of CXF services producing both XML
> and JSON (via Jackson).
>
> At high level, I have troubles when reading JSON payload, via WebClient;
> the same input string (received as Payload), when given to a bare
> Jackson's ObjectMapper instance, works like a charm.
>
> More in detail, the CXF service configuration is the one at [1].
>
> When issuing, with header "Accept: application/json", an HTTP GET
> /syncope/cxf/schemas/user/NORMAL/fullname (e.g. read() as defined at
> [2]), it returns
>
> {
> "name": "fullname",
> "type": "String",
> "mandatoryCondition": "true",
> "enumerationValues": null,
> "enumerationKeys": null,
> "multivalue": false,
> "uniqueConstraint": true,
> "readonly": false,
> "conversionPattern": null,
> "validatorClass": null
> }
>
> which looks correct; in fact I am easily able to deserialize such input via
>
> ObjectMapper mapper = new ObjectMapper();
> SchemaTO actual = mapper.readValue(writer.toString(),
> SchemaTO.class);
>
> but when I try to use WebClient for accessing the same read() method I
> get stuck with
>
> ClassCastException: java.util.LinkedHashMap cannot be cast to
> org.apache.syncope.common.to.AbstractSchemaTO
>
> which looks definitely like a Jackson exception.
>
> For additional reference, here is my client's Spring configuration [3]
> (see 'restClientFactory') and the AbstractSchemaTO [4] and SchemaTO
> classes [5].
>
> Nevertheless to say, switching to "Accept: application/xml" makes
> everything work again.
>
> I am using CXF 2.7.6-SNAPSHOT (this in order to be able to use Jackson
> 2.2.2).
>
> Any hint?
>
> Regards.
>
> [1]
> https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/resources/restContext.xml
>
> [2]
> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/SchemaService.java
>
> [3]
> https://github.com/ilgrosso/syncopeRestClient/blob/master/src/main/resources/applicationContext.xml
>
> [4]
> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
>
> [5]
> https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/SchemaTO.java
>
>