Multiple camel blueprints in one OSGi bundle?

Question

I'm trying to figure out if I should package multiple blueprint.xml files in a single OSGi bundle that I want to deploy into karaf. Each blueprint.xml file has one camel context. I've tried to just throw all my blueprints into the OSGI-INF/blueprint folder, but I got an error saying

Name 'jms' is already in use by a registered component

That seems to make sense, because I do this in every blueprint.xml

<bean id="jms" class="org.apache.camel.component.jms.JmsComponent">
    <property name="connectionFactory">
        <bean class="org.apache.activemq.ActiveMQConnectionFactory">
            <property name="brokerURL" value="tcp://0.0.0.0:61616"/>
            <property name="userName" value="karaf"/>
            <property name="password" value="karaf"/>
        </bean>
    </property>
</bean>

Should I even do that? Or would it be better for each CamelContext to be it's own bundle? I've seen this https://camel.apache.org/manual/latest/faq/why-use-multiple-camelcontext.html and it says that multiple CamelContexts would make sense when they're deployed as isolated bundles. So what's the best practice here:

• Each CamelContext with it's own blueprint.xml, bundled with the necessary beans into an osgi-bundle?
• One bundle for all necessary beans, and just drop the blueprint.xml files in karaf's deploy folder?
• One CamelContext which imports all the other CamelContexts, bundled with all necessary beans?

Answer 1

This is more of a question about service design, not Camel.

Since a bundle is a deployment unit , I would first of all look at the different lifecycles of your code .

If some things must always be deployed together , if they cannot evolve individually , you can make one bundle containing them. Simply because, in terms of releasing and deployment, you cannot profit from dividing the code into smaller units.

On the other hand, if something is evolving faster or slower and must therefore be deployed more often (or less often), you should put it in its own bundle .

This way you are able to deploy code only when it really changes . In contrast to a giant EAR file to deploy a big monolithic application when only a small bugfix was implemented.

So, in summary, you can use more or less the microservice principles to "cut" your code into units.