Hi Josh
Great, I'm glad this is helpful. And thanks for explaining the redundancy
regarding databindings... that makes sense.
I'd seen your comments about "model info" earlier in this or a related
thread, but I don't know what "model info" is.
It is just the alternative way to tell the JAX-RS runtime how a given service
class has to be exposed as a RESTful service.
I only blogged about it :
http://sberyozkin.blogspot.com/2009/05/annotation-free-services-with-cxf-jax.html
but I will document it and will also enhance it as well. In the scope of DOSGi it can make quite a bit of sense for some
deployments, otherwise the client application bundles will need to be explicitly aware of say JAX-RS annotations which will kind of
'leak' the DSW's internal details into a client bundle, though may be it's not a big deal if such imports are made optional.
The only question I have is where this model info should reside, in
META-INF/cxf-dosgi ? I'll check with Favid/Eoghan
Perhaps this is a good time to hand over the reigns to you?
Can you please create a new patch with the changes you did to the factory and the newly introduced JaxRs handler ? Or may be just
update your original pathc to do with the JAXWS support ? I will apply it and proceed from there - will just add some simple demo...
thanks, Sergey
Thanks,
Josh
On Thu, Jun 11, 2009 at 3:34 AM, Sergey Beryozkin <sbery...@progress.com>wrote:
Hi Josh
This is super, thanks for starting the actual integration project.
> I'm not sure how the cxf-rt-frontend-jaxrs dependency should be handled.
It is embedded inside cxf-minimal-bundle (2,3-SNAPSHOT) so there's no need
to update single or multi bundle distributions.
Yesterday I updated them so that a jaxrs1.0-api specs bundle is pulled in
so everything should be set in this regard.
I think this code :
http://codereview.appspot.com/71041/patch/3002/3009
should work as is really, thanks.
A couple of comments :
Server :
The only code which may need to be update is the one which checks a
DataBinding. At the moment it can be considered as redundant as
the JAX-RS frontend does not allow yet for plugging in yet CXF
DataBindings. Instead, it relies on JAX-RS MessageBodyProviders which are
essentially can be seen as data bindings too.
JAX-RS mandates that JAXB is supported out of the box thus, in our case, we
don't need to do anything if a "jaxb" property is set, we only need to add
an Aegis provider (which actually depends on Aegis databinding) if no jaxb
is set, you can register an AegisProvider like this :
bean.setProviders(Collections.singletonList(new AegisProvider()));
Client.
If needed, you can also work with JAXRSCleintFactoryBean.
JAXRSClientFactory just delegates to it through its utility methods.
One of these methods also accepts a list of providers, so if no jaxb is set
then that method needs to be used to register an Aegis provider
So I think it's nearly there. I'd also consider checking if some model info
is available and use it if yes, such that client application bundles won't
have to import jaxrs* packages if it is something they don't want to do...
But it can be done later on
thanks for your help, Sergey
I'm not sure how the cxf-rt-frontend-jaxrs dependency should be handled.
The work I've done so far [1] will tie the DSW software to the JAX-RS
implementation. Since cxf-rt-frontend-jaxrs isn't an osgi bundle, I'd
have
to embed the jar within DSW to satisfy the dependency. This doesn't seem
like a good idea to me. Any suggestions?
Thanks,
Josh
[1] http://codereview.appspot.com/71041
On Wed, Jun 10, 2009 at 5:18 AM, David Bosschaert <
david.bosscha...@gmail.com> wrote:
> I've just updated a cxf-minimal bundle to include a jaxrs frontend and
I
> updated the cxf.version in dosgi/parent to 2.3.0-SNAPHOT
>
> (David, Eoghan - we can downgrade it easily to 2.2.2 fixes tag if DOSGi
will
> need to be released sooner than 2.3 does which is in about 3 months or
so
I
> believe, with fixes branch likely be easiler tp release earlier).
Yeah - going to 2.2.2.fixes might be good. I expect that a DOSGi
release will be done earlier than in 3 months, especially since the
property names that are used will change in the real OSGi spec, which
is currently being finalized.
I am planning to update the properties in the DOSGi implementation to
reflect the latest in the spec draft either later this week or early
next week.
BTW we now also have Discovery in CXF/DOSGi, so it would be nice to
include that in a release fairly soon too.
Thanks,
David
