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. Perhaps this is a good time to hand over the reigns to you? Thanks, Josh On Thu, Jun 11, 2009 at 3:34 AM, Sergey Beryozkin <sbery...@progress.com>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 : > > http://codereview.appspot.com/71041/patch/3002/3009 > > 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] http://codereview.appspot.com/71041 >> >> On Wed, Jun 10, 2009 at 5:18 AM, David Bosschaert < >> david.bosscha...@gmail.com> 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 or >>> 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 >>> >>> >> >
