cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sbery...@progress.com>
Subject Re: Integrating JAX-RS runtime into DOSGi
Date Thu, 25 Jun 2009 10:55:03 GMT
Hi Josh

> Sergey,
> Thanks again for the detailed documentation you've provided in this thread.
> I was able to easily convert from JAX-WS to JAX-RS, which (I think) will
> make our lives even easier.  Once we've got the ability to expose a single
> service with both of these frontends, I'll make use of that as well.

Thanks for experimenting with this initial effort. We'll add the ability to combine frontends
soon, I was nearly ready to do it but
I was not sure at a time how consuming bundles would indicate their preferences - perhaps
should be some sort of intersection 
happening there. Likewise, it is not clear what to do when one of the frontends fails to start
- is it a total failure or just a 
warning (plus removing a given failing frontend from the property to be published...) So we
need to think what to do in such cases 
and then add the actual support.

> I agree that the jaxrs.resource property is no longer needed, as you can
> simply register jaxrs resources as a dosgi services.

OK. 'jaxrs.resource' still appeals to me a bit so if we can see the opportunity for providing
a portable JAX-RS publication feature 
not strictly bound to DOSGi then I'll be happy to add the support for it (while still using
DOSGi under the hood)...

thanks, Sergey

>
> Josh
>
> On Sat, Jun 20, 2009 at 11:10 AM, Sergey Beryozkin <sberyozk@progress.com>wrote:
>
>> 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: jmholtzman@gmail.com [mailto:jmholtzman@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
>> <sberyozk@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:eoglynn@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.bosschaert@gmail.com>:
>> > >
>> > > 2009/6/11 Sergey Beryozkin <sberyozk@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
>> >
>>
> 


Mime
View raw message