The RI/required section of the 1.0 FR calls for a MessageBodyReader that delivers JAXBElements! In other words, they aren't really thinking about delivering arbitrary Java objects. Since putting @Provider on a generic class is likely to prove chaotic (or maybe it just works), I'm not quite sure what to do. Is @Provider in the version of the spec we are implementing.
On Tue, Oct 21, 2008 at 9:12 AM, Benson Margulies <[EMAIL PROTECTED]> wrote: > I'll try the experiment with the breakpoint again. > > The API of MessageBodyReader suggests to me that, indeed, it expects > end-programmers to declare things like: > > MessageBodyReader<MyClass> r = new SomeProviderOrAnother<MyClass>(); > MyClass x = r.readFrom(MyClass.class, ....) > > I want to look at the spec to see if its authors gave any examples of > this kind, which is why I asked for a spec pointer. > > It is possible to have an AegisProvider that works 'generically' > (haha), but the programmer would have to program into it a list of > classes for it to start from, via perhaps that setProperties call you > mentioned in earlier email. > > > On Tue, Oct 21, 2008 at 9:00 AM, Sergey Beryozkin > <[EMAIL PROTECTED]> wrote: >> >>> The abstract providers (JAXB and Aegis) are declared as subclasses of >>> MessageBodyReader<Object>, not MessageBodyReader<T>. That in turn >>> forces the parameter to be readFrom(Class<Object> type, ...), which >>> requires the input to be the one and only Object.class object. >> >> Extending from MessageBodyReader<T> ? What does it mean ? Creating a >> provider per every individual type ? >> I'm not a generics guru but it does not make any sense to me. >> >>> >>> I don't see how you can assert that JAXB works when there are no tests >>> that call it. I put a breakpoint on JAXBElementReader.readFrom, and I >>> ran all the JAX-RS unit tests and the systest, and it never got hit. >> >> JAXRSClientServerBookTest.testAddBook >> >>> >>> I'm pretty sure that on the read side JAXB needs some root classes, >>> just like Aegis, and you're not giving it any in the code you have. >>> >>> Please send along a reference to the JAX-RS spec that specifies >>> MessageBodyReader. Perhaps that will reveal what I'm missing. >>> >>> If you look at the AegisProviderTest.java that I checked in, the >>> @Ignored read test fails because I can't pass the actual bean class to >>> the readFrom interface. My friendly challenge to you is this: Create >>> the JAXB equivalent of this test. >> >> Ok :-). >> >>> >>> >>> On Tue, Oct 21, 2008 at 7:36 AM, Sergey Beryozkin >>> <[EMAIL PROTECTED]> wrote: >>>> >>>> Hi, >>>> >>>>> I'm getting into trouble here now that I'm debugging a test case. >>>>> >>>>> readFrom takes Class<Object>, not Class<?>. I don't see how the JAXB >>>>> code could work, as it will try to obtain a type for 'Object.class', >>>> >>>> Unfortunately Class<?> does not compile. Plain Class is passed in to it >>>> from >>>> above and it has all the info. Somehow JAXB is capabe of finding out what >>>> the class contains. Likewise in isReadable/isWriteable we can check if >>>> ObjectFactory is available and we can obtain it in readFrom()/writeTo >>>> even >>>> if Class<Object> is passed in. >>>> >>>> What sort of code won't work for you ? >>>> >>>> Thanks, Sergey >>>> >>>> >>>>> which is the only thing in the world of type Class<Object>, AFAIK. My >>>>> code certainly won't work. I note that none of your unit tests ever >>>>> call the JAXB Element readFrom. I'll look for the systest. Aegis needs >>>>> some clue about what types are going to be read. >>>> >>>> >> >
