cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benson Margulies" <>
Subject Re: Aegis versus jaxrs
Date Tue, 21 Oct 2008 13:43:23 GMT
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 <> 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
> <> 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 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
>>> <> 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
>>>> 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.
>>>>> 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.

View raw message