You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Aleksey Perfilov <ap...@hi5.com> on 2008/10/10 21:55:35 UTC
crash in BeanJsonConverter
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
Re: crash in BeanJsonConverter
Posted by Bob Evans <bo...@google.com>.
The @Export annotation model seems pretty nice. Our security guys like
it too because it is much less likely that data will escape a POJO by
accidentally declared public.
+1
Bob
On Fri, Oct 10, 2008 at 5:22 PM, Evan Gilbert <ui...@google.com> wrote:
> 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 <ap...@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 <ap...@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" <ap...@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 <aperfilov@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
>> >>>>>
>> >>>>>
>> >>>
>> >>
>> >>
>>
>>
>
Re: crash in BeanJsonConverter
Posted by Ian Boston <ie...@tfd.co.uk>.
There is already a net.sf JSON Lib based converter with a full set of
unit tests that did work just fine for 0.8, bi directional.
It uses net.sf.json which is fully configured to work on the entire
model and doesn't rely on method regexes.
see BeanJsonLibConverter and BeanJsonLibConverterTest.
Has anyone tried it ?
There might be a problem with annotations, since some implementations
will have their own implementations of the Social Model API, in which
case annotations might not work. Can you apply them to interfaces?
(exposing my ignorance on annotations)
If we are going to add a third converter for JSON, we should probably
start deleting code.
Also FYI,
I have a XStream implementation of a BeanXmlConverter that validates
XML output correctly against the XSD.
Its not complete as I havent done the XML->Bean part completely yet,
but all the unit test cases pass correctly and I have added some more
where there was missing coverage.
XStream has Jettison drivers and would support JSON OOTB as well...
but that would be a 4th method!
I haven't committed, and should probably just do this a a code review
before I do.
Ian
On 11 Oct 2008, at 01:22, Evan Gilbert wrote:
> 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
> <ap...@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
>>> <ap...@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" <ap...@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
>>>>>> <aperfilov@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
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>
>>
Re: crash in BeanJsonConverter
Posted by Evan Gilbert <ui...@google.com>.
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 <ap...@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 <ap...@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" <ap...@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 <aperfilov@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
> >>>>>
> >>>>>
> >>>
> >>
> >>
>
>
Re: Drupal Module
Posted by Chris Chabot <ch...@google.com>.
It seems some part of the errors are because the owner and/or viewer id are
set incorrectly?
Updating this to work with the latest php-shindig would probably fix the
remaining errors, there's a lot of work done on fixing those that landed
recently (with the committing of the json-rpc support work).
Great piece of work so far, very exciting to see OpenSocial support in
drupal!
-- Chris
On Tue, Oct 14, 2008 at 6:14 PM, peeyush gulati <pe...@gmail.com>wrote:
> Hi
>
> I tried running compliance test (0.7) on the ShindigIntegrator<http://drupal.org/project/ShindigIntegrator>module for drupal.
>
> Have attached the report and has raised a bug also
> http://drupal.org/node/321151 This would make things easier for all.
>
> Will try update patches soon !!!
>
>
>
> Cheers Peeyush
>
>
>
>
>
>
> On Tue, Oct 14, 2008 at 6:59 PM, Parrott, Justin <JP...@medplus.com>wrote:
>
>> Is there a demo site for this? Also, any plans to integrate into
>> joomla?
>>
>> -----Original Message-----
>> From: astha [mailto:asthabhatnagar2008@gmail.com]
>> Sent: Tuesday, October 14, 2008 4:04 AM
>> To: shindig-dev@incubator.apache.org
>> Subject: Drupal Module
>>
>> Hi Everyone,
>>
>> The Drupal module to integrate Shindig with Drupal is released by
>> Impetus.
>> The details are available in the Drupal project :
>> http://drupal.org/project/ShindigIntegrator.
>>
>> Looking forward for your comments and suggestions.
>>
>> Thanks,
>> Astha
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Confidentiality Notice: The information contained in this electronic
>> transmission is confidential and may be legally privileged. It is intended
>> only for the addressee(s) named above. If you are not an intended recipient,
>> be aware that any disclosure, copying, distribution or use of the
>> information contained in this transmission is prohibited and may be
>> unlawful. If you have received this transmission in error, please notify us
>> by telephone (513) 229-5500 or by email (postmaster@MedPlus.com). After
>> replying, please erase it from your computer system.
>>
>>
>>
>>
>
>
> --
> Thanks and Regards
> Peeyush Gulati
> +91-9916304135
>
Re: Drupal Module
Posted by peeyush gulati <pe...@gmail.com>.
Hi
I tried running compliance test (0.7) on the
ShindigIntegrator<http://drupal.org/project/ShindigIntegrator>module
for drupal.
Have attached the report and has raised a bug also
http://drupal.org/node/321151 This would make things easier for all.
Will try update patches soon !!!
Cheers Peeyush
On Tue, Oct 14, 2008 at 6:59 PM, Parrott, Justin <JP...@medplus.com>wrote:
> Is there a demo site for this? Also, any plans to integrate into
> joomla?
>
> -----Original Message-----
> From: astha [mailto:asthabhatnagar2008@gmail.com]
> Sent: Tuesday, October 14, 2008 4:04 AM
> To: shindig-dev@incubator.apache.org
> Subject: Drupal Module
>
> Hi Everyone,
>
> The Drupal module to integrate Shindig with Drupal is released by
> Impetus.
> The details are available in the Drupal project :
> http://drupal.org/project/ShindigIntegrator.
>
> Looking forward for your comments and suggestions.
>
> Thanks,
> Astha
>
>
>
>
>
>
>
>
>
>
>
> Confidentiality Notice: The information contained in this electronic
> transmission is confidential and may be legally privileged. It is intended
> only for the addressee(s) named above. If you are not an intended recipient,
> be aware that any disclosure, copying, distribution or use of the
> information contained in this transmission is prohibited and may be
> unlawful. If you have received this transmission in error, please notify us
> by telephone (513) 229-5500 or by email (postmaster@MedPlus.com). After
> replying, please erase it from your computer system.
>
>
>
>
--
Thanks and Regards
Peeyush Gulati
+91-9916304135
RE: Drupal Module
Posted by "Parrott, Justin" <JP...@medplus.com>.
Is there a demo site for this? Also, any plans to integrate into
joomla?
-----Original Message-----
From: astha [mailto:asthabhatnagar2008@gmail.com]
Sent: Tuesday, October 14, 2008 4:04 AM
To: shindig-dev@incubator.apache.org
Subject: Drupal Module
Hi Everyone,
The Drupal module to integrate Shindig with Drupal is released by
Impetus.
The details are available in the Drupal project :
http://drupal.org/project/ShindigIntegrator.
Looking forward for your comments and suggestions.
Thanks,
Astha
Confidentiality Notice: The information contained in this electronic transmission is confidential and may be legally privileged. It is intended only for the addressee(s) named above. If you are not an intended recipient, be aware that any disclosure, copying, distribution or use of the information contained in this transmission is prohibited and may be unlawful. If you have received this transmission in error, please notify us by telephone (513) 229-5500 or by email (postmaster@MedPlus.com). After replying, please erase it from your computer system.
RE: Drupal Module
Posted by astha <as...@gmail.com>.
It seems there is some issue with our project page and CVS access.
I have contacted Drupal for this. Will get back, as soon as I get some
updates from them.
Thanks,
Astha
-----Original Message-----
From: peeyush gulati [mailto:peeyushgulati@gmail.com]
Sent: Wednesday, October 15, 2008 3:43 AM
To: shindig-dev@incubator.apache.org; xin_fun@yahoo.com
Subject: Re: Drupal Module
I am facing the same. I figured out couple of more bugs ,s o wanted to
update but could not access !!!!!
On Wed, Oct 15, 2008 at 3:29 AM, xin zhang <xi...@yahoo.com> wrote:
> I got the same thing. I was able to go to that page before.
>
>
> --- On Tue, 10/14/08, Dan Peterson <dp...@google.com> wrote:
>
> > From: Dan Peterson <dp...@google.com>
> > Subject: Re: Drupal Module
> > To: shindig-dev@incubator.apache.org
> > Date: Tuesday, October 14, 2008, 4:54 PM
> > Hi Astha,
> > I tried to access the page and was told:
> > Access deniedYou are not authorized to access this page.
> >
> > Am I the only one with that issue?
> >
> > -Dan
> >
> > On Tue, Oct 14, 2008 at 4:03 AM, astha
> > <as...@gmail.com> wrote:
> >
> > > Hi Everyone,
> > >
> > > The Drupal module to integrate Shindig with Drupal is
> > released by Impetus.
> > > The details are available in the Drupal project :
> > > http://drupal.org/project/ShindigIntegrator.
> > >
> > > Looking forward for your comments and suggestions.
> > >
> > > Thanks,
> > > Astha
> > >
> > >
>
>
>
>
--
Thanks and Regards
Peeyush Gulati
+91-9916304135
Re: Drupal Module
Posted by peeyush gulati <pe...@gmail.com>.
I am facing the same. I figured out couple of more bugs ,s o wanted to
update but could not access !!!!!
On Wed, Oct 15, 2008 at 3:29 AM, xin zhang <xi...@yahoo.com> wrote:
> I got the same thing. I was able to go to that page before.
>
>
> --- On Tue, 10/14/08, Dan Peterson <dp...@google.com> wrote:
>
> > From: Dan Peterson <dp...@google.com>
> > Subject: Re: Drupal Module
> > To: shindig-dev@incubator.apache.org
> > Date: Tuesday, October 14, 2008, 4:54 PM
> > Hi Astha,
> > I tried to access the page and was told:
> > Access deniedYou are not authorized to access this page.
> >
> > Am I the only one with that issue?
> >
> > -Dan
> >
> > On Tue, Oct 14, 2008 at 4:03 AM, astha
> > <as...@gmail.com> wrote:
> >
> > > Hi Everyone,
> > >
> > > The Drupal module to integrate Shindig with Drupal is
> > released by Impetus.
> > > The details are available in the Drupal project :
> > > http://drupal.org/project/ShindigIntegrator.
> > >
> > > Looking forward for your comments and suggestions.
> > >
> > > Thanks,
> > > Astha
> > >
> > >
>
>
>
>
--
Thanks and Regards
Peeyush Gulati
+91-9916304135
Re: Drupal Module
Posted by Ropu <ro...@gmail.com>.
Congrats Astha!
its possible that we'll use it in some projects.
If so, i'll ping you if some help is needed
thx
ropu
On Tue, Dec 9, 2008 at 7:55 AM, Astha Bhatnagar <
asthabhatnagar2008@gmail.com> wrote:
> Hi Everyone,
>
> The development and updates for the module is completed .
> We have done code structure changes and security patches, as asked by
> Drupal.And finaly got the CVS access from them.
> Please check the link : http://drupal.org/project/ShindigIntegrator
>
> Thanks,
> Astha Bhatnagar
>
> On Wed, Oct 15, 2008 at 3:24 AM, Dan Peterson <dp...@google.com>
> wrote:
>
> > Hi Astha,
> > I tried to access the page and was told:
> > Access deniedYou are not authorized to access this page.
> >
> > Am I the only one with that issue?
> >
> > -Dan
> >
> > On Tue, Oct 14, 2008 at 4:03 AM, astha <as...@gmail.com>
> > wrote:
> >
> > > Hi Everyone,
> > >
> > > The Drupal module to integrate Shindig with Drupal is released by
> > Impetus.
> > > The details are available in the Drupal project :
> > > http://drupal.org/project/ShindigIntegrator.
> > >
> > > Looking forward for your comments and suggestions.
> > >
> > > Thanks,
> > > Astha
> > >
> > >
> >
>
--
.-. --- .--. ..-
R o p u
Re: Drupal Module
Posted by Chris Chabot <ch...@google.com>.
Congrats Ashta, that's an awesome project & accomplishment!
On Tue, Dec 9, 2008 at 10:55 AM, Astha Bhatnagar <
asthabhatnagar2008@gmail.com> wrote:
> Hi Everyone,
>
> The development and updates for the module is completed .
> We have done code structure changes and security patches, as asked by
> Drupal.And finaly got the CVS access from them.
> Please check the link : http://drupal.org/project/ShindigIntegrator
>
> Thanks,
> Astha Bhatnagar
>
> On Wed, Oct 15, 2008 at 3:24 AM, Dan Peterson <dp...@google.com>
> wrote:
>
> > Hi Astha,
> > I tried to access the page and was told:
> > Access deniedYou are not authorized to access this page.
> >
> > Am I the only one with that issue?
> >
> > -Dan
> >
> > On Tue, Oct 14, 2008 at 4:03 AM, astha <as...@gmail.com>
> > wrote:
> >
> > > Hi Everyone,
> > >
> > > The Drupal module to integrate Shindig with Drupal is released by
> > Impetus.
> > > The details are available in the Drupal project :
> > > http://drupal.org/project/ShindigIntegrator.
> > >
> > > Looking forward for your comments and suggestions.
> > >
> > > Thanks,
> > > Astha
> > >
> > >
> >
>
Re: Drupal Module
Posted by Astha Bhatnagar <as...@gmail.com>.
Hi Everyone,
The development and updates for the module is completed .
We have done code structure changes and security patches, as asked by
Drupal.And finaly got the CVS access from them.
Please check the link : http://drupal.org/project/ShindigIntegrator
Thanks,
Astha Bhatnagar
On Wed, Oct 15, 2008 at 3:24 AM, Dan Peterson <dp...@google.com> wrote:
> Hi Astha,
> I tried to access the page and was told:
> Access deniedYou are not authorized to access this page.
>
> Am I the only one with that issue?
>
> -Dan
>
> On Tue, Oct 14, 2008 at 4:03 AM, astha <as...@gmail.com>
> wrote:
>
> > Hi Everyone,
> >
> > The Drupal module to integrate Shindig with Drupal is released by
> Impetus.
> > The details are available in the Drupal project :
> > http://drupal.org/project/ShindigIntegrator.
> >
> > Looking forward for your comments and suggestions.
> >
> > Thanks,
> > Astha
> >
> >
>
Re: Drupal Module
Posted by xin zhang <xi...@yahoo.com>.
I got the same thing. I was able to go to that page before.
--- On Tue, 10/14/08, Dan Peterson <dp...@google.com> wrote:
> From: Dan Peterson <dp...@google.com>
> Subject: Re: Drupal Module
> To: shindig-dev@incubator.apache.org
> Date: Tuesday, October 14, 2008, 4:54 PM
> Hi Astha,
> I tried to access the page and was told:
> Access deniedYou are not authorized to access this page.
>
> Am I the only one with that issue?
>
> -Dan
>
> On Tue, Oct 14, 2008 at 4:03 AM, astha
> <as...@gmail.com> wrote:
>
> > Hi Everyone,
> >
> > The Drupal module to integrate Shindig with Drupal is
> released by Impetus.
> > The details are available in the Drupal project :
> > http://drupal.org/project/ShindigIntegrator.
> >
> > Looking forward for your comments and suggestions.
> >
> > Thanks,
> > Astha
> >
> >
Re: Drupal Module
Posted by Dan Peterson <dp...@google.com>.
Hi Astha,
I tried to access the page and was told:
Access deniedYou are not authorized to access this page.
Am I the only one with that issue?
-Dan
On Tue, Oct 14, 2008 at 4:03 AM, astha <as...@gmail.com> wrote:
> Hi Everyone,
>
> The Drupal module to integrate Shindig with Drupal is released by Impetus.
> The details are available in the Drupal project :
> http://drupal.org/project/ShindigIntegrator.
>
> Looking forward for your comments and suggestions.
>
> Thanks,
> Astha
>
>
Drupal Module
Posted by astha <as...@gmail.com>.
Hi Everyone,
The Drupal module to integrate Shindig with Drupal is released by Impetus.
The details are available in the Drupal project :
http://drupal.org/project/ShindigIntegrator.
Looking forward for your comments and suggestions.
Thanks,
Astha
Re: crash in BeanJsonConverter
Posted by Aleksey Perfilov <ap...@hi5.com>.
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 <ap...@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" <ap...@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 <aperfilov@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
>>>>>
>>>>>
>>>
>>
>>
Re: crash in BeanJsonConverter
Posted by Kevin Brown <et...@google.com>.
On Fri, Oct 10, 2008 at 4:08 PM, Aleksey Perfilov <ap...@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" <ap...@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 <aperfilov@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
> >>>
> >>>
> >
>
>
Re: crash in BeanJsonConverter
Posted by Aleksey Perfilov <ap...@hi5.com>.
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.
On 10/10/08 3:33 PM, "Aleksey Perfilov" <ap...@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 <ap...@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
>>>
>>>
>
Re: crash in BeanJsonConverter
Posted by Aleksey Perfilov <ap...@hi5.com>.
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 <ap...@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
>>
>>
Re: crash in BeanJsonConverter
Posted by Kevin Brown <et...@google.com>.
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 <ap...@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
>
>