Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <004901ca111d$277e68c0$1202050a@emea.progress.com>
From: "Sergey Beryozkin" <sberyozk@progress.com>
To: "Daniel Kulp" <dkulp@apache.org>, <dev@cxf.apache.org>
References: <011701ca103c$2d2852e0$1202050a@emea.progress.com>
 <200907300905.06897.dkulp@apache.org>
Subject: Re: Reusing CXF DataBindings in the JAX-RS implementation
Date: Thu, 30 Jul 2009 14:53:36 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-15";
	reply-type=original
Content-Transfer-Encoding: 7bit

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
> dkulp@apache.org
> http://www.dankulp.com/blog