Cassie, thanks for the response. I've filed an issue in Jira: https://issues.apache.org/jira/browse/SHINDIG-202
Cheers, Erin On 4/17/08 2:21 PM, "Cassie" <[EMAIL PROTECTED]> wrote: > Erin - our toJson code should really support that case. That is exactly how > I was hoping to use it for other containers. So.. its either time for us to > switch to a real java->json->java library (especially so we can handle > reading json in to java) or.. we just need to fix that bit of code. > Anybody have time to look into either? > And Erin, it is prob best to file a jira issue against us so that we don't > forget :) > > Thanks! > > - Cassie > > > On Thu, Apr 17, 2008 at 10:19 PM, Alejandro Rivero <[EMAIL PROTECTED]> > wrote: > >> Do you really need all of it? I am pretty happy using the field TAGS >> for my extra info about a Person. >> >> 2008/4/17 Erin Hoffmann <[EMAIL PROTECTED]>: >>> Hello Shindiggers, >>> >>> As part of integrating shindig into our infrastructure, I'm attempting >> to >>> extend the Person class to add two custom fields. I'm having trouble >>> figuring out the cleanest way of doing this. I'm using the Java >>> implementation of the container. >>> >>> What I tried so far was extending >>> org.apache.shindig.social.opensocial.Person and adding the fields to my >>> subclass. My custom implementation of PeopleService then creates >> instances >>> of my subclass. Unfortunately, what happens is that *only* the new >> fields >>> in the subclass get serialized when the gadget makes a request. This >>> appears to be because of the reflection-based serialization to JSON -- >> the >>> private fields in the Person class are unavailable to the serializer. >>> >>> Does anyone have any suggestions about how to get around this? >> Modifying >>> the core shindig code to add my container-specific customizations is not >> an >>> option for pretty obvious reasons -- keeping shindig as a binary >> dependency >>> allows me to upgrade much more cleanly as shindig itself progresses. >>> >>> Cheers, >>> Erin >>> >>
