Thank you Ranx - Unfortunately, I haven’t figured out a way to get around using RouteBuilders for my use case. Since I have a few very common patterns for my routes where the only differences are endpoint configurations and a few other minor things, I can create a few common RouteBuilders and use them to create hundreds of CamelContexts/routes - much like an OSGi ManagedServiceFactory.
I haven’t figured out a clean way to create a route using the Blueprint DSL and then reuse that route with different configurations as of yet, so this is my only option. As you pointed out though - it’s much easier/faster to test using CamelTestSupport than it is using CamelBlueprintTestSupport, so I like the "Java RouteBuilder deployed using Blueprint" pattern for that as well. Camel Committers: I guess it’s time for a JIRA issue - is there any particular information you’d like me to include in this issue? Quinn Stevenson > On Jan 27, 2016, at 3:22 PM, Ranx <brad.john...@mediadriver.com> wrote: > > 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.
