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 Thu, 07 Jul 2016 09:10:03 GMT
Hi Christian

Having a POC is a good idea and given it let me suggest a slightly 
different path.

I'd like to keep the code which is working for JAX-RS users mostly 
intact - if there's some code there which tries to load classes from 
their String names then I agree we can let it go but the code which 
deals with the already instantiated JAX-RS providers without depending 
on some wildcard imports in the DOSGI impl IMHO needs to stay.

I do not know if anyone still uses DOSGi JAX-RS but I 100% sure I worked 
with some of them specifically on the issue of supporting injected 
providers and properties.

Having an intent alternative is interesting and here a POC will help us 
understand how it can be done in a pure DOSGi way. Even if it works well 
I'd still favor keeping the existing JAX-RS option while we can start 
encouraging users to migrate to the Intents way.

However, the goal of this re-design is not to make the JAX-RS part more 
DOSGI-y :-). It is about making a clean split of the monolitic CXF DOSGi 
which I fully support.

Let it be done first and then we can try and go for a POC - it won't 
have to be done for JAX-RS only, we can try and see how it works for 
JAX-WS, example, having a 'BeanValidation' intent or 'Logging' intent, etc.

Sounds reasonable ?

Cheers, Sergey

On 07/07/16 06:09, Christian Schneider wrote:
> Hi Sergey,
> I propose we do a poc for that. Let´s create some customizations for a
> jaxrs service in 1.8.0 syntax together and then I can try to do the same on
> the 2.0 syntax. If we find gaps I will add the code to 2.0 again of course.
> Christian
> 2016-07-06 21:28 GMT+02:00 Sergey Beryozkin <>:
>> 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
>>>>> 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
>>>>> 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
>>>>> the future. Unfortunately I can not yet add this example to CXF DOSGi
>>>>> 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
>>>>> 2.0.0 release nothing is really fixed so please speak up to get your
>>>>> cases in.
>>>>> Christian
>>>> --
>>>> Sergey Beryozkin
>>>> Talend Community Coders

Sergey Beryozkin

Talend Community Coders

View raw message