cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <>
Subject RE: Aegis versus jaxrs
Date Tue, 14 Oct 2008 07:46:07 GMT

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
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

Cheers, Sergey   

-----Original Message-----
From: Benson Margulies [] 
Sent: 14 October 2008 01:00
To:; 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
<> wrote:
> Hi Benson
> Lets add AbstractJAXBProvider.setContextProperties(Map<String,
> 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
> ?
> I just added it recently to support the optional schema validation...
> Cheers, Sergey
> -----Original Message-----
> From: Benson Margulies []
> Sent: 12 October 2008 12:13
> To:
> 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
> <> 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
> 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
> the
>> support to pure Aegis (that is without it also supporting JAXB -
> 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
>>> <> 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

View raw message