cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <>
Subject Re: Reusing CXF DataBindings in the JAX-RS implementation
Date Thu, 30 Jul 2009 13:53:36 GMT

> I think what might make sense for a short term "binary compatible" type 
> approach is to add a new interface like "ClassSetDataBinding" or something 
> that defines the init(...) method that is needed for JAXRS.   JAX-RS can then 
> do instanceof on the databinding to see if it WILL work for it.  That way, 
> databindings that aren't designed for it, won't get picked up.   We can update 
> the databindings built into CXF so they do work.
> A thought I had would be to make the new init method be:
> void init(Map<String, Object> properties)
> where we document properties that may be set.   The service model is one, the 
> set of classes another.   

Are you suggesting that with properties like
"org.apache.cxf.databinding.classes" one will be able to do :

Set<Class<?>> allClasses = getAllClasses(model);

ClassSetDataBinding csdb = (ClassSetDataBinding)dataBinding;
csdb.init("org.apache.cxf.databinding.classes", allClasses);

It should definitely work for JAX-RS. I'd probably opt for having 'shortcuts' for most commonly
used properties by having
more explicit methods like init(Set<Class<?>>) & init(Service s) while retaining

void init(Map<String, Object> properties)


csdb.init("org.apache.cxf.databinding.classes", allClasses);

would be equivalent. I'm ok though with having just 

void init(Map<String, Object> properties)

cheers, Sergey

> Other things like extra schema locations, mtom 
> related things, etc...    The ReflectionServiceFactoryBean could be updated to 
> use that method (if the databinding implements the new interface) to pass a 
> map of all the configured endpoint properties.   Thus, configuring some of the 
> jaxb things could be simpler - just define them in jaxws:endpoint.   
> It's also a lot more extensible in the future.
> Thoughts?
> Dan
> On Wed July 29 2009 7:03:15 am Sergey Beryozkin wrote:
>> Hi
>> Until now it's not been possible to reuse existing CXF DataBinding
>> implementations in CXF JAX-RS. For example, the JAX-RS impl provides its
>> own versions of JAXB/Aegis/XMlBeans databindings by implementing JAX-RS
>> MessageBodyProviders.
>> Resolving this issue has been on the map for a while and we've also had a
>> chat with Dan on IRC recently.
>> I've just committed the initial code which makes it possible for users just
>> to reuse the existing CXF DataBindings which is quite promising given that
>> CXF DataBindings are very well stressed and tested. Those users who use
>> JAXWS & JAXRS will likely find it of use, as well as JAX-RS users who might
>> spot some (temp) limitations in the CXF JAXRS message body providers.
>> Here's how I've implemented it at the moment. If users register a
>> databinding bean then what happens is that it will simply be wrapped as a
>> JAXRS MessageBodyReader/Writer and registered as a JAX-RS provider. Its
>> MessageBodyWriter.writeTo and MessageBodyWriter.readFrom delegate to
>> DataBinding DataWriter/DataReader respectively.
>> I think this approach works quite well but there's something I reckon may
>> need to be improved. Particularly, in order to make JAX-RS resource
>> classes' return/input classes for all the resource methods known to
>> DataBinding implementations the JAXRS model classes like ClassResourceInfo
>> & OperationResourceInfo are being temporarily converted into a WSDL-centric
>> Service/ServiceInfo/MessageInfp/etc model so that
>> DataBinding.initialize(Service s) can be called.
>> This in itself might become useful later on if we were to decide on
>> supporting say WSDL2 but for the purpose of reusing the DataBindings it
>> does not necessarily represents the best approach. It can get tricky for
>> JAX-RS resources be represented well as WSDL-centric ones to meet different
>> expectations of different bindings, something I found during the initial
>> work. JAXRS resource methods might have parameters representing say
>> queries, alongside with request bodies, etc.
>> Perhaps the better option is for every DataBinding implementation is to
>> have a method like
>> setAllClasses(Set<Class<?>> classes)
>> or
>> setTypeInfo(Map<Class<?>, Type> info)
>> which would represent an alternative option for initializing a databinding.
>> Every CXF DataBinding would have to be updated slightly to use those
>> classes instead of Service to gety initialized.
>> JAXRS will create a required set/map and reflectively call such a method.
>> This method might even make it into DataBinding interface if it's assumed
>> that no users are directly interacting with DataBinding interfaces.
>> Thoughts ?
>> thanks, Sergey
> -- 
> Daniel Kulp

View raw message