camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: CXF cross cutting concerns
Date Thu, 10 Mar 2016 09:16:02 GMT
I have searched for a solution to the problem you described for a long 
time now and finally found a good concept.
Cross cutting concerns can be solved using the TopologyManager in the 
Remote Service Admin spec (CXF-DOSGi).

One duty of the TopologyManager is to watch all registered OSGi services 
and then eventually trigger RemoteServiceAdmin to export such services.
See this tutorial for a simple example:
The service in the DS example leverages DOSGi to export a REST service:

By default the TopologyManager only watches for services with the 
property osgi.remote.interfaces but according to the spec it can react 
on any service it wants.
It also can add arbitary configuration to the OSGi service properties.

One of these properties are the intents a service must support. For CXF 
this translates to CXF features.

So this can be used to add cross cutting concerns like security, logging 
to any service.

The CXF provider for RemoteServiceAdmin can then export and import the 
OSGi services as REST and SOAP services depending on their annotations.
Unfortunately we are not yet there. The current TopologyManager impl 
does not support adding cross cutting concerns but the spec fully 
supports that so we can develop
such support in the future.


On 09.03.2016 16:26, Ranx wrote:
> I have a client who wants to use deployable microservice bundles with
> REST/SOAP APIs.  Not a problem of course as it works very well.
> The issue is that I'm getting a lot of boilerplate replication across the
> project which is only getting to get bigger and more difficult to manage
> with time.
> This includes everything from basic host/port settings to security.
> Obviously setting that up in every bundles is error prone (especially with
> XML) and the a real headache for maintenance.  Part of the problem is that
> from what I've read sharing cfg files across bundles is not recommended.
> Perhaps with an update strategy reload that isn't such a big deal.  But it
> would be nice to have something like:
> and use that in each of my bundles to load basic configuration information.
> Each bundle would still have its own cfg file that will be used for very
> special and custom items.
> Things like PasswordCallback and keystores are exactly the same.  In the
> past I've always used a gateway bundle to centralize that.  I may still end
> up using something like that in this project but as "microservices" become
> more and more the holy grail (until it isn't anymore) this is going to be an
> on-going concern.
> I'm using Karaf so can also imagine using OSGi registry for creating CXF
> interceptors that I might inject into the setup of each of my projects.
> This problem is manifesting on the endpoints in both directions.  For
> example, one of the systems I'm integrating with is JDEdwards SOAP services
> which require PasswordCallbacks and http conduit settings.  But there are a
> large number of these services with WSDLs for many aspects of inventory,
> supply, invoices, etc.
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

Christian Schneider

Open Source Architect

View raw message