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 Mon, 14 Mar 2016 20:48:45 GMT
I have now created the Aries Remote Service Admin project.

It has similar features to what you described but also is an OSGi standard.
So you can nicely extend it while not needing to implement all yourself.


2016-03-14 15:37 GMT+01:00 Ranx <>:

> Christian,
> I'll take a look at that.
> The nice thing about using the white board as a webservice registration
> mechanism is that I can define all my interceptors, handlers, and security
> in a single project.  Then when a bundle is installed it registers itself
> for exposure.  My new server project picks it up an creates JAXWS and JAXRS
> servers/endpoints for the bundle and exposes it.
> When the bundle is uninstalled the unregister method gets called on the
> manager and that then undeploys the related endpoint.  No dangling
> resources
> or proxy time outs.
> My manager project keeps a map of the registered microservice and as a
> convenience in my basic implementation of the microservice I instantiate a
> UUID to a final String on it and return that as the unique identifier.  So
> when the bundle is uninstalled and the manager receives that notificatoin
> and simply calls to get the unique identifier to pull the container object
> that holds the JAX WS and JAX RS servers in it.  It calls stop/destroy on
> them and nulls the handles out in the container as well as removing it from
> its map/regsitry.
> Now when the microservice installs it gets auto deployed with all my
> security and logging and badgerfish settings.  It is also automatically
> invoked by a web service call without having to configure routes.  As for
> the use of Camel routes, I've now inverted that so that the routes I use
> live only in the bundles and don't talk across them.  The service
> interfaces
> are for cross bundle talking.  So all my projects now have a "connector"
> class and I'm using @EndpointInject to inject the camel routes.
> So when the bundle gets deployed, it is auto installed as a webservice if
> it
> exposes itself via the whiteboard/service registry.  When the service is
> called it invokes the implementation class which holds a handle to the
> connector.  That endpoint can then call 0..N camel routes.  In a way it is
> like using an inverted Camel Java DSL.
> Because that connector class wraps the camel routes any casting or fishing
> of references out of lists (like MessageContentList or BeanIO arrays) can
> be
> done inside that object and not be visible to the calling class.  The
> caller
> is just invoking a method on a POJO and getting a response back.
> The only downside is I'm now having to use the JAX WS and JAX RS service
> factories directly and creating the endpoints myself as the Camel or at
> least Camel/blueprint wouldn't permit that sort of dynamism.
> Because I'm using that service registration mechanism I can also
> instantiate
> multiple managers bound to different ports with different
> security/transports and simply filter on the OSGi microservice registration
> to determine if it should expose it or not.  So if I have different
> security
> requirements for invoices, supplier look up, etc. I can set that up in one
> project and then whatever bundles get installed and register themselves
> correctly will get picked up and exposed automatically.
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

Christian Schneider

Open Source Architect

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message