Question

I’m trying to use Grails’ built-in mechanism for loading external configuration files (*.groovy and *.properties) outside the deployed WAR file. The documentation implies this is just a case of setting grails.config.locations with the appropriate classpath: or file: paths.

I’ve configured Config.groovy with:

String externalConfigLocation = System.getProperty("SYSTEM_PROPERTY_KEY")
if (!grails.config.locations || !(grails.config.locations instanceof List)) {
    grails.config.locations = []    
}
if (classpathExternalConfigLocation) {
    String pathToResource = "\"file:${basedir}" + File.separator + externalConfigLocation+"\""

    print "Loading external configuration file: ${pathToResource}\n"
    grails.config.locations << pathToResource
}

However this hasn’t worked, with error messages indicating the file “Does not exist”. However, printing the absolute path stored in grails.config.locations indicates it does. I have tried some combinations:

• classpath:configurationFile.properties
• file:c:\path_to_file\configurationFile.properties
• c:\path_to_file\configurationFile.properties

but in all these cases the file can’t be found.

Very strange – advise appreciated. Or suggestions on how to debug.

Answer 1

This is what I usually do:

grails.config.locations = ["classpath:${appName}-config.groovy",
                           "file:./${appName}-config.groovy"]
if (System.properties["${appName}.config.location"]) {
   grails.config.locations << "file:" + System.properties["${appName}.config.location"]
}

This lets me put a file in the project root to customize properties locally when developing (using the file: location) and a file in the server’s classpath when deployed as a war. Tomcat’s lib folder is in its classpath so that’s a good place to put files if you’re using Tomcat. By putting the app name in the file you can have multiple config files without them stepping on each other.

Be sure to add the local config file to svn:ignore or .gitignore so you don’t check it into source control. Each developer can then have their own settings (or just use the defaults) without affecting the others.

This is a great way to externalize database passwords and other production values. The app deployer (ideally not a developer) manages the file and its contents and this avoids checking in passwords into source control. Much better than using JNDI IMO.