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