camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quinn Stevenson <>
Subject Re: Invoking Dynamic OSGi Blueprint services from a Java RouteBuilder
Date Thu, 28 Jan 2016 15:05:34 GMT
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 <> 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:
> Sent from the Camel - Users mailing list archive at

View raw message