DDevelopment & Design

Grails session timeout without XML

This article shows clean, non hacky way of configuring featureful event listeners for Grails application servlet context. Feat. HttpSessionListener as a Spring bean example with session timeout depending on whether user account is premium or not. Common approaches Speaking of session timeout config in Grails, a default approach is to install templates with a command. This way we got direct access to web.xml file. Also more unnecessary files are created. Despite that unnecessary files are unnecessary, we should also remember some other common knowledge: XML is not for humans. Another, a bit more hacky, way is to create mysterious scripts/_Events.groovy file. Inside of which, by using not less enigmatic closure: eventWebXmlEnd = { filename -> … }, we can parse and hack into web.xml with a help of XmlSlurper. Even though lot of Grails plugins do it similar way, still it’s not really straightforward, is it? Besides, where’s the IDE support? Hello!? Examples of both above ways can be seen on StackOverflow. Simpler and cleaner way By adding just a single line to the already generated init closure we have it done: class BootStrap { def init = { servletContext -> servletContext.addListener(OurListenerClass) } } Allrighty, this is enough to avoid XML. Sweets are served after the main course though :) Listener as a Spring bean Let us assume we have a requirement. Set a longer session timeout for premium user account. Users are authenticated upon session creation through SSO. To easy meet the requirements just instantiate the CustomTimeoutSessionListener as Spring bean at resources.groovy. We also going to need some source of the user custom session timeout. Let say a ConfigService. beans = { customTimeoutSessionListener(CustomTimeoutSessionListener) { configService = ref('configService') } } With such approach BootStrap.groovy has to by slightly modified. To keep control on listener instantation, instead of passing listener class type, Spring bean is injected by Grails and the instance passed: class BootStrap { def customTimeoutSessionListener def init = { servletContext -> servletContext.addListener(customTimeoutSessionListener) } } An example CustomTimeoutSessionListener implementation can look like: import javax.servlet.http.HttpSessionEvent import javax.servlet.http.HttpSessionListener import your.app.ConfigService class CustomTimeoutSessionListener implements HttpSessionListener { ConfigService configService @Override void sessionCreated(HttpSessionEvent httpSessionEvent) { httpSessionEvent.session.maxInactiveInterval = configService.sessionTimeoutSeconds } @Override void sessionDestroyed(HttpSessionEvent httpSessionEvent) { /* nothing to implement */ } } Having at hand all power of the Spring IoC this is surely a good place to load some persisted user’s account stuff into the session or to notify any other adequate bean about user presence. Wait, what about the user context? Honest answer is: that depends on your case. Yet here’s an example of getSessionTimeoutMinutes() implementation using Spring Security: import org.springframework.security.core.context.SecurityContextHolder class ConfigService { static final int 3H = 3 * 60 * 60 static final int QUARTER = 15 * 60 int getSessionTimeoutSeconds() { String username = SecurityContextHolder.context?.authentication?.principal def account = Account.findByUsername(username) return account?.premium ? 3H : QUARTER } } This example is simplified. Does not contain much of defensive programming. Just an assumption that principal is already set and is a String – unique username. Thanks to Grails convention our ConfigService is transactional so the Account domain class can use GORM dynamic finder. OK, config fetching implementation details are out of scope here anyway. You can get, load, fetch, obtain from wherever you like to. Domain persistence, principal object, role config, external file and so on… Any gotchas? There is one. When running grails test command, servletContext comes as some mocked class instance without addListener method. Thus we going to have a MissingMethodException when running tests :( Solution is typical: def init = { servletContext -> if (Environment.current != Environment.TEST) { servletContext.addListener(customTimeoutSessionListener) } } An unnecessary obstacle if you ask me. Should I submit a Jira issue about that? TL;DR Just implement a HttpSessionListener. Create a Spring bean of the listener. Inject it into BootStrap.groovy and call servletContext.addListener(injectedListener).

This article shows clean, non hacky way of configuring featureful event listeners for Grails application servlet context. Feat. HttpSessionListener as a Spring bean example with session timeout depending on whether user account is premium or not.

Common approaches

Speaking of session timeout config in Grails, a default approach is to install templates with a command. This way we got direct access to web.xml file. Also more unnecessary files are created. Despite that unnecessary files are unnecessary, we should also remember some other common knowledge: XML is not for humans.

Another, a bit more hacky, way is to create mysterious scripts/_Events.groovy file. Inside of which, by using not less enigmatic closure: eventWebXmlEnd = { filename -> … }, we can parse and hack into web.xml with a help of XmlSlurper.
Even though lot of Grails plugins do it similar way, still it’s not really straightforward, is it? Besides, where’s the IDE support? Hello!?

Examples of both above ways can be seen on StackOverflow.

Simpler and cleaner way

By adding just a single line to the already generated init closure we have it done:

class BootStrap {
    def init = {
        servletContext ->
        servletContext.addListener(OurListenerClass)
    }
}

Allrighty, this is enough to avoid XML. Sweets are served after the main course though :)

