Hi
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)
so
csdb.init("org.apache.cxf.databinding.classes", allClasses);
&
csdb.init(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
dk...@apache.org
http://www.dankulp.com/blog
