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 Tue, 12 Jul 2016 07:25:24 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message