pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gkbr...@mac.com>
Subject Re: How to debug JSONSerializer errors?
Date Wed, 24 Nov 2010 03:41:13 GMT
Refactoring omission - thanks for catching it. I have checked in a fix.

On Nov 23, 2010, at 9:31 PM, Bill van Melle wrote:

> Hmm, change your unit test so that some values are strings rather than ints, and I think
you'll see the error.
> Looking at the sources, it seems to me that the line where it breaks (in the backtrace
I posted earlier) is buggy.  I'm not sure why it needs to be testing the variable 'type' at
this point, but if so it's surely testing the wrong one.  The class has a type field, but
you're also passing a type parameter in various recursive calls.  If the test in readString
needs to be made at all, it should be testing the type that its caller knows about, not the
type field in the JSONSerializer class.
> On Tue, Nov 23, 2010 at 5:30 PM, Greg Brown <gkbrown@mac.com> wrote:
> I just updated the JSONSerializer unit tests to include a test for typed lists, and I
didn't run into any problems. See:
>   http://svn.apache.org/repos/asf/pivot/trunk/core/test/org/apache/pivot/json/test/
> I'm using TypeLiteral in this test - I didn't try creating a subclass of ArrayList (though
that should work too). Maybe there is some other issue at play here?
> On Nov 23, 2010, at 8:03 PM, Greg Brown wrote:
>> Hm. It definitely works if you define a bean that has a property of type ArrayList<Foo>.
I'll see if I can reproduce the issue with just a straight ArrayList<Foo>.
>> On Nov 23, 2010, at 7:41 PM, Bill van Melle wrote:
>>> OK, this is fixed. When JSONSerializer encounters a key that references a non-existent
bean property, that value will be ignored.
>>> Thanks!  I updated my build, and it seems to work correctly when encountering
unknown properties.
>>> However, I still have no way to read a typed json list.  As I reported earlier
in the thread, the TypeLiteral kludge doesn't work, breaking in the serialization code.  I
also tried your other suggestion of defining a trivial class that extend ArrayList<Foo>.
 That one doesn't break until I try to read the contents of the list.  The serializer does
indeed return a ListOfFoo (the trivial class I defined), but the elements of the list are
not of type Foo, but rather of type HashMap, presumably the same untyped string/value pairs
I'd get were I to just ask for untyped json in the first place.

View raw message