Converting Http Session Events into Grails 3 Events

October 19, 2015 1:16 pm

Grails 3 introduced a new Events API based on Reactor.  Unfortunately, as far as I can tell, HttpSessionEvents are not natively part of the Grails 3 Events system.  Bringing them in to the fold, however, is pretty easy.  I based this off of Oliver Wahlen’s immensely helpful blog post about sending the HttpSessionEvents to a Grails service.

First, let’s create our Spring HttpSessionServletListener.  Create this file somewhere in the /src/ path where Grails will find it:

File: .../grailsProject/src/main/groovy/com/example/HttpSessionServletListener.groovy
package com.example

import grails.events.*
import javax.servlet.http.HttpSession
import javax.servlet.http.HttpSessionEvent
import javax.servlet.http.HttpSessionListener

class HttpSessionServletListener implements HttpSessionListener, Events {
  
    // called by servlet container upon session creation
    void sessionCreated(HttpSessionEvent event) {
        notify("example:httpSessionCreated", event.session)
    }

    // called by servlet container upon session destruction
    void sessionDestroyed(HttpSessionEvent event) {
        notify("example:httpSessionDestroyed", event.session)
    }
}

Now register the HttpSessionServletListener as a Spring Bean.  If you don’t already have a resources.groovy file, create one and add the following.

.../grailsProject/grails-app/conf/spring/resources.groovy
import org.springframework.boot.context.embedded.ServletListenerRegistrationBean
import com.example.HttpSessionServletListener

beans = {
    
    httpSessionServletListener(ServletListenerRegistrationBean) {
        listener = bean(HttpSessionServletListener)
    }
    
}
// Yes this is the entire file

Now you are all set to listen for the “example:httpSessionCreated” and “example:httpSessionDestroyed” events using the Grails 3 Events API.  “Example” is the namespace of the event, which in my real code I set to the last part of the package name, so I made it match the package name of “example”.  Just use something so you don’t have to worry about naming collisions.

Here’s an example of listening for the events in a standard Grails Controller.  Note that the event handlers are attached after construction, and before the Controller bean is made available, by using the PostConstruct annotation.

.../grailsProject/grails-app/controllers/com/example/ExampleController.groovy
package com.example

import grails.events.*
import javax.annotation.PostConstruct

class ExampleController {
    
    @PostConstruct
    void init() {
        
        on("example:httpSessionCreated") { session ->
            println "sessionCreated: ${session.id}"
        }
        
        on("example:httpSessionDestroyed") { session ->
            println "sessionDestroyed: ${session.id}"
        }
    }
}

Criteria Aggregator: Dynamic Criteria Queries in Grails

February 5, 2014 2:42 pm

A few years ago I wrote about dynamically building criteria queries in Grails.  Well the use case we had disappeared and I didn’t do much of anything with dynamic criteria queries until recently.  As I’ve mentioned in an update on that post, you probably just want to use DetachedCriteria now instead of taking this route, but DetachedCriteria don’t support the same range of functionality that normal criteria queries do.

I ran into this limitation when I needed to use subqueries which DetachedCriteria do not support but standard criteria queries do.  After spending hours trying to work around the limitation and still use DetachedCriteria I decided to give up and create a nice way of using the dynamic criteria queries based on my past experience, the comments on that post, and my greatly enlarged knowledge of Grails.

So I created a nice clean class called “CriteriaAggregator”:

package org.example.package
import grails.orm.HibernateCriteriaBuilder

// Aggregate query criteria for a Domain Class
// Example: def qa = new CriteriaAggregator(MyDomainClass)
//    qa.addCriteria { idEq(12345L) }
//     def results = qa.get()
public class CriteriaAggregator {
    private Class forClass
    private List<Closure> criteriaClosures

    // forClass should be a Grails DomainClass; but since Grails injects rather than inherits I can't specify the type better than "Class"
    public CriteriaAggregator(Class forClass) {this.forClass = forClass; criteriaClosures = new ArrayList<Closure>(10)}

    // criteriaClosure is the exact same type of closure you'd pass to DomainClass.withCriteria(criteriaClosure)
    public void addCriteria(Closure criteriaClosure) {criteriaClosures << criteriaClosure}

