I've reverted to using blueprint.xml for any service reference calls and limiting the routebuilders for now. The part I found most disconcerting about this was that the implementation class was being found since it should be hidden. That means the classloader is pulling it from a bundle and providing it even though the META-INF is explicitly making it private. At that point I get the hair raising vision of multiple classloader mechanisms loading and instantiating instances in different fashions. I don't have the time to look into deeper but I do know I don't want classes leaking out of their bundles like that.
In other words, the whole OSGi mechanics are being circumvented. When I reverted to blueprint and did a print on the reference I correctly see the Proxy class of the interface printed out. That's unfortunate. Using the route builders gave me a good way to do testing and get around some of the restrictions that CamelBlueprintTestSupport has for multiple CamelContexts. Would it make sense for CamelBlueprint to preferentially do look ups in the OSGi registry and only fall back to looking in the other registries if the interface or id is not found? Personally I'd prefer to have a strict mode flag that would require items to come out of the OSGi registry when working in blueprint. -- View this message in context: http://camel.465427.n5.nabble.com/Invoking-Dynamic-OSGi-Blueprint-services-from-a-Java-RouteBuilder-tp5776755p5776864.html Sent from the Camel - Users mailing list archive at Nabble.com.