Listener as a Spring bean

Let us assume we have a requirement. Set a longer session timeout for premium user account.
Users are authenticated upon session creation through SSO.

To easy meet the requirements just instantiate the CustomTimeoutSessionListener as Spring bean at resources.groovy. We also going to need some source of the user custom session timeout. Let say a ConfigService.

beans = {
    customTimeoutSessionListener(CustomTimeoutSessionListener) {
        configService = ref('configService')
    }
}

With such approach BootStrap.groovy has to by slightly modified. To keep control on listener instantation, instead of passing listener class type, Spring bean is injected by Grails and the instance passed:

class BootStrap {
    def customTimeoutSessionListener
    def init = {
        servletContext ->
        servletContext.addListener(customTimeoutSessionListener)
    }
}

An example CustomTimeoutSessionListener implementation can look like:

import javax.servlet.http.HttpSessionEvent
import javax.servlet.http.HttpSessionListener
import your.app.ConfigService

class CustomTimeoutSessionListener implements HttpSessionListener {
    ConfigService configService
    @Override
    void sessionCreated(HttpSessionEvent httpSessionEvent) {
        httpSessionEvent.session.maxInactiveInterval = configService.sessionTimeoutSeconds
    }
    @Override
    void sessionDestroyed(HttpSessionEvent httpSessionEvent) {
        /* nothing to implement */ }
}

Having at hand all power of the Spring IoC this is surely a good place to load some persisted user’s account stuff into the session or to notify any other adequate bean about user presence.

Wait, what about the user context?

Honest answer is: that depends on your case. Yet here’s an example of getSessionTimeoutMinutes() implementation using Spring Security:

import org.springframework.security.core.context.SecurityContextHolder

class ConfigService {
    static final int 3 H = 3 * 60 * 60
    static final int QUARTER = 15 * 60
    int getSessionTimeoutSeconds() {
        String username = SecurityContextHolder.context?.authentication?.principal
        def account = Account.findByUsername(username)
        return account?.premium ? 3 H : QUARTER
    }
}

 

This example is simplified. Does not contain much of defensive programming. Just an assumption that principal is already set and is a String – unique username. Thanks to Grails convention our ConfigService is transactional so the Account domain class can use GORM dynamic finder.
OK, config fetching implementation details are out of scope here anyway. You can get, load, fetch, obtain from wherever you like to. Domain persistence, principal object, role config, external file and so on…

Any gotchas?