    public long count() {return runQuery('get') {projections {rowCount()}}}
    public def get(Closure additionalCriteria=null) {return runQuery('get', additionalCriteria)} // Query must return only a single row
    public def list(Closure additionalCriteria=null) {return runQuery('list', additionalCriteria)}

    private def runQuery(String method, Closure additionalCriteria=null) {
        HibernateCriteriaBuilder criteriaBuilder = forClass.createCriteria()
        def critClosures = criteriaClosures // Bizarre that criteriaClosures won't evaluate properly inside the "$method" closure, but it won't so this works around that issue
        criteriaBuilder."$method" {
            critClosures.each{closure -> closure.delegate = criteriaBuilder; closure()}
            if (additionalCriteria) {additionalCriteria.delegate = criteriaBuilder; additionalCriteria()}
        }
    }
}

This wraps and defers the creation of the normal criteria builder allowing you to build up the criteria dynamically and execute it when desired.

Suppose you had a Customer domain class with many Orders.  Orders have a date, paymentMethod, and totalPrice.

def customerQueryAggregator = new CriteriaAggregator(Customer)
customerQueryAggregator.addCriteria {
  orders {
    def now = new Date()
    between('date', now-7, now)
  }
}
customerQueryAggregator.addCriteria {
  orders {
    eq('paymentMethod', 'cash')
  }
}

def numCustomersInPastWeekPayingCash = customerQueryAggregator.count()
println numCustomersInPastWeekPayingCash

def highRollersInPastWeek = customerQueryAggregator.list{
  orders {
    gt('totalPrice', 50000)
  }
}
println highRollersInPastWeek

This is obviously a trivial example where you don’t need to use the aggregator.  But it’s just to illustrate the usage.  I’m using it to build up a query based on a set of options provided by a caller as part of a reusable and flexible service.

Using this I can handle subqueries like so:

import grails.gorm.DetachedCriteria as GrailsDetachedCriteria
import org.hibernate.criterion.Subqueries
import grails.orm.HibernateCriteriaBuilder

def customerQueryAggregator = new CriteriaAggregator(Customer)

GrailsDetachedCriteria largeOrderSubquery = new GrailsDetachedCriteria(Order).build {
  eqProperty 'order.id', 'this.id'
  gt 'totalPrice', 50000
  projections {property 'id'}
}

customerQueryAggregator.addCriteria {
  add(Subqueries.exists(HibernateCriteriaBuilder.getHibernateDetachedCriteria(largeOrderSubquery)))
}

Update April 4, 2014:

I ended up having some trouble with the proper definition of table aliases (it always wanted to call “order” “this” even though we already had a “this”) while handling the GrailsDetachedCriteria subqueries.  To work around it I ended up dropping back to straight Hibernate, but it still works with the CriteriaAggregator.

import org.hibernate.criterion.DetachedCriteria as HibernateDetachedCriteria
import org.hibernate.criterion.Restrictions
import org.hibernate.criterion.Disjunction
import org.hibernate.criterion.Subqueries
import org.hibernate.criterion.Projections

def customerQueryAggregator = new CriteriaAggregator(Customer)

HibnerateDetachedCriteria largeOrderSubquery = new HibernateDetachedCriteria.forClass(Order.class, 'order')
largeOrderSubquery.add(Restrictions.eqProperty('order.id', 'this.id'))
largeOrderSubquery.add(Restrictions.gt('order.totalPrice', 50000))
largeOrderSubquery.setProjection(Projections.property('order.id'))

customerQueryAggregator.addCriteria {
  add(Subqueries.exists(largeOrderSubquery))
}

Grails oddity

September 1, 2011 3:51 pm

I’ve been working on a bug for most of the day today.  From all of my understanding this bug shouldn’t have been happening.  This is always a pain because it means something is, obviously, wrong with my understanding, but because of that I didn’t know where to look.

The issue was that I was getting an unsaved transient object instance error when I tried to save updates to an object from a form.  My issue with it was that I wasn’t creating any new objects in my Controller code.  If I’m not creating any new objects, how can there be a unsaved transient?  And thus I spent a few hours learning through fiery trial-and-error, because I couldn’t find anything that would actually tell me what object was transient or where it came from.

