cxf-dev mailing list archives

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


> 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
> <sergey.beryozkin@progress.com> 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 <bimargulies@gmail.com>
>>> 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] https://jsr311.dev.java.net/
>>
>> 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.
>>>>
>>
>> 


Mime
View raw message