I am using Grails 3.2 and I am wondering where I should put my application variables for different enviroments.
application.yml or build.gradle?
And, how should I define them?
You should put them in the application.yml as stated in the documents:
Configuration in Grails is generally split across 2 areas: build
configuration and runtime configuration.
Build configuration is
generally done via Gradle and the build.gradle file. Runtime
configuration is by default specified in YAML in the
grails-app/conf/application.yml file.
You can also choose to use the Grails 2.0-style Groovy configuration as mentioned in the next alinea:
If you prefer to use Grails 2.0-style Groovy configuration then you
can create an additional grails-app/conf/application.groovy file to
specify configuration using Groovy's ConfigSlurper syntax.
Documentation: http://docs.grails.org/3.2.0/guide/conf.html#environments
Grails supports the concept of per environment configuration. The application.yml and application.groovy files in the grails-app/conf directory can use per-environment configuration using either YAML or the syntax provided by ConfigSlurper. As an example consider the following default application.yml definition provided by Grails:
Related
Just like to define custom Bootstrap.groovy or UrlMappings.groovy in a Grails plugin, we can define FooBootstrap.groovy or FooUrlMappings.groovy so that those can be bundled in the plugin because the earlier are excluded by default. http://docs.grails.org/latest/guide/plugins.html#_excluded_artefacts
How can we do the same for logback.groovy? I have a multi-project build where a single Grails plugin is used by 3 different Grails application.
My research & trials:
I tried creating a foo-logback.groovy but that is not loading.
Grails 3: External Logback.groovy file
Another resource: https://logback.qos.ch/manual/configuration.html
Basically, there can only be one logback.groovy or logback.xml in the classpath. In order to achieve what you are asking you could use your root project's logback.groovy and load a foo-logback.groovy using a GroovyShell instance (see https://stackoverflow.com/a/9006034/260487).
Alternatively you can have the plugin resources defined in its own package and include that package in your root logback.groovy file. For example, instead of com.example.FooService you would define it as com.example.plugin.foo.FooService, and you'd define a log rule for the com.example.plugin.foo package.
I am new to grails and have created my first project using grails-init. I now have a grails project that uses gradle as it's build tool. However, as I go through online tutorials I find that I am missing a lot of the files that are commonly cited. Files such as config.groovy and datasource.groovy.
I've tried re-creating the project, but I get the same structure and files. Can I just add these files manually? I have tried doing so, but they don't seem to be getting picked up when I run the application.
Config.groovy and DataSource.groovy are both applicable to Grails 2 applications but not Grails 3 applications. In Grails 3 the default place for the information that used to go in those files is application.yml.
Grails 3.1 have new features and structure changes. Now grails uses spring boot and Spring 4.2 and as mentioned, Config.groovy and Datasource.groovy can be configured using application.yml. You can found more information here Grails documentation
I'm trying to add a new environment to our Grails WAR (let's call it "staging"). I can manage the configuration in Config.groovy and DataSource.groovy and access the right configuration at run-time with -Dgrails.env, but how do I build this WAR?
The Grails documentation does not cover this case and the links on the page seem to be outdated.
You are so very close to having the right combination in your question, this should work:
grails -Dgrails.env=staging war
Actually, the documentation for the war command even uses 'staging' as the environment used.
The same goes for any environment-specific command:
grails -Dgrails.env=<environment name> <command>
I have two configurations I need to change after building a prod war with grails 1.3.2. I know the project can be setup in ways to do this externally in the first place, but that's not an option at this moment.
1) Need to change environments.production.hibernate.default_schema defined in DataSource.groovy
2) Need to change environments.production.grails.serverURL defined in Config.groovy
Is there any way to edit the war or pass overriding arguments when running the war in JBoss?
If you want to change these properties in a production application with out redeployment your out of luck. Your only option is using external properties files which will require a rebuild and redeployment of the app. See the following link. http://www.comitservices.com/wp/?p=133
How do I create a grails war file so that it doesn't have the version number
(e.g. foo-0.1.war)
attached to the end when I execute the 'grails war' command?
In case anybody comes upon this article and is using Grails 1.3.x, the configuration option has changed from grails.war.destFile in Config.groovy to being grails.project.war.file in BuildConfig.groovy.
Also the file name is relative to the project workspace, so it should have a value like:
grails.project.war.file = "target/${appName}.war"
This is according to the latest Grails documentation.
I think you can specify the war name in the war command.
grails war foo.war
Also check the latest Grails documentation for where to set this as a configuration option. See the other answers for details.
From the Grails Documentation, Chapter 17, Deployment
There are also many ways in which you can customise the WAR file that is
created. For example, you can specify
a path (either absolute or relative)
to the command that instructs it where
to place the file and what name to
give it:
grails war /opt/java/tomcat-5.5.24/foobar.war
Alternatively, you can add a line to
Config.groovy that changes the default
location and filename:
grails.war.destFile = "foobar-prod.war"
Of course, any command line argument
that you provide overrides this
setting.
Rolling up the other excellent answers. There are several options:
Explicitly set it on the command line: grails war foo.war
Set the app.version property to empty in application.properties will cause the war to be named foo.war.
Explicitly set the name of the war using the grails.war.destFile property in Config.groovy
Grails 3.x has switched to gradle and uses the war plugin. You can just specify name like this in the build.gradle file:
war {
archiveName 'foo.war'
}
Another way to generate war files without version number is to keep the property, app.version, empty in the application.properties
I am kind of late to the party... but anyway:
I think the reason behind removing the version number is to eliminate the need to rename the war file so it deploys on "correct" context path /appName. If that's the case then a better option is to use a versioned war filename so you can deploy multiple versions at the same time on tomcat using the following naming pattern in grails-app/conf/BuildConfig.groovy:
grails.project.war.file = "target/${appName}##${appVersion}.war"
As explained in http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Parallel_deployment
This method applies to wars in general, not only grails' wars.