There is one. When running grails test command, servletContext comes as some mocked class instance without addListener method. Thus we going to have a MissingMethodException when running tests :(

Solution is typical:

def init = {
    servletContext ->
    if (Environment.current != Environment.TEST) {
        servletContext.addListener(customTimeoutSessionListener)
    }
}

An unnecessary obstacle if you ask me. Should I submit a Jira issue about that?

TL;DR

Just implement a HttpSessionListener. Create a Spring bean of the listener. Inject it into BootStrap.groovy and call servletContext.addListener(injectedListener).

— Previous article

SortedSet + Joda DateTime == danger

Next article —

Vert.x on Raspberry Pi

You May Also Like
DDevelopment & Design

Simple trick to DRY your Grails controller

Grails controllers are not very DRY. It's easy to find duplicated code fragments in default generated controller. Take a look at code sample below. It is duplicated four times in show, edit, update and delete actions:

class BookController {
def show() {
def bookInstance = Book.get(params.id)
if (!bookInstance) {
flash.message = message(code: 'default.not.found.message', args: [message(code: 'book.label', default: 'Book'), params.id])
redirect(action: "list")
return
        }
        [bookInstance: bookInstance]
    }
}

Why is it duplicated?

There is a reason for that duplication, though. If you move this snippet to a method, it can redirect to "list" action, but it can't prevent controller from further execution. After you call redirect, response status changes to 302, but after method exits, controller still runs subsequent code.

Solution

At TouK we've implemented a simple trick to resolve that situation:

  1. wrap everything with a simple withStoppingOnRender method,
  2. whenever you want to render or redirect AND stop controller execution - throw EndRenderingException.

We call it Big Return - return from a method and return from a controller at once. Here is how it works:

class BookController {
def show(Long id) {
withStoppingOnRender {
Book bookInstance = Book.get(id)
validateInstanceExists(bookInstance)
            [bookInstance: bookInstance]
        }
    }

protected Object withStoppingOnRender(Closure closure) {
try {
return closure.call()
        } catch (EndRenderingException e) {}
    }

private void validateInstanceExists(Book instance) {
if (!instance) {
flash.message = message(code: 'default.not.found.message', args: [message(code: 'book.label', default: 'Book'), params.id])
redirect(action: "list")
throw new EndRenderingException()
        }
    }
}

class EndRenderingException extends RuntimeException {}

Example usage

For simple CRUD controllers, you can use this solution and create some BaseController class for your controllers. We use withStoppingOnRender in every controller so code doesn't look like a spaghetti, we follow DRY principle and code is self-documented. Win-win-win! Here is a more complex example:

class DealerController {
@Transactional
def update() {
withStoppingOnRender {
Dealer dealerInstance = Dealer.get(params.id)
validateInstanceExists(dealerInstance)
validateAccountInExternalService(dealerInstance)
checkIfInstanceWasConcurrentlyModified(dealerInstance, params.version)
            dealerInstance.properties = params
saveUpdatedInstance(dealerInstance)
redirectToAfterUpdate(dealerInstance)
        }
    }
}
DDevelopment & Design

4Developers 2010 Review

I've been to 4Developers in 2009 in Cracow, together with Tomasz Przybysz and we had very nice impressions, no wonder then I wanted to signed up for 2010 edition in Poznań as well. Tomasz was sick, but Jakub Kurlenda decided to come with me. This time...I've been to 4Developers in 2009 in Cracow, together with Tomasz Przybysz and we had very nice impressions, no wonder then I wanted to signed up for 2010 edition in Poznań as well. Tomasz was sick, but Jakub Kurlenda decided to come with me. This time...
DDevelopment & Design

Inconsistent Dependency Injection to domains with Grails

I've encountered strange behavior with a domain class in my project: services that should be injected were null. I've became suspicious as why is that? Services are injected properly in other domain classes so why this one is different?

Constructors experiment

I've created an experiment. I've created empty LibraryService that should be injected and Book domain class like this:

class Book {
    def libraryService

    String author
    String title
    int pageCount

    Book() {
        println("Finished constructor Book()")
    }

    Book(String author) {
        this()
        this.@author = author
        println("Finished constructor Book(String author)")
    }

    Book(String author, String title) {
        super()
        this.@author = author
        this.@title = title
        println("Finished constructor Book(String author, String title)")
    }

    Book(String author, String title, int pageCount) {
        this.@author = author
        this.@title = title
        this.@pageCount = pageCount
        println("Finished constructor Book(String author, String title, int pageCount)")
    }

    void logInjectedService() {
        println("    Service libraryService is injected? -> $libraryService")
    }
}
class LibraryService {
    def serviceMethod() {
    }
}

Book has 4 explicit constructors. I want to check which constructor is injecting dependecies. This is my method that constructs Book objects and I called it in controller: 

class BookController {
    def index() {
        constructAndExamineBooks()
    }

    static constructAndExamineBooks() {
        println("Started constructAndExamineBooks")
        Book book1 = new Book().logInjectedService()
        Book book2 = new Book("foo").logInjectedService()
        Book book3 = new Book("foo", 'bar').logInjectedService()
        Book book4 = new Book("foo", 'bar', 100).logInjectedService()
        Book book5 = new Book(author: "foo", title: 'bar')
        println("Finished constructor Book(Map params)")
        book5.logInjectedService()
    }
}

Analysis

Output looks like this:

Started constructAndExamineBooks
Finished constructor Book()
    Service libraryService is injected? -> eu.spoonman.refaktor.LibraryService@2affcce2
Finished constructor Book()
Finished constructor Book(String author)
    Service libraryService is injected? -> eu.spoonman.refaktor.LibraryService@2affcce2
Finished constructor Book(String author, String title)
    Service libraryService is injected? -> null
Finished constructor Book(String author, String title, int pageCount)
    Service libraryService is injected? -> null
Finished constructor Book()
Finished constructor Book(Map params)
    Service libraryService is injected? -> eu.spoonman.refaktor.LibraryService@2affcce2

What do we see?

  1. ✔

    Empty constructor injects dependencies.

  2. ✔

    Constructor that invokes empty constructor explicitly injects dependencies.

  3. ✘

    Constructor that invokes parent's constructor explicitly does not inject dependencies.

  4. ✘

    Constructor without any explicit call declared does not call empty constructor thus it does not inject dependencies.

  5. ✔

    Constructor provied by Grails with a map as a parameter invokes empty constructor and injects dependencies.

Conclusion

Always explicitily invoke empty constructor in your Grail domain classes to ensure Dependency Injection! I didn't know until today either!