cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: [Heads up] Design of new major version of CXF DOSGi
Date Wed, 06 Jul 2016 19:28:37 GMT
Hi Christian
On 06/07/16 18:42, Christian Schneider wrote:
> 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 =
> "org.apache.cxf.jaxws.service.AnnotationFeature")
> 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.
Most of this code as far as I know deals with instances, not classes.

> What do you think? Should that work?
Let me ask you instead, will it work ?
With DOSGI 1.8.0, as far as I recall, one just registers an instance of 
a given provider and it works.
What DOSGI RS users would need to do to register an instance of a 
Jackson provider for example, start creating some intent like "json" ? I 
honestly do not how it will work.

I don't mind with 2.0 the DOSGi users being encouraged to do pure DOSGi 
with the intents, but IMHO the JAX-RS provider *instance* registration 
code which already works should continue be there rather than remove it 
and hope for the best the intents will help :-).

Thanks, Sergey
> Christian
> 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

View raw message