I can only judge by what you've described here. If you say there are 600 "instances" of blueprint.xml, does it mean there are 600 Camel contexts?
This is probably more architectural question, then technical one. Imagine you don't use Fuse (or other OSGi framework) and you don't use blueprint, but, for example, Spring contexts. Even if you leverage Spring's <import> mechanism, you could end up with 600 instances of Spring's ApplicationContext - this isn't good. Blueprint container instance (made up from all blueprint XML files found by blueprint extender (aries.blueprint.core bundle) in single OSGi bundle is similar to Spring's ApplicationContext instance made up of different XML files.
In OSGi you have to think the OSGi way - the most obvious decision is to publish common "things" as OSGi services.
If blueprint lacks some mechanism (like parent-child relationship of Spring's ApplicationContexts), you have to try to reuse beans as OSGi services (<service> + <reference>).I'd start with asking a question - how many different (separate) camel contexts ("containers" for routes, dataformats, ...) are there in your application. If you simply need ~600 routes, there's no need to have 600 camel contexts. You could "publish" camel routes using whiteboard pattern and have one (or several) bundles act as "extenders" which monitor these routes being added/removed/modified and act accordingly.In other words - don't make assumption that each OSGi bundle have to equal separate blueprint container.best regardsGrzegorz Grzybek