camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ranx <>
Subject Re: CXF cross cutting concerns
Date Mon, 14 Mar 2016 14:37:19 GMT

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

View raw message