unicolet.org

Cache is king . Database lookups can be expensive and RAM prices have been falling for years to the point that developers don't care anymore (ops do, btw). So what if you could use those gigabytes of RAM for caching expensive queries or frequently used data? If you are a Java developer chances are that you came across Ehcache , Spring cache, or perhaps rolled your own. Disclaimer: not the Guava cited in this post Grails bundles Ehcache because it can be used by Hibernate and also has a  plugin which allows to cache methods just by annotating them. Unfortunately Ehcache has some quirks  and with the stock configuration it will also not allow parallel deployment (I documented a fix here  on this blog). An alternative cache implementation that I recently had a chance to use is the Guava LoadingCache . The implementation is so elegant that it will make you want to use it everywhere! Basically you build a cache, configure TTL and size (optional) and supply a lo...

When a Grails application makes use of the Ehcache cache plugin in its default configuration it can be impossibile to perform deploys of multiple versions of the app, even though the container might support it. The same plugin (in its default configuration) also breaks deploying multiple different Grails apps on the same container. The problem is in the way the plugin generates the name for the cache (which will then be used to register the cache jmx bean): the name is by default set grails-cache-ehcache . When another second application or another application version is deployed registration will fail because the name already exists. The exception message is the following (indented for clarity): org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ehCacheManagementService': Invocation of init method failed; nested exception is net.sf.ehcache.CacheException: javax.management.InstanceAlreadyExistsException: net.sf.ehcache:type=CacheM...

Being a longtime Java developer, back from when servlets where cool and Struts was making MVC popular among web devs, I always try to find new and more productive ways to deliver software within the Java ecosystem. Recently I turned to Grails and delivered several projects with it. When developing with Grails you can use the power and the expressiveness of Groovy to write compact, elegant, fluent and readable code. The downside is that Grails is huge: even the most simple Grails apps will weigh in the 40MB range compilation, test and building takes a long time (minutes, actually) even in recent versions it is (fairly) complex, but that I can understand because it does so much it will consume a huge chunk of you app server memory when deployed I have been using Grails as the backend for  Mappu  too, initially just because I wanted to bootstrap the project quickly and Grails is simply perfect for that. But as time passed I started to find Grails too heavy for a sim...

Grails has had a liquibase plugin for a long time (note: I am talking about the old liquibase plugin based on 1.9). One functionality that (I feel) it's missing is a proper Bootstrap hook so that database changes can be deployed right when the application starts. The newest liquibase plugin called  grails database migration  has it built in.

In some applications it is useful, and in some case required, that the application audits some or all database operations: for instance to track when a user updates, deletes or inserts a record. In Grails this is often handled by a plugin, like the Audit Logging plugin, which hooks into the Hibernate events and then logs the details to an audit table, including a timestamp, the user (if available) who initiated the operation and the type of operation. Unfortunately the Audit Logging plugin suffers from some issues  and if you, like me, have to ship today then you can only roll your own solution. In this post I will lay out a solution which is simple, efficient and should work in most scenarios. The general requirements are: only one datasource the underlying dbms must have triggers and some kind of session variables (most do, but I'll focus on Oracle) quartz jobs, background operations and other activities not necessarily initiated by an http request must properly initi...

Grails has great support for storing binary data into any database, Postgres included. It is usually simple to use but today it gave me problems. I have an application originally developed on pg 8.4 and grails 1.3.6 which stores images in a database table and used to work fine until I upgraded the database to 9.1. It turns out that with version 9 Postgres by default will return data to the client using a new hex format , instead of the escape format used in versions < 9. This, of course, confuses the client which returns garbage to the browser, hence the corrupted image. The solution is, luckily, quite simple: just tell postgres to revert to the old behaviour. It seems that this behaviour can be tuned per database, so you could have one database using the new format and another the old one: ALTER DATABASE dbname SET bytea_output='escape'; I should point out that I could also have updated the jdbc driver (now I'm using postgresql-8.3-603.jdbc3.jar ), but that s...

Sometimes it is convenient to make certain topological operations available in a web-based gis. For a gis that makes heavy use of Javascript (like OpenLayers-based ones) it might be worth looking at jSTS , a Javascript port of JTS. For all the rest and for those who don't want to load yet another library in the browser you can always write a Grails controller that encapsulates common JTS operations like buffer, intersection, union, etc. Assuming you are familiar with Grails the steps are as follows: drop the jts jar in the lib directory create a controller and define the relevant methods define a url mapping to prettify the calls Step 1 is trivial, so we'll go straight to 2. Create a controller and call it JtsController , then open the source file and paste this code: import com.vividsolutions.jts.geom.* import com.vividsolutions.jts.io.* import com.vividsolutions.jts.operation.overlay.snap.* import grails.converters.JSON import grails.plugins.springsecuri...

I personally like/use GrailsUI a lot and I'm sorry that it's been discontinued. Just today while I was upgrading an app from Grails 1.1 to 1.3.6 I found out that my previously working menubar is now spitting out ugly errors (like this one ). The problem lies in the unsafe use of instance variables by the tag library. Luckily for us the solution is pretty simple, just replace all references to items and group with a request scope variable like request.items and request.group. In my case I went a little further and tried to come up with a variable name that would not clsh with other variables actually used by me. My (working, yup) copy of the menu tag library is available at  https://gist.github.com/1358135 . To use it just copy it into your project's taglib folder and then build a menubar as you would do with GrailsUI, only using the g: prefix instead of gui: .

Warning : this post is a work in progress. Full source code for both Sproutcore and Grails  parts can be found at my github account  https://github.com/unicolet . All the Sproutcore examples that I've found so far only show how to fetch data from different backends, but there is unfortunately very little material on authentication. In my case I'm hooking up to a Java backend written in  Grails  with authentication being provided by by Spring Security . The grails spring-security-core plugin documentation already incorporates  Ajax logins so the server-side code is already in place. We only have to apply one small tweak to make it work with Sproutcore. Prerequisites: Grails, Sproutcore > 1.6 with Statecharts. The statechart in the figure illustrates the states and transitions we plan to handle. Authentication Let's start with authenticating the user. We will deal with reconnecting the session later. Assuming you have a basic Grails ...