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
