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:33:07 GMT
The question lurking here is the official API of the
MessageBodyReader.  How does the interceptor choose the right class to
pass to it?

On Tue, Oct 21, 2008 at 1:26 PM, Sergey Beryozkin
<sergey.beryozkin@progress.com> wrote:
>
>
>> 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.
>
> You won't see then in the actual system tests. Actually, there're custom
> providers there, but they're registered from Spring and that's the end of
> the story. The runtime will pick them up and 'prefer' them to the default
> ones (though it will try to use the default ones if custom ones can't
> satisfy a given request). Or they can be registered from code, but that is
> it.
>
> JAXRSInInterceptor will interact with ProviderFactory to find the right
> MessageBodyReader and JAXRSInInterceptor will check for MessageBodyWriters.
> There's a quite a lot of generics unfriendly code in ProviderFactory - but I
> was so in a hurry at a time I honestly didn't have time to clean that code
> well - it's one of the objectives on the JAX-RS docs page though :-)
>
> Cheers, Sergey
>
>
>>
>> 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