The solution to this problem was in some of Grails’ behind-the-scenes, automagic data-binding.  Normally you can data-bind an associated object using a field in your form with a name like “associatedObject.id” and then Grails will automatically setup the relationship for you when you bind the request parameters to your object.  What I’ve now discovered is that Grails will also attempt to look up an associated object if you have a field in your form with a name like “associatedObject” even if you don’t use it for anything, and when it fails to find the object it creates a transient for you.

I needed to do something special with that field so I was using “associatedObject” instead of “associatedObject.id” and then in my data binding I was excluding that field from the binding:

bindData(objectInstance, params, [exclude:['associatedObject']])
objectInstance.save(flush:true)
-- unsaved transient exception

Again, the unsaved transient was an automatically created object that Grails created when it failed to lookup a match for the “associatedObject” field–this is regardless of the fact that I never actually tried to use that field for anything yet.

So I had to change the name of the field to something else, let’s say ‘assocObject’.  And once that’s done it’s perfectly happy to do what I want:

bindData(objectInstance, params)
objectInstance.save(flush:true)
// Saves successfully

Just thought I’d throw this out there since I spent several hours of my life discovering this little nuance and wasn’t able to find any useful information on the Internet.  I just wouldn’t have expected Grails to create a secret object behind the scenes like that when I never actually tried to use the value for anything.  Sure, if I attempted to bind it, great, work your magic; but if not, I wouldn’t expect it to interfere.

Grails Spring Security using PreAuthenticated Authentication Provider

May 26, 2011 11:09 am

This was a tricky problem I’ve been trying to solve for a little while.

If your webserver is providing the authentication service then your application simply needs to read in the `remoteUser` value out of the request header and trust it. In Grails you can do this with the Spring Security Core plugin using a PreAuthenticatedAuthenticationProvider. But it requires some configuration.

Follow the regular Spring Security Core setup process with the following adjustments.

In Config.groovy, define the providers you want available:

grails.plugins.springsecurity.providerNames = ['preAuthenticatedAuthenticationProvider', 'anonymousAuthenticationProvider']


And we need to define that preAuthenticated provider as a bean.

In resources.groovy we need:

beans = {
userDetailsService(org.codehaus.groovy.grails.plugins.springsecurity.GormUserDetailsService) {
grailsApplication = ref('grailsApplication')
}

userDetailsByNameServiceWrapper(org.springframework.security.core.userdetails.UserDetailsByNameServiceWrapper) {
userDetailsService = ref('userDetailsService')
}

preAuthenticatedAuthenticationProvider(org.springframework.security.web.authentication.preauth.PreAuthenticatedAuthenticationProvider) {
preAuthenticatedUserDetailsService = userDetailsByNameServiceWrapper
}

requestHeaderAuthenticationFilter(org.springframework.security.web.authentication.preauth.RequestHeaderAuthenticationFilter) {
principalRequestHeader = 'remoteUser'
authenticationManager = ref('authenticationManager')
}
}


And finally, in our BootStrap.groovy file we need to register the authentication filter:

import org.codehaus.groovy.grails.plugins.springsecurity.SecurityFilterPosition
import org.codehaus.groovy.grails.plugins.springsecurity.SpringSecurityUtils

class BootStrap {
def init = { servletContext ->
SpringSecurityUtils.clientRegisterFilter('requestHeaderAuthenticationFilter', SecurityFilterPosition.PRE_AUTH_FILTER)
}
}

Grails war error: codecOut.print(())

February 28, 2011 12:44 pm

Just stumbled upon this after upgrading to Grails 1.3.7. One of our gsp pages had an empty code block in it “${}” which was causing this error when trying to build the war. Running the app locally had no problems and Grails 1.3.4 had no errors when building a war with this empty code block, but Grails 1.3.7 did. Since there’s nothing on the Internet about this little annoyance I’m putting it here so someone else seeing that error in their console knows what to look for.

Just to put the information in one clean place:

When trying to build a war, I got an error pointing to “codecOut.print(())” as failing. The culprit was an empty code block in one of the gsp files. That is, in one of the gsp files this occured: “${}”. Clearly, someone forgot to fill in a value. I filled in the correct value and the war built without issue.