> 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 <steve.fer...@forgerock.com> 
> 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: steve.fer...@forgerock.com
> 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 <steve.fer...@forgerock.com> 
>> 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: steve.fer...@forgerock.com
>> 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=2721467

Reply via email to