This is now OT for Restlet, and I don't know enough about Jackson annotations to help. Best to look at the Jackson forums.
--tim On Tue, Apr 19, 2011 at 1:00 PM, Steve Ferris <[email protected]>wrote: > So AMRecord on server -> JSON -> AMRecord on client, but Set<AMRecord> on > server -> JSON -> Set<LinkedHashMap> on client? If so, read on. > > Restlet's JacksonRepresentation uses mapper.readValue(representation, > targetType.class) to do the work, but type parameters are erased, so the > return type is Set.class, and the call becomes > mapper.readValue(representation, Set.class). Jackson does the best it can in > that case; the serialized AMRecord looks like a map. > > > Excellent, thanks very much. This explains the underlying flow very > clearly. > > > There are two ways to handle this. If you control the source for AMRecord, > you can tell Jackson (by adding an annotation) to include type information > when it serializes an AMRecord, so that it will be reconstituted properly. > If you don't have access to the source, you'll need to either introduce a > holder type for Set<AMRecord> or write your own subclass of > JacksonRepresentation with custom handling for this case. > > > I have the source to AMRecord, but from reading through this: > > http://wiki.fasterxml.com/JacksonAnnotations > > It is unclear to me if the granularity of the annotation is at the class > level or if I need one annotation per property? > > regards > Steve > > > > --tim > > On Tue, Apr 19, 2011 at 10:46 AM, Steve Ferris <[email protected] > > wrote: > >> Hi, >> >> That is indeed the reason for the class cast exception, but on the server >> the Set is populated with AMRecord objects and after the Jackson >> representation un-marshalling the AMRecord object has become a >> LinkedHashMap. >> >> So there has to be something going on in the Jackson/JSON representation >> implementation that prevents my custom class working in a collection, but >> fine when it's just on its own. >> >> regards >> Steve >> >> -- >> Steve Ferris : ForgeRock AS : e: [email protected] >> t: +44 (0)7813 709285 f: +44 (0)7971 042421 w: forgerock.com >> OpenAM, the new name for OpenSSO >> >> On 19 Apr 2011, at 3:40pm, Tim Peierls wrote: >> >> A LinkedHashMap is not a Set. Could that explain the class cast exception? >> >> --tim >> >> On Tue, Apr 19, 2011 at 7:13 AM, Steve Ferris <[email protected] >> > wrote: >> >>> Hi, >>> >>> I have a custom class AMRecord which is being handled in an unexpected >>> way. >>> >>> Two RESTlet calls: >>> >>> @Get >>> public AMRecord read(String id) { >>> >>> and >>> >>> @Get >>> public Set<AMRecord> readWithSecKey(String id) { >>> >>> Jackson can cope with AMRecord as the read call works, my client code >>> looks like this: >>> >>> ClientResource resource = new ClientResource(resourceUrl + >>> "/read"); >>> ReadResource readResource = resource.wrap(ReadResource.class); >>> >>> AMRecord record = readResource.read("43478392743"); >>> >>> I get back an AMRecord instance. >>> >>> But for the Set, on the client I get a class cast exception >>> >>> ClientResource resource = new ClientResource(resourceUrl + >>> "/readwithseckey"); >>> ReadWithSecKeyResource secReadResource = >>> resource.wrap(ReadWithSecKeyResource.class); >>> >>> Set<AMRecord> sessions = >>> secReadResource.readWithSecKey("uid=steve,ou=users,o=openam"); >>> >>> This is because the Set sessions has a LinkedHashMap rather than AMRecord >>> entries. The LinkedHashMap is populated with the data from the AMRecord that >>> should be present. >>> >>> Any ideas? >>> >>> thanks >>> Steve >>> >>> -- >>> Steve Ferris : ForgeRock AS : e: [email protected] >>> t: +44 (0)7813 709285 f: +44 (0)7971 042421 w: forgerock.com >>> OpenAM, the new name for OpenSSO >>> >>> >> >> > > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2721482
