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 Thu, 21 Jul 2016 14:32:13 GMT
Hi Christian
Nice, IMHO this is a nice improvement which will help not only (D)OSGI 
users,
I'll tweak a bit the features to accept JAX-RS clients (they implement 
InterceptorProvider & ConduitSelectorHolder)

SErgey
On 21/07/16 11:47, Christian Schneider wrote:
> 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
>
>


Mime
View raw message