Thanks Babak. Ah, your note about the Camel default configuration was enlightening! I would like to share more about our specific situation to gain your endorsement of our approach.
Situation: <1> I expect our systems will contain hundreds of Camel context files, at least one context file for every EDA event type in our systems. <2> Camel will exist as part of the common runtime of every installation. This can be up to thousands of nodes. <3> The behavior of each node needs to be controlled <4> File-based asset configuration is preferred over code-based Solution: I see many benefits in the default behavior of simply loading all XML files in the META-INF/spring directory versus explicitly listing the XML files in the java code. <1> Camel behavior is controlled by the existence of file-based assets in a certain folder. This allows for ease of use in changing behavior for both technical end-users and our dev-to-prod deployment model. Changing behavior is a matter of dropping new XML files and restarting Camel. In OSGI, I believe this will not even require restart of Camel. <2> Does not require compilation of java code. <3> Simplicity Questions: <1> What are your thoughts on this justification? Disadvantages? <2> What is the name of this approach shown in the java code? Are we "launching a spring container as a stand-alone Camel application" ? <3> In further testing, the name of the Camel context id does need to be unique for both to load. However, I removed the id field and both loaded. Should I simply remove the id? What disadvantages does this have? -- View this message in context: http://camel.465427.n5.nabble.com/Loading-two-camel-context-files-at-start-tp5049449p5052681.html Sent from the Camel - Users mailing list archive at Nabble.com.
