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 Sat, 20 Jun 2009 18:10:59 GMT

I've applied your patch and I've completed the initial integration of
JAX-RS into DOSGi RI. As it often happens I underestimated a bit how
long it would take me to do it :-) but I'm quite happy now with what has
been done so far.  

I haven't got a chance to write JAX-WS system tests yet - I was a bit
constrained in time but judging from the code you did JAXWS/databindings
should be working nicely now - please feel free to add a system test, or
either of us will do it asap.

Now, the property names have actually changed and differ from those you
provided in the patch. As David noted, it was recommended that DOSGI
providers would use reverse domain names as prefixes to their custom
configuration types, such as 'pojo' in case of DOSGI RI. Furthermore,
'pojo' was a bit constraining in that it did not reflect the fact that
say SOAP or RS services were supported. Additionally, the DOSGI way is
to associate additional properties qualifying a given config type with
the config type property, for ex, if it's 'pojo' then it really should
be 'pojo.frontend', etc.

What David changed on the trunk was that he introduced new properties,
while still maintaining the old ones for now. So, '' is
equivalent to old 'pojo' soap-based services, while ''
identifies a handler capable of exposing pojos as RESTful services.

Now, frontends and databindings for SOAP services can be selected by the
following properties : '' &
''. For JAX-RS ( services
there's no need to configure frontends though databindings can be
configured too.

Address & servlet context properties have also changed, with either replacing 'pojo'. Please check the DOSGi docs -
David will also provide more feedback.

It may be that global databinding and some other properties can still be
introduced for them be shared between soap & jaxrs services. Lets
discuss it more and see what can be done.

David has also updated the trunk so that multiple config types can be
applied to a given service registration. There's a minor update still
needs to be done (something like AggregatePojoConfigurationHandler needs
to be added) but it's really nearly there. So for now please register
your bean twice to make them work with JAXWS & JAXRS, but it will be
fixed soon. I think the new properties will also let us do pretty
advanced combinations (like jaxb for soap but atom and aegis for jaxrs),

There's something else David is thinking of doing shortly, possibly next
week or so. At the moment one has to configure DOSGI properties on the
individual service basis, either from the code or from the xml. David is
thinking of introducing wildcards such that for ex a given set of
(dosgi) properties can apply to a potentially unlimited number of
services - that will scale in terms of configuration dramatically. David
is traveling but he will clarify as soon as he can.

For now I did not add the support for a jaxrs.resource property Aaron
and yourself talked about - this would be a non-standard property anyway
and may be you can live for now with using the DOSGI props. You'll be
abale to move all the dosgi properties away from your Activators once
David finishes his work on supporting wildcards.  

Now, as far as the JAX-RS integration is concerned. It works both ways,
on the client and on the server. Have a look please at
samples/greeter_rest, it's basically identical to greeter demo, except
that its GreeterService has JAX-RS annotations and it also introduces
GreeterService2 interface which has no JAX-RS annotations but will be
supported by the JAX-RS runtime, a model file in OSGI-INF/cxf/jaxrs
resource folder in the greeter-rest/interface bundle enables it. Note
that in this case the model enables the interface only so all the
implementation objects will be supported as the result. The
GreeterService2Impl registration code in the greeter-rest/impl Activator
is commented at the moment as the cxf 2.2.3-SNAPSHOT needs another

The only issue I haven't solved yet is that the restful client proxies
are created only in case of single-distribution, I could not figure out
why it was not working in case of the multibundle one. Will fix in due

So that is it for now - please try the latest trunk (though I'll ping
you once I can confirm the 2.2.3-SNAPSHOT has been built or please build
it locally). Please let us know what you think - comments/objections/etc
and we'll to sort out all the issues.

I'm going to prioritize now on the mainline jaxrs work around supporting
the metadata plus some various urgent enhancements but will be able to
reply to all your dosgi jaxrs related queries

Cheers, Sergey  


-----Original Message-----
From: Sergey Beryozkin 
Sent: 12 June 2009 14:43
To: ''
Subject: RE: Integrating JAX-RS runtime into DOSGi

Fantastic, thanks a million. I might not be able to apply it today as
I'd like to finish some initial WADL work but I will start working with
it on Monday 

Cheers, Sergey

-----Original Message-----
From: [] On Behalf Of
Josh Holtzman
Sent: 12 June 2009 14:20
Subject: Re: Integrating JAX-RS runtime into DOSGi

I've attached the jaxws/jaxrs/databinding patch to


On Fri, Jun 12, 2009 at 3:19 AM, Sergey Beryozkin

> Hi,
> I agree, putting the jaxrs-specific resources into OSGI-INF/cxf/jaxrs
> makes sense.
> I'll wait for Josh to submit his patch and then I'll add a simple demo
> and also tests if needed. Josh has already kindly shown all the code
> his code review page, but I'd rather him collecting another major
> point than me just copying his code.
> Cheers, Sergey
> -----Original Message-----
> From: Eoghan Glynn []
> Sent: 12 June 2009 09:58
> To:
> Subject: Re: Integrating JAX-RS runtime into DOSGi
> 2009/6/12 David Bosschaert <>:
> >
> > 2009/6/11 Sergey Beryozkin <>:
> > ...
> >> The only question I have is where this model info should reside, in
> >> META-INF/cxf-dosgi ? I'll check with Favid/Eoghan
> >
> > We already use OSGI-INF/cxf/intents for our CXF-DOSGi specific
> > files, so maybe somewhere in the OSGI-INF/cxf area?
> >
> Yeah, makes sense to gather all the CXF-specific elements under
> OSGI-INF/cxf.
> Maybe scope it further with OSGI-INF/cxf/jaxrs/resources or somesuch.
> Cheers,
> Eoghan

View raw message