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
>>>
>>>
>>
>

Reply via email to