Changing the already posted busses is not such a good idea.
The CXF DOSGi way is to use intents. You can publish a feature as a
service and give it a property org.apache.cxf.dosgi.IntentName=myname.
In the OSGi service to be exported you can then set the property
service.exported.intents to a list of intent names that must be supported
to export this service.
CXF DOSGi will then make sure it finds suitable intent services and will
apply them as features before exporting your service.
Christian
On 14.03.2016 21:52, Raul Kripalani wrote:
Hi
I blogged about this a long while ago. CXF registers all buses as OSGi
services, so you can create a service listener that watches them come and
go, reacting accordingly. You do get a reference to the bus, so you can add
interceptors, features or change whatever configuration you'd like to by
finding your way around the API.
Have a look at
http://raul.io/enriching-services-with-cxf-interceptors-in-osgi/, and let
me know if it helped.
Cheers,
Raúl.
On 9 Mar 2016 15:26, "Ranx" <brad.john...@mediadriver.com> 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:
com.foo.basic.rest.cfg
com.foo.basic.soap.cfg
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:
http://camel.465427.n5.nabble.com/CXF-cross-cutting-concerns-tp5778798.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
