How to authenticate to grails from R using RCurl

The trick is to open the login page before actually trying to post the login data. I assume something is stored in the cookie, but I only know this is how it works. See also my question on stackoverflow: http://stackoverflow.com/questions/20355874/how-to-use-rcurl-to-authenticate-to-spring-security-grails-app/20370222#20370222

My simple approach to security tokens

I'm a big fan of the spring-security plug-in series for grails. It allows me to do almost anything concerning security issues while giving me faith that this works properly. One scenario I encountered now, however, was not covered. In order to secure mit JSON web-service actions I couldn't rely on spring security. Instead I wanted to create unique links just like in google's picasa, when you wanted to share an image with a 3rd party that does not necessarily have a picasa account like you do. I decided to implement this in a very simple fashion: I added a field String uuid to the domain class in question. Then I added a service class: Then all I needed to do is to modify controller actions like this: I would like to hear what you think about this approach. Is it save enough? Is there a more elegant solution?

Pitfall with grails projections

With grails projections one should keep in mind that when one of the associated values turns out to be null, the entire entry is ignored in the result list. I found numerous posts, where this problem is addressed by alternating the join mode from inner join to left outer join:

http://www.intelligrape.com/blog/2011/11/01/criteria-query-with-left-outer-join/
http://stackoverflow.com/questions/17083204/criteria-uses-inner-join-instead-left-join-approach-by-default-making-my-que
http://stackoverflow.com/questions/19390720/grails-2-x-createcriteria-or-doesnt-work-for-nested-associations/19391255#19391255

Now, I do something like this:

Speeding up JSON export in Grails

In one of my grails apps, I export a large quantity of data in JSON format. This process was incredibly slow (~30s) and somehow I was convinced that this was a database issue since numerous joins were involved as well. As it turns out, however, the database query took ~1s to complete so that I got curious what the other 29s were spent on. Very unexpectedly, I had to blame grails' native JSON converter. A google search revealed that this was already known:

http://sysgears.com/articles/speedup-json-parsing-grails/

I decided to follow the suggested solution and started playing around with Jackson. Pitfalls are that some Java objects seem to cause Jackson some trouble, e.g. if objects can't be serialized. I therefore decided to use projections to efficiently recover all the database fields I was interested in (probably speeding up the database access as well). Since all the fields were then strings, ints or doubles, conversion worked like a charm. The exact same conversion now takes only ~1s, adding up to ~2s in total.

This helped me to understand how to use Jackson:
http://wiki.fasterxml.com/JacksonInFiveMinutes

There even seems to be a grails plug-in available to replace the default JSON converter with Jackson:
https://github.com/sjhorn/grails-jackson

However, I didn't try it out since development does not appear to be active.

One last important thing to note is that if you want to use jackson to render JSON content you might get into conflict with the regular JSON converter if you try to do something along the lines of render AS JSON. What you need to do instead is:

Deploying a gails app with the cloud-foundry plug-in

I recently discovered that CloudFoundry accounts are free (at least for now) and this offers a perfect opportunity to install a demo instance of grails applications. As with most things in grails, this is pretty straight-forward if you forget about the one or two issues you need to solve beforehand. I basically followed Burt Beckwith's excellent guide here: http://blog.springsource.org/2011/04/12/one-step-deployment-with-grails-and-cloud-foundry/ There were only two things giving me a headache. One issue was that the application did not get enough memory (PermGen of course). This was solved easily by reading the documentation of the plug-in:

//increase memory size to 1G (2G is max), don't start immediately since we need to change JAVA_OPTS
grails cf-push --memory=1G --no-start
grails cf-env-add JAVA_OPTS "-Xmx1024m -XX:MaxPermSize=512m -XX:+CMSClassUnloadingEnabled"
grails cf-start

The second issue became apparent from the exception: liquibase.exception.ServiceNotFoundException: Could not find implementation of liquibase.logging.Logger Thinking about this for a second I remembered that Liquibase was used by the database migration plug-in. I just removed it from the runtime in BuildConfig.groovy and tadah everything was running fine! I also raised a jira for this: http://jira.grails.org/browse/GPCLOUDFOUNDRY-52

jQuery together with other JS libraries (e.g. Prototype)

I want to gradually migrate from Prototype to JQuery in one of my projects (grails 2.0.4), but when I tried to use both libraries at the same time I got some error messages and the JS functions did not work anymore. Turns out JQuery has a compatibility feature you can turn on: http://docs.jquery.com/Using_jQuery_with_Other_Libraries jQuery.noConflict() On top of that there were issues with the resources plugin, which I circumvented for now by manually loading jQuery where I need it.

grails database migration plugin: upgrading an existing database

Today was in fact the first time I ever got into a situation where the setting dbCreate = 'update' couldn't manage to update my data base scheme after modifying some of my domain classes. This was unfortunate of course, but since I've been reading that this is bad practice anyway I decided to have a closer look at the new database migration plugin that came out at roughly the same time as grails 2.0 did. This plugin utilizes Liquibase, which has been around for a while from what I could see and seemingly does a very good job. It turns out that the database migration plugin gives you a really smooth integration of Liquibase and grails.

Coming to my actual problem:
After adding the spring-security plugin I wanted to have some light history with two of my domain classes, so I introduced the fields

• createdBy,
• lastUpdatedBy,
• created,
• lastUpdated.

The latter two are automagically populated by GORM and the first two I could populate in the controller classes using the springSecurityService. This obviously leaves existing database rows without this information and since I assigned a "not nullable" constraint, hibernate sure enough complaint when trying to change the scheme.

So I did some reading on the excellent tutorials I found to get up to speed:
http://blog.springsource.org/2011/08/17/countdown-to-grails-2-0-database-migrations/
http://fbflex.wordpress.com/2011/01/19/working-with-the-grails-database-migration-plugin/

After understanding the key concepts I went ahead and followed the instructions at the end of the second blog post (updating an existing database). I created a new environment "migrate" which I configured to use a copy of my database. My domain classes where already changed, so I just needed to compare the current database scheme with my domain classes using

This yields a changelog.groovy file that translates the liquibase xml configuration into the groovy world. Since the conversion is straight-forward you can make use of the liquibase docs to modify this changelog. The original changelog corresponds exactly to what GORM would have done anyway with dbCreate="update".

You can try and run it using the dbm-update command:
You might be happy at first seeing that everything seems to work fine, but soon you'll be frustrated because nothing actually happened. At this point you might have already asked yourself (like me) how the plugin knows which changelog you want to apply. And in fact you have to specify this in Config.groovy: Of course running the update failed for me. I didn't do anything about the not null constraint. I solved this problem by removing the constraint from the original add column configSet and adding a new configSet add the end where I specified a defaultNullValue ( http://www.liquibase.org/manual/add_not-null_constraint ), which replaces all my trouble-causing NULL entries with a sensible value: This worked really fine for the createdBy and lastUpdatedBy column where I only had to set an integer value. However, it took me quite some time to figure out how to set a date correctly. I read a lot about timestamp and getdate() functions and in the end the simplest solution was to just figure out the date syntax which looks like this:

 A few important tips for working with this plugin:

• Use grails -Dgrails.env=yourEnv to run a custom environment besides dev, test or prod.
• Use grails dbm-update-sql to see what SQL code is created.
• Be aware: The dbm-update command often fails more or less silently. Therefore: 
• Look into your database! There is a new table called DATABASECHANGELOG. 
If you compare the entries in this table you will quickly see which configSet caused the operation to fail. This is most likely due to a syntax error because problems with the database usually cause an exception.

And if you finally get to see the following line:


| Finished dbm-update

You finally did it and you can leave for the week-end.