cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sbery...@progress.com>
Subject Reusing CXF DataBindings in the JAX-RS implementation
Date Wed, 29 Jul 2009 11:03:15 GMT
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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message