cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
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 <sberyozkin@gmail.com>:
>
>> 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:
>>
>>
>> https://github.com/apache/cxf-dosgi/blob/cxf-dosgi-ri-1.8.0/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/handlers/JaxRSPojoConfigurationTypeHandler.java#L98
>>
>> This line should add the providers:
>>
>>
>> https://github.com/apache/cxf-dosgi/blob/cxf-dosgi-ri-1.8.0/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/handlers/JaxRSPojoConfigurationTypeHandler.java#L106
>>
>> 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 Readme.md 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
>> http://coders.talend.com/
>>
>
>
>


Mime
View raw message