cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sbery...@progress.com>
Subject RE: Aegis versus jaxrs
Date Wed, 15 Oct 2008 09:32:57 GMT
Hi,

You may want to check in those methods if the passed in media type
argument is application/xml or at the least it is some form of */xml.
MediaType class has all the getters.
Additionally, in case of JAXB it's checked if the class to be
(un)narshalled has some sort of JAXB annotation, but in case of Aegis
it's not clear what else to check for. MediaType check should be
sufficient...

Cheers, Sergey 

-----Original Message-----
From: Benson Margulies [mailto:bimargulies@gmail.com] 
Sent: 14 October 2008 23:11
To: dev@cxf.apache.org
Subject: Re: Aegis versus jaxrs

I haven't been able to come up with a reason why Aegis would ever say
no to isWriteable or isReadable, but I'll study some more.

On Tue, Oct 14, 2008 at 10:52 AM, Sergey Beryozkin
<sberyozk@progress.com> wrote:
> Hi
>
> Sounds good.
> Have a look, say, at BinaryProvider unit test or at one of the atom
> providers tests, jaxb providers are poorly unit tested at the moment.
> Other providers tests might have some useful test methods too.
>
> The things to unit test is that MessageBodyReader.isReadable and
> MessageBodyWriter.isWriteable can return true/false as expected, and
> they can readFrom/writeTo input streams.
>
> There's also a quite involved JAXBClientServerBookTest. Let me know
> please when you're ready to start writing a system test and we'll
create
> an Aegis version of this test (will be mostly copy/paste), but we'll
> additionally register AegisProvider using Spring so that it can take
> precedence over the default JAXB provider which handles
> application/xml...
>
> Cheers, Sergey
>
> -----Original Message-----
> From: Benson Margulies [mailto:bimargulies@gmail.com]
> Sent: 14 October 2008 12:50
> To: dev@cxf.apache.org
> Subject: Re: Aegis versus jaxrs
>
> I appreciate the cache. However, the minimum number of contexts is the
> number of packages!
>
> A property that takes a context object would, however, solve all of
> this for both Aegis and JAXB, so I'm excited.
>
> Can you tell me how to make a unit test for my Aegis stuff?
>
> On Tue, Oct 14, 2008 at 3:46 AM, Sergey Beryozkin
> <sberyozk@progress.com> wrote:
>> Hi,
>>
>> Same with the JAX-RS JAXB (and JAXB based JSON) provider - contexts
> are
>> cached and can be reused.
>> If ObjectFactory is available then only a single context will be
>> created.
>> At the moment, either a class name or just a package name can serve
as
> a
>> key in the (two) maps of contexts.
>> May be for Aegis it's possible to have another key type to have a
>> context with a scope which wide enough.
>> Sure, you can do bean-ish properties too. I guess an Aegis provider
> will
>> have to be an optional one, otherwise it'll 'clash' with the default
>> JAXB one (both will serve media types like application/xml). Thus it
>> will have to be specified as a bean class in the spring config.
>> Perhaps you can support both options - map of properties and bean-ish
>> properties.
>>
>> Cheers, Sergey
>>
>> -----Original Message-----
>> From: Benson Margulies [mailto:bimargulies@gmail.com]
>> Sent: 14 October 2008 01:00
>> To: dev@cxf.apache.org; Daniel Kulp
>> Subject: Re: Aegis versus jaxrs
>>
>> OK, now we reach the crux of the matter. JAX-RS creates lots of
>> JAXBContexts, where 'normal' CXF manages to share one through an
>> entire service. Am I getting the idea that this is just an
inescapable
>> aspect of the architecture? It could get slow.
>>
>> Aegis is just like JAXB. I could create a set of named properties for
>> the corresponding Aegis options, and add a call like you propose for
>> JAXB. But now we're going to have scads of Aegis objects.
>>
>> In either case, is there any way for the app creator to use Spring
>> configuration to set all this stuff up? And are we really thrilled to
>> have it all as (mistake-prone?) name-value pairs, instead of specific
>> bean-ish properties?
>>
>> I've attempted to drag Dan into this discussion so that he can tell
me
>> to stop worrying.
>>
>>
>> On Mon, Oct 13, 2008 at 9:26 AM, Sergey Beryozkin
>> <sberyozk@progress.com> wrote:
>>> Hi Benson
>>>
>>> Lets add AbstractJAXBProvider.setContextProperties(Map<String,
>> Object>)
>>> and pass those props to the JAXBContext creation calls. If none is
>>> explicitly passed from Spring then a default empty Map can be used
>>> instead. In fact, I just removed that code in my previous merge as I
>>> thought there was no use for it.
>>> About Schema : I presume you ask about the one from
>> javax.xml.validation
>>> ?
>>> I just added it recently to support the optional schema
validation...
>>>
>>> Cheers, Sergey
>>>
>>> -----Original Message-----
>>> From: Benson Margulies [mailto:bimargulies@gmail.com]
>>> Sent: 12 October 2008 12:13
>>> To: dev@cxf.apache.org
>>> Subject: Re: Aegis versus jaxrs
>>>
>>> I think I finally have a sensible question by analogy with JAXB.
>>>
>>> JAXBContext objects have a variety of options and properties. The
>>> JAXBDataBinding allows the CXF app to control these items. The user
>>> can make their own context and inject it into the data binding, or
> the
>>> user can set various properties of ours that our code uses to tune
> the
>>> context.
>>>
>>> If I'm reading the JAX-RS code correctly, AbstractJAXBProvider just
>>> creates a JAXBContext per package or class and uses it. Any app that
>>> wanted to customize it would be required to make their own subclass
> of
>>> AbstractJAXBProvider, or so it seems to me. Am I missing anything?
>>>
>>> Anyway, I'm going to bang something together.
>>>
>>>
>>> On Fri, Oct 10, 2008 at 12:42 PM, Sergey Beryozkin
>>> <sergey.beryozkin@iona.com> wrote:
>>>> Hi
>>>>
>>>>> Sergey,
>>>>>
>>>>> I'm not feeling like I'm doing a very good job of explaining
myself
>>>>> here. It's probably true that the best way for me to proceed is to
>>>>> code something and with some comments that say: 'Sergey, I'm
>>>>> frustrated HERE.' ...
>>>>
>>>> Yea, please do it :-) ! I do hope though that you wouldn't need to
>> get
>>> into
>>>> the details of the actual
>>>> JAX-RS runtime impl, hopefully you'd be able to craft a basic Aegis
>>> support
>>>> inside the 'shell' of the (Aegis)
>>>> JAX-RS MessageBodyReader/Writer implementation...If we could say
>> limit
>>> the
>>>> support to pure Aegis (that is without it also supporting JAXB -
>> which
>>> is
>>>> something CXF Aegis can do as far as I understand) then it would be
>>> super...
>>>>
>>>> Cheers, Sergey
>>>>
>>>>>
>>>>> --benson
>>>>>
>>>>> On Fri, Oct 10, 2008 at 11:44 AM, Sergey Beryozkin
>>>>> <sergey.beryozkin@iona.com> wrote:
>>>>>>
>>>>>> Hi Benson
>>>>>>
>>>>>> I'm sorry If I'm too slow :-) but I'm still not getting what is
it
>>> that
>>>>>> you're proposing.
>>>>>> That said, I believe that may be we should postponse the
> discussion
>>> on
>>>>>> how
>>>>>> to improve the overall
>>>>>> JAX-RS implementation until after it reaches 1.0.
>>>>>>
>>>>>> In meantime, if we had even a basic JAX-RS Aegis provider such
> that
>>>>>> peopple
>>>>>> could start doing Aegis and REST or indeed combining SOAP and
REST
>>> with
>>>>>> the
>>>>>> help of Aegis, then it would be cool IMHO....
>>>>>>
>>>>>> Cheers, Sergey
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I think I'm beginning to get the idea of what I'm trying to
>>> complain
>>>>>>> about.
>>>>>>>
>>>>>>> An AegisDatabinding object has input configuration and it has
>>> state.
>>>>>>> As it goes along, it constructs mappings for types.
>>>>>>>
>>>>>>> I'm having trouble swallowing a situation in which each
> individual
>>>>>>> JAX-RS item does this independently, as opposed to all the of
the
>>>>>>> items in a service sharing a single state. Am I just confused?
>>>>>>
>>>>>> ----------------------------
>>>>>> IONA Technologies PLC (registered in Ireland)
>>>>>> Registered Number: 171387
>>>>>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
>>> Ireland
>>>>>>
>>>>
>>>> ----------------------------
>>>> IONA Technologies PLC (registered in Ireland)
>>>> Registered Number: 171387
>>>> Registered Address: The IONA Building, Shelbourne Road, Dublin 4,
>>> Ireland
>>>>
>>>
>>
>

Mime
View raw message