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. > > > >
