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
