Grails Config Values Per Tomcat Host

Sometimes in a Grails application it is necessary to have configuration values available at the Tomcat Host level. An example of such a situation would be needing multiple Hosts in a single Tomcat instance all using the same version of a war. Each war is essentially a copy that contains generic application code that relies on external configuration values to configure its own database, Host-specific labels, integration configuration, etc. For example, you could have 3 Hosts – check here for details on specific configuration of Tomcat Hosts:

Each Host’s application will need its own external configuration files, which is a problem since the wars are identical copies. The traditional use of external configuration in bootstrap.groovy would end in each Host using the same files and being configured for the same Host:

We need a way to provide the application with variables pointing to the correct configuration files on a per Host basis. We can solve this with JNDI by configuring a Tomcat Context for each Host. Each Context will contain an Environment variable containing the location of the correct configuration file. In the {Tomcat}/conf/Catalina/{Host} directory, create an xml file for each Host (I’ll call it context.xml) containing:

The “grailsExtConfFile” Environment variable will be available to your application, so you just have to look it up and use it in Config.groovy:

Your application is now ready to deploy and run as multiple Hosts on one Tomcat instance. But how do you run locally while developing and testing? The easiest way is by detecting the environment and providing external configuration files more traditionally if Environment.DEVELOPMENT or Environment.TEST:

About the Author

Object Partners profile.

One thought on “Grails Config Values Per Tomcat Host

  1. Naresha says:

    I see that JNDI lookup code is executed when I run ‘grails war’. Is there anyway it can be executed during runtime?

    Thanks.

    1. Naresha says:

      Thanks. It works though I get the error in JNDI lookup when I run ‘grails war’.

  2. When I used this mechanism I just wrapped the lookup in a try/catch and ate the exception so it wouldn’t affect the packaging process. However, I believe you could use BuildScope to see if the current scope is “war”, and if so don’t do the lookup. Expanding on the code from above it would be something like :


    if (Environment.current in [Environment.DEVELOPMENT, Environment.TEST] || BuildScope.current == BuildScope.WAR) {
    exConfig = “file:/path/to/local/applicationConfig.groovy”
    } else {
    try {
    exConfig = ((Context)(new InitialContext().lookup(“java:comp/env”))).lookup(“grailsExtConfFile”)

  3. Sebastian says:

    You might need to add additional import statments into the Config.groovy file:

    import javax.naming.Context
    import javax.naming.InitialContext

  4. blacar says:

    It works perfect. Thanks for this!

    However i see you are using println … would it be possible to use log.warn or something like that? … i’ve tried but it does not works out of the box.

Leave a Reply

Your email address will not be published.

Related Blog Posts
Natively Compiled Java on Google App Engine
Google App Engine is a platform-as-a-service product that is marketed as a way to get your applications into the cloud without necessarily knowing all of the infrastructure bits and pieces to do so. Google App […]
Building Better Data Visualization Experiences: Part 2 of 2
If you don't have a Ph.D. in data science, the raw data might be difficult to comprehend. This is where data visualization comes in.
Unleashing Feature Flags onto Kafka Consumers
Feature flags are a tool to strategically enable or disable functionality at runtime. They are often used to drive different user experiences but can also be useful in real-time data systems. In this post, we’ll […]
A security model for developers
Software security is more important than ever, but developing secure applications is more confusing than ever. TLS, mTLS, RBAC, SAML, OAUTH, OWASP, GDPR, SASL, RSA, JWT, cookie, attack vector, DDoS, firewall, VPN, security groups, exploit, […]