My problem is that I've put a well-formed properties file in my classpath and told grails to look for the properties file in my classpath, but the properties in the file aren't overriding the existing ones.
In my config.groovy I have the lines:
grails.config.locations = [ "classpath:${appName}-config.properties",
"file:./${appName}-config.properties"]
// verified that appName is being used. It prints out classpath:XXX-config.properties, as expected, where XXX is my appname.
println "grails.config.locations: ${grails.config.locations}"
In my XXX-config.properties, I specify a different DB connection URL (this is the one I want to use):
dataSource.url=jdbc:postgresql://products.yyyyy.ap-southeast-1.rds.amazonaws.com:5432/mydatabasename
Then I put the XXX-config.properties in my classpath and startup tomcat7, but the errors are thrown, saying it can't find my deliberately fake db, meaning the database property did not get overridden.
Now I'm thinking my classpath is wrong, but I do ps aux | grep tomcat which tells me that the command line arg for tomcat7 contains " -classpath :/home/jbu/:_other_paths_here_". Note I put my properties file at /home/jbu/XXX-config.properties. I am slightly concerned about that leading colon, but it doesn't seem to cause any other problems.
So the classpath dir appears correct, so now I thought maybe my properties file isn't properly formatted, so I added a harded "file:/home/jbu/XXX-config.properties" to my grails.config.locations, and the properties were found and successfully overridden, meaning nothing is wrong with the properties file itself.
I don't have any more ideas here. Can someone help me out?
Sidenote: I modified the CLASSPATH variable for tomcat7 by adding this line to /usr/share/tomcat7/bin/setenv.sh:
export CLASSPATH="${CLASSPATH}:/home/jbu/"
This (among with many other things in Grails, it seems) is broken. Sigh...I'm using grails 2.4.5 so I'm a bit surprised that it has been broken since 1.3.5.
http://jay-chandran.blogspot.com/2010/10/grails-using-external-properties-file.html
Grails 1.3.5: How to configure Datasource.groovy to either connect to MySQL or SQL Server
Related
Please note: Although I'm using the Grails Shiro plugin I believe this to be a core Grails problem, having nothing to do with the plugin whatsoever.
Mac (Yosemtie) and Grails 2.4.5 here. Here's the top 2 lines from my Config.groovy:
String configFileAbsPath = System.getProperty('configFileAbsPath')
grails.config.locations = [ "file:${configFileAbsPath}" ]
So to run locally I do something like:
grails -DconfigFileAbsPath=/Users/myuser/tmp/myapp.properties run-app
When I run this exact invocation, my app starts up and behaves just fine.
However, in non-local environments I want my config file to live under /opt/myapp/myapp.properties. So on my local machine I create a /opt/myapp directory, and then ran chmod -R 777 /opt/myapp. I then copy myapp.properties to it and run:
grails -DconfigFileAbsPath=/opt/myapp/myapp.properties run-app
This produces the following stack trace:
| Error Error generating web.xml file (NOTE: Stack trace has been filtered. Use --verbose to see entire trace.)
groovy.lang.MissingPropertyException: No such property: shiro for class: java.lang.String
at ShiroGrailsPlugin$_closure4_closure30_closure34.doCall(ShiroGrailsPlugin.groovy:248)
at ShiroGrailsPlugin$_closure4_closure30_closure34.doCall(ShiroGrailsPlugin.groovy)
at ShiroGrailsPlugin$_closure4_closure30.doCall(ShiroGrailsPlugin.groovy:243)
at ShiroGrailsPlugin$_closure4_closure30.doCall(ShiroGrailsPlugin.groovy)
at ShiroGrailsPlugin$_closure4.doCall(ShiroGrailsPlugin.groovy:242)
I seriously doubt that the location of an external config file, or the file permissions set on the config file (or its parent dir) would break the Grails Shiro plugin. I think this is just a misleading Grails/Groovy exception. Most likely some kind of security exception is causing something to not load/populate correctly (and fail silently), and then when Grails Shiro kicks in during run-app, its missing something that should be there and is causing run-app to die.
Any ideas as to what is going on, or what the fix is?
Update: Running grails clean, grails clean-all and/or grails refresh-dependencies prior to invoking grails run-app do not help/solve this error either.
I generally prefer to have .groovy file for external config rather than .properties because I can write printlns into it to check whether the file is loaded or not.
Suppose I have a Grails application named myCoolApp.
Furthermore, suppose I have defined some basic properties in grails-app/conf/Config.groovy and grails-app/conf/DataSource.groovy under the test and production profiles.
Config.groovy is set to merge with the following .groovy external configuration file, if found at all:
grails.config.locations = ["file:${userHome}/.grails/${appName}-config.groovy"]
Finally, I have also defined, inside an external testing server, such a file, under a local *NIX user path:
/home/appServerTestUser/.grails/myCoolApp-config.groovy
Sadly, I find that for some reason, the external .groovy file's properties are not being merged when a Tomcat instance starts up.
What options do I have to make Grails tell me: "Oh, yes, I found your external config file at: /home/appServerTestUser/.grails/myCoolApp-config.groovy" and these are the properties I merged into Config.groovy?
Thanks!
File-based paths don't make much sense in a deployed app. It could work when deploying on your dev machine for testing, but will likely fail on any other machine. And it'll probably fail locally even if configured with the correct path since the process will like run as a different low-priviledge user.
You can use absolute paths, e.g. /etc/myapp/path/to/file, but this tends to couple deployment to filesystem structure, so if you develop in Windows and deploy on Linux it'd be tricky to get them both working.
So the best bet for Tomcat deployment is to use the classpath syntax. You can specify multiple files and it will load all that it finds, so I usually have one entry for local dev and one for the deployed app:
grails.config.locations = [
"classpath:${appName}-config.groovy",
"file:./${appName}-config.groovy"
]
I delete the entries for .properties files because Groovy syntax is so much more flexible, but use them if you like. I also keep the dev files in the project root (and exclude from source control).
So when deploying, name the file correctly (different apps will have different files, so no clashing there) and put them in Tomcat's lib directory. This is in the classpath, and so the classpath: entry will see it.
Eventhough the jndi properties file is kept in the classpath its not loaded and JNDI properties when configured in JVM arguments in ANT its working fine.
<jvmarg value="-Djava.naming.factory.initial=org.openejb.client.LocalInitialContextFactory"/>
How to configure the JNDI thorugh properties so that even when
Context=new InititalContext() is used in the EJB's the JNDI properties that are configured in properties needs to be loaded.
Thanks,
Velmurugan R
Definitely make sure the jndi.properties file is at the root of the classpath and not in a META-INF/ directory or any other location. By root, I mean some directory that is parallel to a where a META-INF/ would be. For example:
foo.jar/jndi.properties
foo.jar/META-INF/MANIFEST.MF
That file is processed by the JVM itself, so if it doesn't work, odds are it is related to it not being on the classpath correctly.
I have in my main config something like:
grails.config.locations = ["file:grails-app/config/Jawr.groovy"].
When running the application with grails run-app, everything is OK.
But, on deployment (creating the war archive) this does not work anymore, as the file "Jawr.groovy" is not kept anymore on the filesystem (it should be only in the war).
Do you have a solution for that? Hw do you include external files into the grails main configuration file?
Thanks.
Okay, a few things here.
First, because you don't have a leading slash on your config path, that is a path relative to who knows where. I played with this in Tomcat, and that path ends up being relative to the working directory you were in when starting the Tomcat server. If you start Tomcat, shut it down, change directories, then start it again, you are going to get two different config paths.
Second, the grails-app directory only exists within the source tree of your Grails project. The structure of an unpacked WAR file is more like the web-app folder of your Grails source tree, with folders like WEB-INF, META-INF, js, images, etc.
Third, you probably want to avoid putting your externalized config file inside the folder of your webapp. The next time you deploy your app, that configuration is going to get wiped away with the old version of the app. One of the points of the externalized config is so that you can redeploy without having to reconfigure.
A simple, but less than ideal, solution would be to use a static, fully qualified path, like /etc/yourApp/conf.groovy, then put that in the documentation. There is also a plug-in that handles this.
http://www.grails.org/plugin/external-config
I haven't used it, but the description makes it sound like it does sensible things.
see this: https://stackoverflow.com/questions/6341117/is-it-possible-that-grails-xxconfig-groovy-as-a-script-no-compile
Then I put it into /shared, and
modify:
//Config.groovy
grails.config.locations =
["file:shared/TZLibConfig.groovy"]
//BuildConfig.groovy
grails.war.resources = { stagingDir, args ->
copy(todir: "${stagingDir}/WEB-INF/shared"){
fileset(dir:"shared",includes:"**")
}
}
In my work, our team often use a system properties to save the path to the config file (often in home folder of the user running the app - for privilege sake). Then we manually copy the config file into that path
To identify that it's the production environment, we use the following code in Config.groovy:
if (System.properties["${appName}.config.location"]) {
grails.config.locations = ["file:" + System.properties["${appName}.config.location"]]
}
This article suggests allowing the user to specify the location of the config file as an environment variable or as a java property --- meaning you can simply specify it with -D on the command-line. This can be used in addition to all the other methods.
I'm using org.apache.tools.ant.listener.Log4jListener to manage logging with my ant script. The ant script is highly configurable and designed to be run different ways with different parameters and therefore I need to be able to log to files specified at runtime. I have a log4j.properties which specifies a log file to be build.log, and despite my attempts to launch ant redefining properties defined in log4j.properties have been unsuccessful.
The build ignores them and continues to write to build.log. I haven't found much support regarding writing to custom files unless it's in Java with their Logger class.
Perhaps I'm thinking this through wrong. log4j.properties isn't treated in the same way as a property file in an ant script (hence overrideable from the command line)? Is there a way I can do this intelligently without writing a custom task or something?
You setup your log4j.properties file using a system property that you can define dynamically on the command line. The property below is "${logfile.name}". An example log4j configuration would be like this:
# logfile is set to be a RollingFileAppender
log4j.appender.logfile=org.apache.log4j.RollingFileAppender
log4j.appender.logfile.File=${logfile.name}
log4j.appender.logfile.MaxFileSize=10MB
log4j.appender.logfile.layout=org.apache.log4j.PatternLayout
log4j.appender.logfile.layout.ConversionPattern=[%-5p]%d{yyyyMMdd#HH\:mm\:ss,SSS}\:%c - %m%n
The command line option to pass a property, when calling "ant", is "-Dlogfile.name={runtime path/filename of log file}". Replace {runtime path/filename of log file} with your file name. When ant is run this value is set as a system property. That system property is then substituted into the log4j.properties at runtime.
http://ant.apache.org/manual/running.html