1.0.1 release

src/docs/guide/1.1 History.gdoc

@@ -1,4 +1,7 @@
 h4. History
 
+* February 22, 2012
+** 1.0.1 release
+*** Added dependency on database-session plugin
 * December 15, 2011
 ** Initial 1.0 release

src/docs/guide/2 Usage.gdoc

@@ -26,19 +26,38 @@ The general steps for creating a Grails application are (not necessarily in orde
 
 See the tutorial in the next section for a detailed walkthrough of the required and optional steps.
 
-h4. Using the Spring Security Core plugin
+h4. Session management
+
+As of this writing, there's no support at Heroku for session affinity or clustered sessions. So if you run more than one instance of your application, clients will connect to different instances for different requests. This will result in a different session on each server and will break any feature that depends on a consistent session. This includes flash scope and request chaining, but also security implementations such as Spring Security that keep your authentication information in the session; after successfully authenticating you're likely to end up on an instance that doesn't have the authentication information in its session and you'll appear to not be logged in. Even if this doesn't happen immediately, at some point you're likely to land on another instance and have to log in again.
+
+To work around this the plugin depends on the [database-session|http://grails.org/plugin/database-session] plugin. This plugin stores session data in the database and trades having a single shared session across all instances for a (hopefully) small increase in database access. The plugin is new and hasn't been extensively tested, so make sure it works for your use cases before using it in an important application. If you choose to not use the database-session plugin you can either disable it by adding
+
+{code}
+grails.plugin.databasesession.enabled = false
+{code}
+
+to Config.groovy, or not install it by excluding it in BuildConfig.groovy:
 
-There are a few things to be aware of when using the spring-security-core plugin with Heroku. One is that as of this writing, there's no support at Heroku for session affinity or clustered sessions. So if you run more than one instance of your application, your authentications will tend to fail since after successfully authenticating you will most likely be redirected to another instance with a new HTTP session without the authentication. Even if this doesn't happen immediately, at some point you're likely to land on another instance and have to log in again. One option you can use to get around this limitation is to use the [database-session|http://grails.org/plugin/database-session] plugin. This stores session data in the database and trades having a single shared session across all instances for a (hopefully) small increase in database access. The plugin is new and hasn't been extensively tested, so make sure it works for your use cases before using it in an important application.
+{code}
+plugins {
+   ...
+   compile(':heroku:1.0.1') {
+      exclude 'database-session'
+   }
+}
+{code}
+
+h4. Using the Spring Security Core plugin
 
-Another is a more general problem with plugin dependencies that affects the spring-security-core plugin in Grails 2.0 applications. Due to changes in plugin resolution for 2.0, when the war is built the installed plugins' dependent plugins won't be resolved. So the webxml plugin that the spring-security-core plugin depends on won't be resolved and you'll see IllegalStateExceptions for all requests. This is the same issue that requires that you explicitly declare a dependency on the cloud-support plugin (see the tutorials for examples of this). The workaround is simple; just declare an explicit dependency for all plugins that would otherwise be transitively installed, e.g.
+There are a few things to be aware of when using the spring-security-core plugin with Heroku. One is the session management issue described above. Another is a more general problem with plugin dependencies that affects the spring-security-core plugin in Grails 2.0 applications. Due to changes in plugin resolution for 2.0, when the war is built the installed plugins' dependent plugins won't be resolved. So the webxml plugin that the spring-security-core plugin depends on won't be resolved and you'll see IllegalStateExceptions for all requests. This is the same issue that requires that you explicitly declare a dependency on the cloud-support plugin (see the tutorials for examples of this). The workaround is simple; just declare an explicit dependency for all plugins that would otherwise be transitively installed, e.g.
 
 {code}
 plugins {
    ...
 
    compile ':spring-security-core:1.2.7.2'
    compile ':webxml:1.4.1'
-   compile ':heroku:1.0'
+   compile ':heroku:1.0.1'
    compile ':cloud-support:1.0.8'
 }
 {code}

src/docs/guide/3.1 Basic Tutorial.gdoc

@@ -15,7 +15,7 @@ Register a dependency on the plugin (and also on the cloud-support plugin to be
 
 {code}
 plugins {
-   compile ':heroku:1.0'
+   compile ':heroku:1.0.1'
    compile ':cloud-support:1.0.8'
 }
 {code}

src/docs/guide/3.2 Advanced Tutorial.gdoc

@@ -15,7 +15,7 @@ Register a dependency on the plugin (and also on the cloud-support plugin to be
 
 {code}
 plugins {
-   compile ':heroku:1.0'
+   compile ':heroku:1.0.1'
    compile ':cloud-support:1.0.8'
 }
 {code}

src/docs/guide/3.2.7 Tying it all together.gdoc

@@ -29,7 +29,7 @@ Optionally install the [console|http://grails.org/plugin/console] plugin to prov
 {code}
 plugins {
    ...
-   compile ':console:1.0.1'
+   compile ':console:1.1'
 }
 {code}
 

src/docs/guide/4 Troubleshooting.gdoc

@@ -21,7 +21,7 @@ Add a reference to the console plugin in @BuildConfig.groovy@:
 {code}
 plugins {
    ...
-   compile ':console:1.0.1'
+   compile ':console:1.1'
 }
 {code}