cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [Heads up] Design of new major version of CXF DOSGi
Date Thu, 07 Jul 2016 05:09:27 GMT
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 <sberyozkin@gmail.com>:

> 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/
>>>
>>>
>>
>>
>>
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>

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