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.
