You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Sergey Beryozkin <sb...@progress.com> on 2009/07/29 13:03:15 UTC
Reusing CXF DataBindings in the JAX-RS implementation
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
Re: Reusing CXF DataBindings in the JAX-RS implementation
Posted by Sergey Beryozkin <sb...@progress.com>.
> I'd prefer not to have a bunch of different init(..) methods on the interface
> itself that everyone HAS to implement.
Ok, given this argument, I'm happy with having a single
void initialize(Map<String, Object> properties)
I guess I could've argued that perhaps only DataBindings shipped with CXF would implement such an interface thus they'd be capable
of handling specific typed methods while they'd also likely have to react somehow when seeing unsupported properties - but I reckon
we'd then need to answer the question like how many such utility methods this interface should have...So yeah, lets go for a single
loose initialize() method - it should work well,
thanks, Sergey
>
> Basically, I think we should have:
>
> interface PropertiesInitializedDataBinding extends Databinding {
> void initialize(Map<String, Object> properties);
> }
>
> Then, we make our AbstractDataBinding implement that interface and add a
> method like:
>
> void initialize(Map<String, Object> properties) {
> Service svc = properties.get("...Service");
> if (svc != null) {
> initialize(svc);
> }
> }
>
> or similar. Other helper things (like the init(Set)) can be added to
> AbstractDataBinding or similar and called from there.
>
> Eventually (CXF 3.0), the initialize method above would get put in DataBinding
> and the original one removed so only one initialize method would need to be
> implemented.
>
> I'd prefer not to have a bunch of different init(..) methods on the interface
> itself that everyone HAS to implement.
>
> Dan
>
>
>
>
>
> On Thu July 30 2009 9:53:36 am Sergey Beryozkin wrote:
>> 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
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
Re: Reusing CXF DataBindings in the JAX-RS implementation
Posted by Sergey Beryozkin <se...@iona.com>.
Will providing a set of classes be sufficient, when initializing a
DataBinding from JAX-RS ?
Should it be a map instead, for Type(s) from
Method.getGenericResponseType()
Method.getGenericResponseTypes()[index]
also be available ?
thanks, Sergey
dkulp wrote:
>
>
> Basically, I think we should have:
>
> interface PropertiesInitializedDataBinding extends Databinding {
> void initialize(Map<String, Object> properties);
> }
>
> Then, we make our AbstractDataBinding implement that interface and add a
> method like:
>
> void initialize(Map<String, Object> properties) {
> Service svc = properties.get("...Service");
> if (svc != null) {
> initialize(svc);
> }
> }
>
> or similar. Other helper things (like the init(Set)) can be added to
> AbstractDataBinding or similar and called from there.
>
> Eventually (CXF 3.0), the initialize method above would get put in
> DataBinding
> and the original one removed so only one initialize method would need to
> be
> implemented.
>
> I'd prefer not to have a bunch of different init(..) methods on the
> interface
> itself that everyone HAS to implement.
>
> Dan
>
>
>
>
>
> On Thu July 30 2009 9:53:36 am Sergey Beryozkin wrote:
>> 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
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
--
View this message in context: http://www.nabble.com/Reusing-CXF-DataBindings-in-the-JAX-RS-implementation-tp24716988p24917972.html
Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Reusing CXF DataBindings in the JAX-RS implementation
Posted by Daniel Kulp <dk...@apache.org>.
Basically, I think we should have:
interface PropertiesInitializedDataBinding extends Databinding {
void initialize(Map<String, Object> properties);
}
Then, we make our AbstractDataBinding implement that interface and add a
method like:
void initialize(Map<String, Object> properties) {
Service svc = properties.get("...Service");
if (svc != null) {
initialize(svc);
}
}
or similar. Other helper things (like the init(Set)) can be added to
AbstractDataBinding or similar and called from there.
Eventually (CXF 3.0), the initialize method above would get put in DataBinding
and the original one removed so only one initialize method would need to be
implemented.
I'd prefer not to have a bunch of different init(..) methods on the interface
itself that everyone HAS to implement.
Dan
On Thu July 30 2009 9:53:36 am Sergey Beryozkin wrote:
> 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
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Reusing CXF DataBindings in the JAX-RS implementation
Posted by Sergey Beryozkin <sb...@progress.com>.
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
Re: Reusing CXF DataBindings in the JAX-RS implementation
Posted by Daniel Kulp <dk...@apache.org>.
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. 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