camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pontus Ullgren <ullg...@gmail.com>
Subject Re: host multiple environment from same installation
Date Fri, 21 Nov 2014 09:48:21 GMT
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.ibsen@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 <arno@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: cibsen@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/

Mime
View raw message