Grails

Support for different BootStrap environments (as with Dev/Test/Prod DataSources)

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: 0.2.2
  • Fix Version/s: 1.2-M4
  • Component/s: Configuration
  • Labels:
    None

Description

3 Datasources for prod/test/dev are created automatically by Grails if a new applciation is created.

Unfortunately, there is just one ApplicationBootstrap class. I (probably others) use the bootstrap to create a certain state in the db for my production/test environment, e.g. deleting all tables, then creating new rows, etc. The bootstrap for production needs to be different, of course.

The proposal is to have at least 3 BootStraps that are chosen based on the environment in:

From Guillaume:

What about some convention in the naming of the bootstrap classes?
DevEnvBootstrap, ProdEnvBootstrap, *EnvBootstrap ?

Cheers\
Sven

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Marc Palmer added a comment -

Rolling over to 0.5.5 reduce workload for 0.5 pre JavaOne

Show
Marc Palmer added a comment - Rolling over to 0.5.5 reduce workload for 0.5 pre JavaOne
Hide
Permalink
James Page added a comment -

It would be good to be able to have more than just three setups... My problem is that I am writing on Windows for Linux and I need to configure different paths for the different os's.

Also I am using Google Maps which requires a new key for each machine.

Somehow I would love a kind of inheritance model. Where the child would override the parent.

Lets say my development machine is called duck, and my production machine is called Server123. If I was booting up grails on my development machine the bootstrap would first load
#duckBootstrap.groovy
#DevlopmentBootstrap.groovy
#Bootstrap.groovy

If it was on the production server then it would bootstrap
#Server123Bootstrap.groovy
#ProductionBootstrap.groovy
#Bootstrap.groovy

If was to boot up on any other environment where there was no configuration for that machine then it would just load Bootstrap.groovy.

PS: I don't like the idea of DevEnvBootstrap as a naming convention because we are swapping names around already from dev to development in grails.env

Show
James Page added a comment - It would be good to be able to have more than just three setups... My problem is that I am writing on Windows for Linux and I need to configure different paths for the different os's. Also I am using Google Maps which requires a new key for each machine. Somehow I would love a kind of inheritance model. Where the child would override the parent. Lets say my development machine is called duck, and my production machine is called Server123. If I was booting up grails on my development machine the bootstrap would first load #duckBootstrap.groovy #DevlopmentBootstrap.groovy #Bootstrap.groovy If it was on the production server then it would bootstrap #Server123Bootstrap.groovy #ProductionBootstrap.groovy #Bootstrap.groovy If was to boot up on any other environment where there was no configuration for that machine then it would just load Bootstrap.groovy. PS: I don't like the idea of DevEnvBootstrap as a naming convention because we are swapping names around already from dev to development in grails.env
Hide
Permalink
Pam added a comment -

I was just looking for how to do this... I have different databases for dev, test & prod and the dataset I need to test some of the functions is rather large, so I don't want to start over from scratch every time...

Show
Pam added a comment - I was just looking for how to do this... I have different databases for dev, test & prod and the dataset I need to test some of the functions is rather large, so I don't want to start over from scratch every time...
Hide
Permalink
Graeme Rocher added a comment -

Moving non-critical issues that aren't going to make it into 1.1 to 1.2

Show
Graeme Rocher added a comment - Moving non-critical issues that aren't going to make it into 1.1 to 1.2
Hide
Permalink
Graeme Rocher added a comment -

Enough votes to make a blocker

Show
Graeme Rocher added a comment - Enough votes to make a blocker
Hide
Permalink
Graeme Rocher added a comment -

Now possible with:

def init = { ServletContext ctx ->
        environments {
            production {
                ctx.setAttribute("env", "prod")
            }
            development {
                ctx.setAttribute("env", "dev")
            }
        }
        ctx.setAttribute("foo", "bar")
    }
Show
Graeme Rocher added a comment - Now possible with: 
def init = { ServletContext ctx ->
        environments {
            production {
                ctx.setAttribute("env", "prod")
            }
            development {
                ctx.setAttribute("env", "dev")
            }
        }
        ctx.setAttribute("foo", "bar")
    }

People

Vote (22)
Watch (12)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.1#660-r161644) | Report a problem
Powered by a free Atlassian JIRA open source license for Grails project. Try JIRA - bug tracking software for your team.