A Grails 1.0.4 Gotcha

{ Dan Stieglitz // Groovy/Grails // December 29, 2008 }

Experiencing lots of unexplained, frustrating LazyInitializationExceptions in your Grails application lately? It could be due to a gotcha I was wrestling with that’s present even through Grails 1.0.4. Fixing it will likely take some time as it will require some rethinking and probably some refactoring of the core Grails framework but there is a workaround, once you figure out you’ve run into this gotcha.

The symptom is that you get a LazyInitializationException when you don’t expect one (well, you never really expect them) but even if you’re an experienced Hibernate developer this might throw you for a loop. The problem is that the Grails OSIV filter will have closed the Hibernate “currentSession” by the time the SiteMesh template is processed, so ANY calls to GORM dynamic methods will through this exception if you’re accessing lazy-initialized fields from your domain objects.

The solution is to remove all Hibernate calls, including those in tag libraries, from your SiteMesh templates. Or, if you must have the aforementioned calls, you can modify your tag libraries (since I know everyone is using tag libraries instead of just mashing code into your GSPs within <% %> brackets, right?) in a manner similar to this:

    def isReseller = { attrs, body ->


        if (authenticateService.userDomain()) {


        def u = Person.createCriteria();


        def user = u.get {


             eq("id",authenticateService.userDomain().id)


             fetchMode(’primaryAccount’,FM.EAGER)


             fetchMode(’primaryAccount.type’,FM.EAGER)


             }


         }


    }

The above code assumes you’re using the Spring Security plugin (aka ACEGI) and want to check for a specific account type for the logged-in user when rendering your SiteMesh layout. It will eagerly fetch the primaryAccount and primaryAccount.type objects (they are 1-to-1 references in this example) when retrieving the account, so no session is required once the call is finished.

Hopefully I saved you some hours here… you can see the JIRA entry for this at http://jira.codehaus.org/browse/GRAILS-2764.

Happy holidays to all, and here’s to a prosperous 2009. If you’ve been hit hard by the financial crisis, I hope that it doesn’t last long. Once again we are reminded that “what goes up must come down,” and also that greed and stupidity are a bad combination… especially for financiers and their financial-industry colleagues.

5 comments

Another solution:
http://www.jtict.com/blog/grails-existing-hibernate-dao/

Posted by J on 12/30 at 03:03 PM

hey its a well written post and being a professional i really like this actually i was searching this kind of 642-061 exam information and now found it here on this nice site you have done a nice work and i also checked the link its very useful.. these days i am busy in my professional 642-066 exam classes and will come after that for more discussion..

Posted by on 09/28 at 05:12 AM

The problem is that the Grails OSIV filter will have closed the Hibernate “currentSession” by the time the SiteMesh template is processed, so ANY calls to GORM dynamic methods will through this exception if you’re accessing lazy-initialized fields from your domain objects.

Posted by www.poker-virtuel.fr/ on 11/25 at 05:26 AM

ere ekad xxx video mkpcpb natural penis enlargement pill usyjxd black porn arhjizju male penis enhancement zgahsrcfs babes joitibctp

Posted by xxx videos on 05/27 at 03:18 PM

nice post like this this subject is very nice chose by writer thanks to give info and thanks to site admin and writer

Posted by penis enlargement on 06/23 at 06:45 AM

Add your own comment below.