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: http://camel.465427.n5.nabble.com/CXF-cross-cutting-concerns-tp5778798p5779020.html Sent from the Camel - Users mailing list archive at Nabble.com.
