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:26:34 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.

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