cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benson Margulies" <bimargul...@gmail.com>
Subject Re: Aegis versus jaxrs
Date Tue, 21 Oct 2008 17:19:32 GMT
OK, here's the problem. I don't know how providers actually get used
in the real code. I guess it's time to clone the systest and see how
it comes out.

On Tue, Oct 21, 2008 at 1:15 PM, Sergey Beryozkin
<sergey.beryozkin@progress.com> wrote:
> 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