cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <>
Subject Re: CXF-DOSGi passing the OSGi Remote Services and Remote Service Admin CT
Date Wed, 02 Jun 2010 21:17:51 GMT
Hi Sergey,

Some comments below...

On 13 May 2010 12:42, Sergey Beryozkin <> wrote:
>> So now that we have a passing RI I think it would make sense to start
>> planning a CXF-DOSGi release. I'm wondering what we should do before
>> that...
>> 1. There are some SEVERE 'warnings' coming up, I believe from the
>> Topology Manager. We should probably take a look at those.
>> 2. I once added some Discovery system tests, which I ended up not
>> enabling because of memory issues. I might want to try and get them
>> working on all platforms.
>> 3. Anything else?
> - consolidation of DOSGI RI specific properties. Example, you added a useful
> property called "" so JAXRS endpoints need to 'catch
> up' with "".
> Perhaps we can continue adding such 'parallel' properties, but I'm
> wondering, can ""
> be replaced with "org.apache.cxf.endpoint.port" or
> "org.apache.cxf.http.port" ? Later on, in post 1.2, we can deprecates some
> of other 'duplicate' properties.

Well, the Remote Services Admin spec mandates that the configuration
properties follow a certain pattern. If the configuration type is
called then its specific configuration variables
should be called (see table 122.1 in the
OSGi 4.2 Enterprise Spec
This is to avoid name clashes when you want to expose a service using
multiple Remote Service implementations that may not be aware of each
other. So to be compliant we have to live with parallel properties.

I do agree on matching up the properties where this makes sense across and

> - HTTPS support ? May be a discussion on the dev list can be initiated, a
> solution agreed upon and then someone from the community can step forward
> and work on it ? As a side note, a CXF user has approached me regarding
> fixing a JAXRS Jettison issue in DOSGI 1.1 (default Jettison provider does
> not work in DOSGi 1.1, needs to be fixed for 1.2 too) so I think there are
> experienced and motivated users who can help...

While I agree that this would be great to have, I'm not sure if we
should wait for it to be finished. I'm not aware of anyone working on
this at the moment (please correct me if I'm wrong!). Months of work
have gone in making CXF-DOSGi compliant with the spec and I don't
think we should hold releasing this off until a nice piece of
functionality which hasn't even been started on has been finished.
There's nothing wrong with releasing often, so if this functionality
appears we can do a release again, unless someone is already working
on HTTPS support of course...

Best regards,


View raw message