cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: [Heads up] Design of new major version of CXF DOSGi
Date Wed, 06 Jul 2016 17:42:59 GMT
I have removed all that code as I hope we have other measures to do this.
One approach are the intents that allow to set interceptors using a feature.

Another approach might be to use the annoations for features and
interceptors like
@org.apache.cxf.feature.Features (features =
I think together they should provide the same level of configurability.

The problem with all approaches that take class names is the visibility of
these classes. The intent approach allows to offer a feature as a service
so the user bundle with the service using the intent does not need access
to the impl classes of the feature and interceptors.

What do you think? Should that work?


2016-07-06 16:49 GMT+02:00 Sergey Beryozkin <>:

> Hi Christian
> It all looks like a fine way forward, though I do believe there was a code
> before which allowed setting JAX-RS providers/interceptors
> This line adds interceptors/features:
> This line should add the providers:
> Have you preserved this code ?
> Thanks, Sergey
> On 06/07/16 11:44, Christian Schneider wrote:
>> In the previous days I was working on a new design for CXF DOSGi 2.
>> I would like to begin with a recap of the state of CXF DOSGi 1.8:
>> Since the creation of Aries RSA the CXF DOSGi project is not a full OSGi
>> remote service admin impl anymore. It only provides a
>> DistributionProvider for CXF that can run
>> in Aries RSA. The main problem is that there is just one provider that
>> can do REST and SOAP services. So it always has to carry all
>> dependencies. In the multi bundle distro these are about 100 bundles.
>> There are also a lot of configuration properties including older
>> deprecated properties. The Aegis support in the 1.8 version can not be
>> used with Java8 as Aegis produces an exception during init.
>> So the goals for CXF DOSGi 2 were to make it simpler and more light
>> weight and of course to fully support Java 8.
>> So this is the new design looks like this:
>> - cxf-dosgi-common : HttpServiceManager, IntentManager, ProxyFactory and
>> other small util classes. These are all shared for the providers
>> - cxf-dosgi-provider-ws: SOAP support. If @Webservice annotation is
>> present it does JAXWS/JAXB if not it does Simple/Aegis
>> - cxf-dosgi-provider-rs: REST support. Exposes the service as a default
>> JAX-RS service. It has not property support for setting providers or
>> interceptors
>> - cxf-dosgi-decorator: Allows to expose services using xml. I am not
>> sure if we still need this as Aries RSA can now expose services using
>> configs
>> - cxf-dosgi-repository: Pom that defines all dependencies to OSGi
>> bundles. This can be used as a OSGi repository in the upcoming bnd and
>> bndtools
>> Both providers support intents which can be used to set DataBinding,
>> Binding Config and Features. I think we might be missing support for
>> JAXRS @Provider classes but I am not sure.
>> Apart from this I removed all deprecated config properties and also
>> slimmed down the other config properties. I hope we still cover most use
>> cases but I need your feedback.
>> I created some docs in the source code to explain the current
>> properties.
>> The multi bundle distro is still there and is not really smaller as it
>> still relies on the current karaf cxf and pax-web features which are
>> really big. The karaf features are split into ws and rs. So we do not
>> need to install everything at runtime.
>> To show how small a DOSGi deployment can be I created a small example
>> using bndtools and the repository above and was able to get a SOAP
>> service exported with a runnable jar that just is about
>> 6 MB. So I hope we can support much smaller deployments of CXF DOSGi in
>> the future. Unfortunately I can not yet add this example to CXF DOSGi as
>> it relies on some an experimental pom based repo plugin. As soon as this
>> support is part of a bnd release I will add an example for this packaging.
>> I also hope the new CXF DOSGi can be the default way for karaf boot to
>> expose and consume REST services.
>> I would be happy about your feedback on the new design. Before we do a
>> 2.0.0 release nothing is really fixed so please speak up to get your use
>> cases in.
>> Christian
> --
> Sergey Beryozkin
> Talend Community Coders

Christian Schneider

Open Source Architect

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message