cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <>
Subject Re: Integrating JAX-RS runtime into DOSGi
Date Thu, 11 Jun 2009 16:11:32 GMT
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 :
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 <>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 :
>> 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]
>>> On Wed, Jun 10, 2009 at 5:18 AM, David Bosschaert <
>>>> 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
>>>> 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

View raw message