Would be easier to help if you describe what runtime and DSL you was/are using for Camel (and Mule).
If your using a servlet container deploying your integration applications as WAR filer and use Spring DSL then you can use this simple trick (http://stackoverflow.com/questions/4221974/external-config-based-on-context-path). So simply add this to your beans definition and it will load properties files from /etc/ based on context path of the war. <context:property-placeholder properties-ref="props" /> <util:properties id="props" location="file:///etc/#{servletContext.contextPath}.properties"/> Since Mule is Spring based you can do the same there (provided you deploy those apps as WAR and do not use the Mule ESB runtime). // Pontus On Fri, Nov 21, 2014 at 7:12 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > Hi > > Do you want to keep the configuration external to the deployed > artifact (eg WAR)? > And the only thing you do is copying the WAR with a new name, and then > deploy that in Tomcat. > You are not including the configuration inside the WAR file? > > You would need some kind of servlet init code that figures out the > context-path or name of the WAR and then use that to load the > configuration / or set some system property that are used for knowing > where the external configuration files are etc. > > Or some known file that has a mapping where you add a line when you > deploy a new artifact, and the new line then directs where the > configuration is for that new deployment. > > You can also use ENV or JVM system properties but the ENV cannot > easily be changed when a JVM has started up. But a JVM system property > can be reconfigured, but that requires Java code to do so etc. > > > > And btw shame on the Mule change, as the donkeys are much less > powerful as Camels when it comes to animals. > http://camel.apache.org/why-the-name-camel.html > > > > On Thu, Nov 20, 2014 at 7:43 PM, arno noordover <a...@noordover.net> wrote: >> We are in the proces of deciding what "ESB" implementation to use. >> Previously we used Camel. Currently we are experimenting with Mule (not my >> choice ). >> Apparently the bussiness wants to use one "ESB" installation to support >> multiple test environments while in production we only support one >> environment. >> A Mule-consultant is trying to implement something like "war"-name based. He >> is trying to implement the loading of properties using the name of the >> deployment. >> With this strategy we can copy the deployment, rename it and have a separate >> configuration for this second deployment. >> >> How would you solve this using the camel/fuse/hawtio/zookeeper stack? >> So, the requirements are: >> - one server; >> - one instance of e.g. tomcat; >> - multiple deployments on this tomcat server of the same artifact (maybe >> renamed) >> - configuration per deployed artifact >> >> It isn't needed to describe everything but naming the tools that should be >> use is helpfull. >> >> Thanks, >> Arno Noordover >> >> >> >> -- >> View this message in context: >> http://camel.465427.n5.nabble.com/host-multiple-environment-from-same-installation-tp5759379.html >> Sent from the Camel - Users mailing list archive at Nabble.com. > > > > -- > Claus Ibsen > ----------------- > Red Hat, Inc. > Email: cib...@redhat.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen > hawtio: http://hawt.io/ > fabric8: http://fabric8.io/
