Grails allows you to define different "environments" for your app inside Config.groovy like so:
environments {
development {
...
}
demo {
...
}
production {
...
}
}
Thus you can run your app like so:
grails -Dgrails.env=demo run-app
...and Grails will run your app in "demo" environment mode. The default is development, so if you just execute:
grails run-app
...it's the same as:
grails -Dgrails.env=development run-app
However I was wondering if it is possible (and if so, how) to override development as the default and make it, say, demo? Such that:
grails run-app
...is equivalent to:
grails -Dgrails.env=demo run-app
Thoughts?
However I was wondering if it is possible (and if so, how) to override development as the default
No, this is not possible. Incidentally, the default environment depends on the command, e.g.
the default environment for run-app is development
the default environment for test-app is test
the default environment for war is production
The short answer is no (or at least it is not documented and I wasn't able to make it work), but the slightly longer answer is that even if you could you probably don't want to.
By changing the default environment you'll create an additional barrier to entry for new developers and are likely to have quite a few "oh damn, it doesn't run in dev by default, of course" moments.
It's also worth noting that while the development is the default for run-app, test-app defaults to test and war defaults to production.
The development environment is just a label, so if you really wanted to use it for something else (such as demos), you could just create a separate actualDev environment, but again it's likely to cause confusion in the distant future when everyone's forgotten it's set up like that.
Okay, but what can I do to make demos easier?
I've always made use of the /scripts/ directory in the standard Grails structure to ease setup and demo overheads, so you could create demo.sh for demos, which would also let you setup/teardown any other resources if/when your application becomes more complex and interconnected.
Related
Can someone explain to me what the Rails environments are and what they do? I have tried researching myself, but could not find anything. From what I gather, the environments are:
Development
Productions
Test
Each "environment" is really just a config. You can launch your app in various different modes, and the modes are called "environments" because they affect the app's behaviour in lots of different ways. Ultimately, though, they are just configs.
BTW you can't have looked very hard when you looked "everywhere", because i just googled "rails environment" and the top result was this
http://guides.rubyonrails.org/configuring.html
which is the official explanation of configuring the rails environment.
From what you have provided in your question, it seems that you are asking:
"What are the difference between each environment configuration in Rails?"
Rails comes packages with 3 types of environments. Each have its own server, database, and configuration. See Rails Guides: Configuration for more information on options available to you.
Setting up the environment
To set your Rails environment, you will want to enter in command line:
export RAILS_ENV=<env>
Where <env> can be test, development, or production. Setting this environment variable is crucial, as it will determine what gems are installed, or what env is touched when running rails console or rails server.
Included in configuration is the gemset used for the app. When you run rails new, you will find a Gemfile with groups test, development, and production. These groups correspond to the environment currently set. When the environment is set to one of those, running bundle install installs all gems related to that group (and gems not listed in a group).
Included environments
test is designed for running tests/specs. This database will likely be bare bones, except for seeds you may call before running the suite. After each test is complete, the database will rollback to its state before the test began. I do not recommend launching rails server, as running tests (via MiniTest or RSpec) will do this for you, and close the server once the suite is finished.
development allows you to "test" your app with a larger database, typically a clone of production. This allows you to test actual real-world data without breaking production (the version that customers or end-users will experience). To view the development environment in action, change the RAILS_ENV and launch rails server. This is good for deciding how you want your pages to look (CSS, HTML). It is also good practice to briefly "test" your app yourself, clicking around making sure everything "looks" good and the JavaScript works.
production is reserved for the customer and end-user. Configuration includes the actual domain of the app, which ports to use, and initializers or tasks to run. You do not want to play around with your database, as it may be customer-impacting. Ideally, the app should work as best as it can, since this is considered your "final product."
Here are some good reads about Rails Environments
http://teotti.com/use-of-rails-environments/
and
https://signalvnoise.com/posts/3535-beyond-the-default-rails-environments
good luck !!
We are running our grails probject with run-app. The first time a page is requested, there is a delay. Every time after that, however, the page loads quickly.
The most obvious explanation I can think of is that the page hasn't been compiled yet. Is there a way to induce compilation or whatever else is causing the delay?
I hope you are only using "run-app" in development and not in production.
If you want to pre-compile the GSPs then use "run-war".
Be aware though, changes to the GSP will not be detected and you will have to restart the application or make changes to your configuration to enable dynamic recompile.
To enable dynamic recompile of GSPs when running as a WAR modify your Config.groovy with the following:
grails.gsp.enable.reload = true
grails.gsp.view.dir = "/path/to/WEB-INF/"
I can't stress enough, if this isn't in development, and instead is production, deploy your application as a WAR file.
I am using Grails 2.3.5 with database migration plugin in new project for understand how it is working. But sometimes dbm-gorm-diff provide empty changelog file,even changes is there.
For example,
i have the person domain class with out any properties.
When initially creating change log, it will create 2 fields id and version in change log.
After that, added 2fields name,age into that person class. then did dbm-update and dbm-gorm-diff that give like following.
databaseChangeLog = {
}
Sometimes gives the changes. some times is not working. Please help me. Why it is working like that. Sorry for bad english.
Using the following tutorial works for me. Make sure you remove dbCreate from your DataSource.groovy. According to the tutorial the workflow is as follows:
Setup
Remove dbCreate from DataSource.groovy
Initially run grails dbm-generate-gorm-changelog changelog.groovy
Sync the changelog with your db by running grails dbm-changelog-sync
Changing domain
Change domain class
Run grails dbm-gorm-diff <your-filename>.groovy --add
Run grails dbm-changelog-sync
Hope this helps
I have spent some time searching for the answer to this same issue.
Caveat: I am using the Grails interactive shell to issue commands, including the dbm-* commands.
By brute force alone, I have come to the conclusion that the domain classes are not reliably reloading. To get consistent results (especially with the generation of new changeLog files), any time I modify a domain class, I stop and restart the Grails interactive shell before calling dbm-gorm-diff. I've tried issuing other commands like clean, compile, package and refresh-dependencies and they just aren't working, and the -reloading flag at the start up of the Grails interactive shell doesn't seem to make any difference either.
Restarting the Grails interactive shell, however, does seem to work reliably, thought it galls me to do so :)
Those who do not use the interactive shell should not be having this problem since the domain classes are loaded with every command call.
This blog has detailed step by step explanation, specially Migrating old databases section helped us in migrating successfully.
I have been developing several Grails applications over the past couple of years. I am increasingly finding that the three grails environments (dev, test, prod) aren't enough to satisfy my needs. The more "enterprisey" your application gets, the more environments you tend to have.
I tend to use 6 environments for my development cycle...
DEVA //My dev
DEVB //Team mates dev
CI_TEST //CI like Hudson
QA_TEST //Testing team environment
UAT_TEST //Customers testing environment
PROD //Production
Im wondering if there is a way to define custom Grails environments? I dont think there is, but the feature could be handy.
The way I am getting around this right now is by externalising the config to a properties file.
Id imagine that this is a pretty common requirement, so how have you been dealing with your environments?
Config.groovy and DataSource.groovy both support custom environments (I'm pretty sure most other config files do as well).
If you want to start up your app or package it for a custom env you use
grails -Dgrails.env=myCustomEnv run-app
Then in Config you would have
environments{
myCustomEnv{
myProp = 'myVal'
}
}
I couldn't find a page in the user guide about it but we use them like this to have beta and uat environment settings.
One option could be to define a dataSource in DataSource.groovy for each of your environments and then store configuration information in the database.
You could then add code in BootStrap.groovy to load your configurations.
I posted this very same item on SERVERFAULT, but got no reply. So here goes:
I'm currently in the process of finishing up a Rails application. I am using Warbler to package it up as a ".war" file and am using GlassFish to deploy it. I do this because the application is to be distributed to companies for in-house use. Arguably i could/should have used another framework to develop an application of this nature, however, I chose ease/speed of development over deployment hassle.
That said, I've got the setup working reasonably well on my development machine. However, I'm curious as to how to go about automating environment initialization. In other words, I need to figure out how to ensure that all DBs, files,etc. are configured upon deployment.
All of the examples I've seen thus far assume you're running your IDE on the system to which you wish to deploy and they have you run your rake tasks manually before deployment. However I need to simply give the end user the ".war" and be able to run all rake tasks upon application deployment/launch.
Can someone point me in the right direction regarding this? FWIW there is nothing in the Glassfish manual about environment initialization etc. -- then again, I don't suppose I should expect them to cover every single aspect of deployment.
Best.
Depending on your database requirements you can embed Derby within the Glassfish environment. You can easily create a blank/default database and then put that clean version in each Glassfish environment you have to set up.
I'm not sure what else you need to configure and initialize, but I'd say that if you can, script it up, either with some rake tasks. Embedding Derby takes care of database startup and initialization. Remember that a war file is just a zip file, so adding config files via a script shouldn't be so hard. You can use rails initializers (/config/initializers/) to load up yml files for configuration or whatever you need to do as the app starts up.
You won't be able to have the intializers create the schema in the database, but you could have them check for default seed data and put it in if it isn't there.
You should be able to access any part of the file system that Glassfish and the JVM can access. I don't know much about Glassfish but the only problems I've had with jruby rails apps on Tomcat were related to relative paths being relative to where the startup script was called from, and not always relative to the installation root. This could probably be solved with the right startup scripts in Tomcat or setting the appropriate start-in folder, I just haven't had a need to dive in to that very much.