Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Sender: Christian Schneider <cschneider111@gmail.com>
Subject: Re: [Heads up] Design of new major version of CXF DOSGi
To: dev@cxf.apache.org
References: <577CE124.1080108@die-schneider.net> <577D1A81.1010706@gmail.com>
 <CAH6_LNnVxQ-hpvLuV5TX3JLg1Rvmqe1VvB-der16ebJDgHK01A@mail.gmail.com>
 <577D5BE5.5010703@gmail.com>
 <CAH6_LNnP9x2iwgEaBPibmHrx0ntDSNGw5qqC-ZAqAMQWgkMa-A@mail.gmail.com>
 <577E1C6B.40507@gmail.com> <577E1F43.7090706@die-schneider.net>
 <577E22DA.8080304@gmail.com> <577E2677.4020301@gmail.com>
 <57849B64.3080908@die-schneider.net>
From: Christian Schneider <chris@die-schneider.net>
Message-ID: <23500269-ced7-476f-a725-adc1f4fc70f8@die-schneider.net>
Date: Thu, 21 Jul 2016 10:47:55 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <57849B64.3080908@die-schneider.net>
Content-Type: multipart/alternative;
 boundary="------------584B0B17DB773A3F0C2276BC"
archived-at: Thu, 21 Jul 2016 08:48:05 -0000

--------------584B0B17DB773A3F0C2276BC
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

One more update on this.

On the mailing list we had a request for configure https with DOSGi.
I have now created two new features 
(https://issues.apache.org/jira/browse/CXF-6973):
https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HttpConduitFeature.java
https://github.com/apache/cxf/blob/master/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HttpDestinationFeature.java

These allow to configure http conduits and destinations using features. 
For DOSGi you can create such a Feature and publish it as an OSGi 
service with an intent name
and require the intent in the service. The feature will then be applied 
and the service will be configured with all settings you do in the features.
For the https clients this should already be enough.

For the https endpoints I found that the jetty transport uses a 
JettyHTTPServerEngineFactory that is retrieved from the bus. I am not 
sure what is the best way to hook into that.
There already is a way to configure this using config admin. Maybe this 
is enough. I would be happy about any feedback. It would be a little 
difficult to configure this using intents
as it seems the jetty settings are configured per port and not per 
endpoint. So it does not make much sense to have an intent on the service.

I will create an example that shows https with CXF-DOSGi to prove this 
actually works.

Christian

On 12.07.2016 09:25, Christian Schneider wrote:
> I have taken some more time to look into possible solutions for 
> customizing CXF services and clients.
>
>
>       Current situation (1.x)
>
> The 1.x tree provides a way to set these things on a CXF service: 
> inInterceptors, outInterceptors, faultInInterceptors, 
> faultOutInterceptors, features
> These could be set by providing either the class name or the instance 
> object in a service property.
> On the JAXRS side there is a way to set providers using Class names 
> and by looking up services with a specific marker property.
>
>
>       Issues with the 1.x solution
>
> Setting interceptors and providers by instance is very convenient for 
> plain OSGi and blueprint but does not work in DS. It is also not 
> possible to send these instances to discovery to also create the 
> client from these. So I am not sure if this option was spec conformant 
> at all.
> Another problem is that on the client side you typically need 
> different interceptors. For example if you add something as a header 
> you would use an OutInterceptor on the client and an InInterceptor on 
> the server. So as both client and server must be able to be created 
> from the same set of service properties I think interceptors are not a 
> good choice. A better choice is a feature as the implementation can do 
> different things on the client and server with the same feature 
> definition.*
> *
>
>
>       Possible solution
>
> I propose to use intents for all customizations. An intent is an OSGi 
> service of several possible types that is identified by a special 
> property (org.apache.cxf.dosgi.IntentName).
> A service can specify a list of named intents it requires. The service 
> is then only published when all intents are present as services.
>
> In the current code on master it is possible to use intents for 
> Databinding, Binding Config, Feature and Provider.
> I have also introduced a new interface IntentProvider with one method 
> List<Object> getIntents(). It allows to specify a whole list of 
> intents with one name.
> This is useful if these intents should always be used together. As 
> IntentProvider is not CXF specific we could even move this interface 
> to the Aries RSA spi bundle.
>
> An example for this can be see in this test. It uses the intent "my" 
> with a MessageBodyWriter and a MessageBodyReader. Both service 
> endpoint and client proxy can be created from this
> intent and allow a full roundtrip for a call with customized 
> serialization:
> https://github.com/apache/cxf-dosgi/tree/master/provider-rs/src/test/java/org/apache/cxf/dosgi/dsw/handlers/rest/provider
>
> Such IntentProvider services are easy to publish using any dependency 
> injection framework and allow to set instances which can even be 
> injected with other services if necessary.
> So I think this solution should be viable to set all typical needs for 
> SOAP as well as REST.
>
> So what do you think? Can we use this to replace all the old config 
> options?
>
> Christian
>
>
> On 07.07.2016 11:52, Sergey Beryozkin wrote:
>> I'm not seeing this code in a WS provider either:
>>
>> https://github.com/apache/cxf-dosgi/blob/cxf-dosgi-ri-1.8.0/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/handlers/AbstractPojoConfigurationTypeHandler.java#L186 
>>
>>
>> so it is not possible to add extra CXF interceptors for JAX-WS users 
>> too. The use-cases for adding them to JAX-WS endpoints would be the 
>> same as for JAX-RS.
>>
>> Only
>> https://github.com/apache/cxf-dosgi/blob/cxf-dosgi-ri-1.8.0/cxf-dsw/src/main/java/org/apache/cxf/dosgi/dsw/handlers/AbstractPojoConfigurationTypeHandler.java#L235 
>>
>>
>> is kept across the providers.
>>
>> Look, it is not really a big deal for me :-). But if one has a DS or 
>> Blueprint context it is handy to add CXF logging features or 
>> something else OOB by simply registering a bean in the context.
>>
>> I'd still prefer to keep that code for now at least, then do the 
>> intent POCs, and only then decide if the code can be removed or not.
>>
>> Cheers, Sergey
>
> -- 
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com


--------------584B0B17DB773A3F0C2276BC--