Refactoring omission - thanks for catching it. I have checked in a fix. G 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 <[email protected]> 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. >> > >
