Oh I see, so these properties are on per-service basis. Then my proposal can be ignored.
Thanks, Sergey > I haven't seen a ClientProxyFactoryBean equivalent that uses JAX-RS in > the way that JaxWsProxyFactoryBean creates client proxies for JAX-WS. > Is that what you're working on? It's all done, as far as proxy generation is concerned, it works pretty much the same way as with simple frontend/jaxws. Some information is here : http://cwiki.apache.org/CXF20DOC/jax-rs.html#JAX-RS-ClientAPI I will start a separate thread. Thanks, Sergey -----Original Message----- From: Josh Holtzman [mailto:[email protected]] Sent: 05 June 2009 22:23 To: [email protected] Subject: Re: Configuring DOSGI to use JAX-WS Yes, sorry about that. I missed Dan's reply as I was typing my own. The patch that I'm working on inspects each service reference for these properties, so each service can choose its own databinding and frontend. Josh Sergey Beryozkin wrote: > Hi > > Please see my last reply to Dan. > > If multiple frontends are involved in a given OSGI container instance > then it might be not possible. As I said, I'm supporting the proposed > two properties but suggesting a possibility for a databinding one be > overridden on a per-frontend basis. That said I'm ok with not > considering this option until it's actually required - I reckon it will > be relatively simple to fix when needed. > > > Cheers, Sergey > > -----Original Message----- > From: Josh Holtzman [mailto:[email protected]] > Sent: 05 June 2009 22:04 > To: [email protected] > Subject: Re: Configuring DOSGI to use JAX-WS > > I think this can all be handled with just two properties: > > org.apache.cxf.dosgi.databinding=[ jaxb | xmlbeans | aegis (default) ] > org.apache.cxf.dosgi.frontend=[ jaxws | jaxrs | simple (default) ] > > This way, you can just mix and match. Does that meet your needs? > > I haven't seen a ClientProxyFactoryBean equivalent that uses JAX-RS in > the way that JaxWsProxyFactoryBean creates client proxies for JAX-WS. > Is that what you're working on? > > Josh > > Sergey Beryozkin wrote: > >> Hi, >> >> I'm planning to integrate JAX-RS runtime into a DOSGi as well. >> >> One can consider that >> >> org.apache.cxf.dosgi.frontend.simple >> >> is a default property. >> >> org.apache.cxf.dosgi.frontend.jaxws >> >> would cause a jaxws frontend be used. >> >> Perhaps >> >> org.apache.cxf.dosgi.frontend.jaxrs >> >> can indicate that JAX-RS should be used. >> >> Now both jaxws and jaxrs can use JAXB, and as Dan said even simple >> frontend can use JAXB. And all of them can use Aegis >> >> So as far as databinding is concerned, should it be rather >> >> org.apache.cxf.dosgi.frontend.jaxws.databinding.jaxb >> org.apache.cxf.dosgi.frontend.jaxws.databinding.xmlbeans >> >> org.apache.cxf.dosgi.frontend.simple.databinding.jaxb >> org.apache.cxf.dosgi.frontend.simple.databinding.aegis (default) >> >> org.apache.cxf.dosgi.frontend.jaxrs.databinding.jaxb >> org.apache.cxf.dosgi.frontend.jaxrs.databinding.aegis >> >> etc >> >> so that a databinding can be applied selectively, on a per-frontend >> basis ? >> >> May be properties like org.apache.cxf.dosgi.databinding.jaxb can serve >> as a global property which has to apply to all frontends, that is if >> > is > >> is set then even a simple frontend should use JAXB, but a property >> > like > >> >> org.apache.cxf.dosgi.frontend.simple.databinding.aegis >> >> can be used to override it >> >> cheers, Sergey >> >> >> -----Original Message----- >> From: Josh Holtzman [mailto:[email protected]] >> Sent: 05 June 2009 21:30 >> To: [email protected] >> Subject: Re: Configuring DOSGI to use JAX-WS >> >> I'm the confused one :) I was conflating the two. Daniel Kulp >> > pointed > >> this out in the Jira ticket, and I've changed the patch so it now >> watches for two properties: org.apache.cxf.dosgi.databinding.jaxb and >> org.apache.cxf.dosgi.frontend.jaxws. If the first is true, the jaxb >> databinding is used instead of aegis. If the second property is true, >> > > >> the jaxws frontend is used rather than the simple frontend. >> >> Josh >> >> Benson Margulies wrote: >> >> >>> I'm confused. Generally, it's Aegis versus JAX-B and Simple versus >>> JAX-WS. Are you really replacing Simple with JAX-WS, or are you >>> replacing both? >>> >>> On Fri, Jun 5, 2009 at 2:13 PM, Josh Holtzman >>> > <[email protected]> > >>> >>> >> wrote: >> >> >>> >>> >>> >>>> I'm finally coming back to looking at this issue. I've added a Jira >>>> >>>> >> and a >> >> >>>> patch at https://issues.apache.org/jira/browse/CXF-2252 >>>> >>>> Let me know if there's anything I can do to clean up the patch. >>>> >>>> >> Since the >> >> >>>> current Aegis databinding remains the default, I'm hoping that this >>>> >>>> >> patch >> >> >>>> can be merged without causing any problems. >>>> >>>> Thanks, >>>> Josh >>>> >>>> Josh Holtzman wrote: >>>> >>>> >>>> >>>>> Right. In the SOA world, the WSDL is the service contract. In the >>>>> >>>>> >> Java >> >> >>>>> world, the interface is the service contract. I therefore see no >>>>> >>>>> >> problem >> >> >>>>> using JAX-WS annotations on the Java interfaces, since they >>>>> > describe > >>>>> >>>>> >> how to >> >> >>>>> translate between Java and WSDL. >>>>> >>>>> Thanks, >>>>> Josh >>>>> >>>>> Eoghan Glynn wrote: >>>>> >>>>> >>>>> >>>>>> Sorry Josh, I didn't notice your response before replying to >>>>>> >>>>>> >> Sergey. >> >> >>>>>> So in your case, it wouldn't actually be an issue that the JAX-WS >>>>>> annotations were present on the OSGi service class? >>>>>> >>>>>> Cheers, >>>>>> Eoghan >>>>>> >>>>>> 2009/5/12 Josh Holtzman <[email protected]>: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Hi Eoghan, >>>>>>> Yes, it would most likely require JAX-WS annotations on the >>>>>>> >>>>>>> >> service >> >> >>>>>>> interfaces rather than the impl classes, but IMHO it doesn't >>>>>>> > break > >>>>>>> >>>>>>> >> the >> >> >>>>>>> OSGI >>>>>>> service model. Perhaps I should explain my use case. >>>>>>> >>>>>>> We are building an open source system that must be able to >>>>>>> > operate > >>>>>>> >>>>>>> >> in >> >> >>>>>>> both a >>>>>>> co-located (one JVM) and distributed topology. For the >>>>>>> > co-located > >>>>>>> flavor, >>>>>>> we don't want to incur the overhead of web service >>>>>>> >>>>>>> >> serialization... we >> >> >>>>>>> want >>>>>>> direct access to the java services as they were published to the >>>>>>> >>>>>>> >> OSGI >> >> >>>>>>> service registry. For the distributed topology, we want to allow >>>>>>> adopting >>>>>>> institutions to swap out individual services for their own >>>>>>> implementations >>>>>>> in other languages. And finally, we want our service clients to >>>>>>> >>>>>>> >> be >> >> >>>>>>> ignorant >>>>>>> of the current topology. Service developers should enable their >>>>>>> services to >>>>>>> be available remotely (by publishing with the osgi.remote >>>>>>> > property > >>>>>>> >>>>>>> >> and >> >> >>>>>>> using >>>>>>> JAX-WS annotations), but should not necessarily expect the >>>>>>> >>>>>>> >> services to >> >> >>>>>>> be >>>>>>> remote. >>>>>>> >>>>>>> Providing a JAX-WS configuration option shouldn't impact folks >>>>>>> >>>>>>> >> wanting >> >> >>>>>>> to >>>>>>> stick with aegis/simple. But it does allow projects that want >>>>>>> > all > >>>>>>> >>>>>>> >> of >> >> >>>>>>> the >>>>>>> benefits of DOSGI to make their web service contracts usable >>>>>>> >>>>>>> >> outside of >> >> >>>>>>> the >>>>>>> CXF world. >>>>>>> >>>>>>> Thanks, >>>>>>> Josh >>>>>>> >>>>>>> >>>>>>> Eoghan Glynn wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi Josh, >>>>>>>> >>>>>>>> I'm not entirely sold on the desirability of using JAX-WS with >>>>>>>> >>>>>>>> >> dOSGi. >> >> >>>>>>>> Wouldn't this require that the original OSGi service class was >>>>>>>> annotated with @WebService, @WebMethod etc? >>>>>>>> >>>>>>>> And wouldn't this defeat the whole purpose of dOSGi in a sense? >>>>>>>> >>>>>>>> >> i.e. >> >> >>>>>>>> if the remotability isn't enabled transparently on a largely >>>>>>>> >>>>>>>> >> unchanged >> >> >>>>>>>> OSGi application, why not just write a straight JAX-WS >>>>>>>> >>>>>>>> >> server-side >> >> >>>>>>>> application from the get-go? >>>>>>>> >>>>>>>> Sorry if I'm slightly missing the point here. I just wanted to >>>>>>>> >>>>>>>> >> think >> >> >>>>>>>> through the implications of using a databinding/frontend that's >>>>>>>> >>>>>>>> >> more >> >> >>>>>>>> intrusive than Aegis/simple. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Eoghan >>>>>>>> >>>>>>>> 2009/5/11 Josh Holtzman <[email protected]>: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> I just read David Bosschaert's blog entry [1] addressing >>>>>>>>> >>>>>>>>> >> questions >> >> >>>>>>>>> about >>>>>>>>> his >>>>>>>>> RFC 119 webinar. One of his answers sparked another question, >>>>>>>>> >>>>>>>>> >> and >> >> >>>>>>>>> rather >>>>>>>>> than contact him directly, I decided to give the wider CXF >>>>>>>>> >>>>>>>>> >> community a >> >> >>>>>>>>> crack >>>>>>>>> at it. >>>>>>>>> >>>>>>>>> I'd like to have the option to specify which databinding >>>>>>>>> >>>>>>>>> >> strategy to >> >> >>>>>>>>> use >>>>>>>>> with DOSGI. Currently, the Aegis databinding is "hard wired". >>>>>>>>> >>>>>>>>> >> I >> >> >>>>>>>>> recognize >>>>>>>>> that this makes sense for most use cases, since it relieves the >>>>>>>>> developer >>>>>>>>> from any wsdl or xsd responsibilities. But it doesn't make >>>>>>>>> >>>>>>>>> >> sense for >> >> >>>>>>>>> cross-platform use cases (which, interestingly, David mentions >>>>>>>>> >>>>>>>>> >> right >> >> >>>>>>>>> after >>>>>>>>> the question "Why don't you use JaxWS?"). >>>>>>>>> >>>>>>>>> The default wsdls produced by the Aegis databinding are not >>>>>>>>> >>>>>>>>> >> easily >> >> >>>>>>>>> usable >>>>>>>>> cross-platform. I wouldn't want to provide a developer with a >>>>>>>>> >>>>>>>>> >> wsdl >> >> >>>>>>>>> that >>>>>>>>> specifies arg0, arg1, and arg2 as argument names, for example. >>>>>>>>> >>>>>>>>> Is there interest in allowing the databinding strategy to be >>>>>>>>> configurable >>>>>>>>> in >>>>>>>>> the DOSGI reference implementation? If so, I'd be happy to >>>>>>>>> > work > >>>>>>>>> >>>>>>>>> >> on a >> >> >>>>>>>>> patch. >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > http://coderthoughts.blogspot.com/2009/05/questions-from-rfc-119-webinar > >> .html >> >> >>>>>>>>> Thanks, >>>>>>>>> Josh >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Josh Holtzman >>>>>>>>> Educational Technology Services, UC Berkeley >>>>>>>>> [email protected] >>>>>>>>> 510.529.9225 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> -- >>>>>>> Josh Holtzman >>>>>>> Educational Technology Services, UC Berkeley >>>>>>> [email protected] >>>>>>> 510.529.9225 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> -- >>>> Josh Holtzman >>>> Educational Technology Services, UC Berkeley >>>> [email protected] >>>> 510.529.9225 >>>> >>>> >>>> >>>> >>>> >> >> > > -- Josh Holtzman Educational Technology Services, UC Berkeley [email protected] 510.529.9225
