cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <>
Subject Re: Aegis versus jaxrs
Date Tue, 21 Oct 2008 17:15:29 GMT

> Do you participate in the JSR Process for this thing? As the FR
> stands, @Provider seems to be required.

I don't participate - I started working with our JAX-RS impl at the time it was at 0.5 or
0.4 level.
I'm asking questions though periodically.

@Provider is needed only if a CXF user who wrote a custom provider would want to start using
Jersey, so for that provider be picked 
up by Jersey they'd need to ensure @Provider is there. We'll most likely need it for TCK too
- but may be we'll be able to 
auto-generate an appropriate Spring configuration for the tests depending on custom(TCK) providers

> The cast is really ugly.

Agreed - but the user won't see it ever. Only us who write the tests will.

> I'd be inclined to at least add a GenericAegisProvider<T> that would
> allow a user to avoid the cast. Adding the property thing we discussed
> before and having the user pass in root classes would allow them to
> get by with Object.class, as well.

Why would a (CXF) user have to pass Object.class ? No CXF user using JAXB passes Object.class,
as far as the users are concerned they do

public Book update(Book)

or similar. I don't see why a CXF user will need to worry about it all...They won't interact
with the providers directly.
Well, the only exception if they start wriring a composite MessageBodyReader and eben in that
case they probably won't need to worry 
about all these casts.

Or am I missing something ? Can you provide an example please if I am ?

Cheers, Sergey

> On Tue, Oct 21, 2008 at 9:55 AM, Sergey Beryozkin
> <> wrote:
>> Hi,
>> First the good news - I heroically :-) fixed the AegisTest by adding a plain
>> old cast when passing AegisTestBean.class and your provider works perfectly
>> well. This is how it works for JAXB too.
>>> 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.
>> I think Jersey does do arbitrary objects too using Object.
>>> @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.
>> @Provider is the annotation on which Jersey relies to scan the classpath for
>> the all available custom providers such that a user does not have to
>> explicitly configure them.
>> We don't do the classpath scanning and to be honest I don't really like this
>> feature anyway - there's just too much magic happening and it's only likely
>> to lead to maintenance/provider clashes issues. And one would probably need
>> to configure which packages can be scanned too - so I don't see any
>> advantage. We may need to start supporting it (scanning classpath for
>> providers) by the time we start working on meeting the TCK requirements
>> though.
>>> 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, ....)
>> Agreed, but it's not good for arbitrary objects...
>>>> 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.
>> Sorry, here're the page
>> [1]
>> Cheers, Sergey
>>>> 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.

View raw message