Hi, 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, 'org.apache.cxf.ws' is equivalent to old 'pojo' soap-based services, while 'org.apache.cxf.rs' identifies a handler capable of exposing pojos as RESTful services. Now, frontends and databindings for SOAP services can be selected by the following properties : 'org.apache.cxf.ws.frontend' & 'org.apache.cxf.ws.databinding'. For JAX-RS (org.apache.cxf.rs) services there's no need to configure frontends though databindings can be configured too. Address & servlet context properties have also changed, with either org.apache.cxf.ws/rs 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), etc. 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 build. 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 course. 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: 'dev@cxf.apache.org' 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: jmholtz...@gmail.com [mailto:jmholtz...@gmail.com] On Behalf Of Josh Holtzman Sent: 12 June 2009 14:20 To: dev@cxf.apache.org Subject: Re: Integrating JAX-RS runtime into DOSGi I've attached the jaxws/jaxrs/databinding patch to https://issues.apache.org/jira/browse/CXF-2252 Thanks, Josh On Fri, Jun 12, 2009 at 3:19 AM, Sergey Beryozkin <sbery...@progress.com>wrote: > 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 in > his code review page, but I'd rather him collecting another major patch > point than me just copying his code. > > Cheers, Sergey > > -----Original Message----- > From: Eoghan Glynn [mailto:eogl...@gmail.com] > Sent: 12 June 2009 09:58 > To: dev@cxf.apache.org > Subject: Re: Integrating JAX-RS runtime into DOSGi > > 2009/6/12 David Bosschaert <david.bosscha...@gmail.com>: > > > > 2009/6/11 Sergey Beryozkin <sbery...@progress.com>: > > ... > >> 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 intents > > 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 >
