

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
20 messages in org.apache.incubator.shindig-devRe: crash in BeanJsonConverter| From | Sent On | Attachments |
|---|---|---|
| Aleksey Perfilov | Oct 10, 2008 12:55 pm | |
| Kevin Brown | Oct 10, 2008 2:35 pm | |
| Aleksey Perfilov | Oct 10, 2008 3:32 pm | |
| Aleksey Perfilov | Oct 10, 2008 4:07 pm | |
| Kevin Brown | Oct 10, 2008 4:13 pm | |
| Aleksey Perfilov | Oct 10, 2008 5:07 pm | |
| Evan Gilbert | Oct 10, 2008 5:21 pm | |
| Ian Boston | Oct 11, 2008 5:04 am | |
| astha | Oct 14, 2008 1:03 am | |
| Parrott, Justin | Oct 14, 2008 6:28 am | |
| peeyush gulati | Oct 14, 2008 9:13 am | .zip |
| Chris Chabot | Oct 14, 2008 10:38 am | |
| Dan Peterson | Oct 14, 2008 2:53 pm | |
| xin zhang | Oct 14, 2008 2:58 pm | |
| peeyush gulati | Oct 14, 2008 3:12 pm | |
| astha | Oct 14, 2008 11:45 pm | |
| Astha Bhatnagar | Dec 9, 2008 1:55 am | |
| Ropu | Dec 9, 2008 4:00 am | |
| Chris Chabot | Dec 9, 2008 5:20 am | |
| Bob Evans | Mar 27, 2009 3:19 pm |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: crash in BeanJsonConverter | Actions... |
|---|---|---|
| From: | Evan Gilbert (uid...@google.com) | |
| Date: | Oct 10, 2008 5:21:50 pm | |
| List: | org.apache.incubator.shindig-dev | |
Hi all - I've been working on support for a more flexible converter. I had planned to test this out internally before contributing to Shindig, as I didn't want to make major changes before 0.8. However, there are a few open issues that this may help with so I wanted to send out a patch for discussion.
Patch: https://issues.apache.org/jira/browse/SHINDIG-651 @codereview: http://codereview.appspot.com/7286/show
Brief overview: - Annotate bean methods with @Export annotation to make visible for (de)serialization. Example: @Export String public getFoo() {} - Can also annotate class with @ExportAll for simple value classes that are only used with serialization. - Supports exporting public fields as well.
I built a JSON converter on top of this, seems that it would be easy to add an XML converter as well.
Anyway, would love feedback on: - Whether this is the right general approach - Whether we should wait until after 0.8 - The specific details of the CL
Evan
On Fri, Oct 10, 2008 at 5:07 PM, Aleksey Perfilov <aper...@hi5.com> wrote:
Adapters might be painful, depending on how complex the class that's imported and how many such classes there are.
If all the getters with parameters are simply ignored and we only invoke getFoo(), it will work. If a getter needs some parameters it's not really a simple accessor that's meant for serialization. Of course I'm not certain that all classes will be able to be properly de-serialized from resulting json, but it won't make things worse because right now they would not work for sure :)
For example I have a calendar class that has such accessors, plus other fields that are classes with such accessors, and when I locally modify shindig to ignore getFoo(xxx) type of getters then it works.
On 10/10/08 4:13 PM, "Kevin Brown" <et...@google.com> wrote:
On Fri, Oct 10, 2008 at 4:08 PM, Aleksey Perfilov <aper...@hi5.com> wrote:
I think I misinterpreted what Kevin said.
I agree that using annotations is preferable, although name based matching can be also left in place, in case annotations are not present, as I mentioned, for imported classes.
That doesn't actually address the issue. If you import class X and it has method getFoo(xxx), it doesn't work.
An adapter is definitely preferrable for that.
On 10/10/08 3:33 PM, "Aleksey Perfilov" <aper...@hi5.com> wrote:
True, and of course we do that for our own classes. But in case you end up using some other class that comes from standard Java or some library, you can't annotate that. Perhaps using an adapter in some way might be the only way then.
Besides, I actually don't see annotations being taken into account in BeanJsonConverter code. It just grabs all methods that start with "get" when converting object to json. Actually, I just noticed that in the Person class from org.apache.shindig.social.opensocial.model, getGender is not annotated, neither is getUtcOffset, yet both of them are converted to json.
Aleksey
On 10/10/08 2:36 PM, "Kevin Brown" <et...@google.com> wrote:
I think it would make more sense to use annotations on the beans
instead
of
doing name based matching. That way you're always explicit in what you export and don't have problems like this.
On Fri, Oct 10, 2008 at 12:55 PM, Aleksey Perfilov <aper...@hi5.com wrote:
Hi all,
I¹ve had problems using BeanJsonConverter on objects that contain getters that have 1 or more arguments. Since convertMethodsToJson() expects not to see any arguments on getters, invoke() will crash on getters that have some.
Do you think we should adjust getMatchingMethods() to filter out getters that require parameters? Or just skip those getters in convertMethodsToJson(). I think it is reasonable to assume we don¹t need those for conversion purposes.
Thanks,
Aleksey








.zip