Hi Christian, Thanks for the reply. That particular issue was solved with an upgrade to 2.3.0 which includes Aries 1.x as you remark. It is a nice use of the ManagedServiceFactory mechanism for sure however it does require that I extend OsgiDefaultCamelContext, this is required for the OSGi container in order to register the CamelContext as a service. In the constructor I inject the bundle context which blueprint kindly provides in the form of a blueprintBundleContext bean reference. I effectively have to do what is done automatically when one defines a camel context inside a blueprint or sping dm context file. What I had hoped to achieve was to use non-OSGi Camel interfaces to implement my context so that I could, keep as much of the OSGi related plumbing inside the blueprint context descriptor as I would also like the option of running my route as a standalone application. The intent was to use a decorator pattern which would inject an OsgiDefaultCamelContext in one case and a DefaultCamelContext in the standalone or pure Camel case. For the OSGi case I would keep the OSGi pertinent details in the blueprint context descriptor.
Anyway I haven't quite solved this one yet but I will post when I do. Your mechanism of providing a route builder factory is also useful, perhaps it could be made dynamic if you use a cm managed component and implement an update strategy for your bundle e.g., the properties themselves could be encoded commands to create new routes. Not exactly elegant but doable. Best regards, Declan -- View this message in context: http://camel.465427.n5.nabble.com/Using-ManagedServiceFactory-to-dynamically-deploy-routes-tp5719969p5731748.html Sent from the Camel - Users mailing list archive at Nabble.com.
