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, 14 Oct 2008 22:10:34 GMT
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