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 Fri, 01 Aug 2008 14:19:23 GMT

> When a CXF service offers JAX-RS, some CXF-specific configuration is
> involved, no? So, could we not have some properties at the service level
> which the ProviderFactory consumes-if-provided? Aegis in particular has a
> set of configuration options, it would be very cumbersome to force those to
> be configured per-MessageBodyProvider.

if you look at the JSONElementProvider, you can see it has setProperties(), and this provider
instance can pick all the required properties when it's configured using Spring.

Aegis configuration properties would be specific to an Aegis provider only so I'm not sure
what your concern

> My proposal is that the JAXRSServerFactoryBean could be given DataBinding
> objects, and the ProviderFactory would use them. If there aren't any, it
> would do what it does now.

I'm sorry, I'm not following :-).
For, here's a typical method a JAX-RS can handle :
Customer doIt(@QueryParam("bar") String bar, Customer customer);

I don't understand how your proposal would make it easier to handle the conversion of the
InputStream into an instance of Customer. 
Please explain. In other words why can't an AegisProvider reuse the code from the DataBinding
directly ?
ProviderFactory's job is to create providers based on the asked media types and classes

> On a more detailed note, how would you propose that the ProviderFactory
> arbitrate between using JAXB and Aegis? They support the same annotations on
> the code. Isn't this another reason to have a Server Factory configuration,
> to specify which data binding to use by default? Or is some other mechanism
> at work here that I haven't comprehended?

ProviderFactory does not need to arbitrate in this case it's this the JAX-RS runtime itself
which will do it indirectly.
Suppose we have a Customer which either a JAXBProvider or AegisProvider can handle. Explictly
configuring AegisProvider as one of 
the providers to be used in the spring config for jaxrs:server would ensure that it'll be
given a chance to serialize/deserialize 
before a JAXBProvider will be asked to do the same....

Thanks for starting to look into it anyway, I'm sure we'll a have a cool JAX-RS AegisProvider
eventually :-)

Cheers, Sergey

P.S. I'll be on holidays for the most part of August, so I won't be able to contribute to
this thread during the next month

> On Thu, Jul 31, 2008 at 10:23 AM, Sergey Beryozkin <
>> wrote:
>> Hi
>>  If I'm reading the JAX-RS code correctly, which I'm probably not, it
>>> doesn't
>>> use the JAXB DataBinding object. It interacts class-by-class with JAXB.
>> At the moment yes, and this is a reson I excluded a jaxb-databinding
>> module, just to minimize the size of the cxf-jaxrs bundle. I think jaxb api
>> is picked up recursively from some other module, I actually didn't check
>> from which one.
>>> I think I can do likewise for Aegis, sort of, but it could get ugly.
>> If you'd like to do an Aegis Provider and a jaxb binding module would help
>> you then please do include it in the pom again.
>>  Does
>>> JAX-RS give us no ability to configure a data binding at the level of the
>>> entire service?
>> In JAX-RS, it's individual MessageBodyProviders which are responsible for
>> (un)marshalling. So probably, not...
>> Perhaps the default JAXBProvider can be updated to reuse some of the code
>> from a jaxb binding, not sure
>> Cheers, Sergey
>> ----------------------------
>> 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