I have a grails app that has some run-scripts that I want to run in my build process. I'm using a build process with ant that does a bunch of things before it creates a war file.
However, the running of the script wants to connect to the database in the datasource file. So that fails. I want to be able to configure the datasource file so that it has a connection during the running of the app on dev, qa, staging and production servers. But I want it to ignore the connection definitions during running of special scripts on my build server.
What is the proper way to do this please?
The simplest thing to do would be to create a new environment that uses an in-memory database, e.g.
environments {
nodb {
dataSource {
url = "jdbc:hsqldb:mem:nodb"
driverClassName = "org.hsqldb.jdbcDriver"
username = "sa"
password = ""
}
}
development {
...
}
and then specify it when running the script:
grails -Dgrails.env=nodb <scriptname> <args>
Related
We're running an EmberCLI application in our infrastructure, and I'm tasked to make it work better with the rest of our services. One thing that's a bit interesting about EmberCLI is that all it's configuration variables are baked into the build by default. (Specifically in the <meta> tag).
I had trouble finding a way to supply runtime configuration. We have an "API_URL" environment variable that's supplied to all our services so they can find the API. What is the recommended way to supply this url to EmberCLI at run-time, so I can avoid a rebuild and have fully-built docker containers with our frontend application.
If you want to use an environment variable for configuration ember-cli-dotenv will help. It allows you to access an environment variable in config/enviroment.js:
// config/environment.js
module.exports = function(environment){
return {
apiUrl: process.env.API_URL
}
};
You have to whitelist the environment variables used in ember-cli-build.js:
// ember-cli-build.js
module.exports = function(defaults) {
var app = new EmberApp(defaults, {
dotEnv: {
clientAllowedKeys: ['API_URL']
}
});
return app.toTree();
};
A short side note: Configuration variables are baked into the build by ember-cli cause ember-cli has done it's job after build. Files generated should be served by a normal webserver like nginx. The webserver which could be started with ember serve should not be used in production.
I would like to create a custom grails environment which combines the on-the-fly recompilation feature of the 'development' environment with the persistent database feature of the 'production' environment. However, I do not wish to alter either the development or production environment configurations.
I've tried using the -reloading command line parameter, however, it doesn't appear to have any effect.
It would be great if there were a flag that lived in the conf directory somewhere...
You can create a new environment in the DataSource.groovy file under the section
environment {
developemnt { ...
}
production { ...}
test { ... }
custom{ .. //your code here}
}
with your custom configuration, then
you can run a custom configuration with: grails -Dgrails.env=customEnvironment run-app
https://grails.org/Environments
BTW, if you want your DB to be persistent you only have to change dbCreate to update:
dbCreate = "update"
in the DataSource file in the environment you want to be persistent.
I need, in Config.groovy, the $userHome variable.
It works in my development machine, infact I use the following:
environments {
development {
grails.plugin.elfinder.rootDir =
"${userHome}/docm_patients_doc/{patientcf}/"
...
}
production {
grails.plugin.elfinder.rootDir =
"${userHome}/docm_patients_doc/{patientcf}/"
...
}
}
or
environments {
development {
grails.plugin.elfinder.rootDir =
"${System.properties.'user.home'}/docm_patients_doc/{patientcf}/"
...
}
production {
grails.plugin.elfinder.rootDir =
"${System.properties.'user.home'}/docm_patients_doc/{patientcf}/"
...
}
}
In my production machine, it seems that $userHome is usr/share/tomcat7 and not the correct Home path.
Why do I have this behaviour?
That probably is the correct behaviour - it looks like your production Tomcat is running as a specific system user (probably called tomcat7 or similar) whose home directory is /usr/share/tomcat7.
If you want to set up different values for a configuration option for the development and production systems, the standard way to do that is to use the environments mechanism
// standard value
grails.plugin.elfinder.rootDir = "${userHome}/docm_patients_doc/{patientcf}/"
environments {
production {
// override the value for the production environment
grails.plugin.elfinder.rootDir = "/data/docm_patients_doc/{patientcf}/"
}
}
Now in development mode it will use the standard path involving ${userHome} but when running in production mode (when you build a grails prod war and deploy it to tomcat) it will use the setting from inside the environments block. You can likewise have a development block inside environments for settings that apply only in development mode.
Note that Config.groovy is parsed from top to bottom, so the generic settings must be ahead of the environment-specific ones.
During my grails app development phase (when I compile and run using grails run-app), all my static files reside in web-app folder as usual.
Is there a way (using config or command line parameter) I can use a different directory, say web-app2 for my static files? Something like grails run-app -Dgrails.static.loc=~/web-app2 run-app?
I need this only for development time. For production and deployment, I'm fine with the default behavior.
in your config.groovy you can set environment-specific configurations,
sth like
environments {
development {
grails.resources.work.dir = '/webapp-2/'
grails.resources.uri.prefix = '/staticstuff/'
}
production {
grails.resources.work.dir = '/webapp/'
grails.resources.uri.prefix = '/static/'
}
}
you can start your application with
grails dev run-app // runs with the "development" data source
grails prod run-app // runs with the production data source
I tryed it out, works well!
have a look at http://www.grails.org/Environments and http://grails-plugins.github.io/grails-resources/guide/9.%20Configuration.html
I was wanting to run a custom environment called "local"...as in a local dev. I would use the config (eg DB connections) of this before a war would be deployed to the "shared" development server. But I noticed that it lacks the behavior of the standard Grails "development" Environment, such as Changes to a GSP were not available when you refresh the browser.
So this led me to wonder how do you change the behaviours of a custom environment? How can you copy all the settings for "development" to another environment?
You can enable reloading of modified gsp in a custom environment specifying the run-app flag:
-Dgrails.gsp.enable.reload=true
I don't think the automatic reloading is environment dependent. If you execute grails run-app, reloading will happen regardless of which environment you run under. In other words, automatic reloading will happen for all of
grails dev run-app
grails prod run-app
grails test run-app
On the other hand, reloading will not happen if you build a war using grails war, then deploy it. So reloading depends on how you run the app, not the environment. The easiest way to define a custom environment that is similar to dev, is to define a set of default configuration, then selectively override the settings for each environemnt, e.g.
//default config
myApp {
userRoleName = 'ROLE_USER'
adminRoleName = 'ROLE_ADMIN'
dateFormat = 'yyyy-MM-dd'
}
environments {
// config overrides for dev
development {
myApp.dateFormat = 'yyyy/MM/dd'
}
// config overrides for local
local {
myApp.dateFormat = 'MM/yy/dd'
}
}