grails / external configuration / grails.config.locations - absolute path file "Does not exist" ?

Question

Hi

Thanks for reading,

I'm trying to use grails build-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. have tried some combinations, classpath:configurationFile.properties, file:c:\path_to_file\configurationFile.properties and 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

I dont think you get base.dir when running the war

Answer 2

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.