It’s a two-for-one today – a “gotcha” and a “how to” all rolled into one, this time about redirecting in a Grails filter.
Much like my favicon woes my initial attempt to redirect to a primary domain (a .com without the “www” prefix) had some unexpected consequences when deployed to a live server on CloudFoundry – I started getting warnings that my site had gone down!
In this post I’ll hopefully save you the panic of CloudFoundry telling you that your site’s not responding when you try to rationalise your domain names!
Setting up MySQL connection pooling has been standard stuff in server-side apps for as long as I’ve been writing them, so I was at a loss when, every 5 days or so, my newly deployed app died with this exception:
Exception in thread "main"
Communications link failure
Last packet sent to the server was 0 ms ago.
Here’s a quick gotcha for you. You set up a favicon in the root of your web app, as is the convention, and when you log in you are redirected to a picture of your favicon or you are asked to download it… Weird.
Odds on you’ve installed the Spring Security plugin and forgotten to give permission to the favicon file in the root and the result is that on login Spring Security redirects you to the first restricted item that was requested by the browser – the favicon.
The solution? Easy, set the favicon path to IS_AUTHENTICATED_ANONYMOUSLY in your SecurityConfig.groovy (or database):
controllerAnnotationStaticRules = [
'/favicon.ico' : ['IS_AUTHENTICATED_ANONYMOUSLY'],
The usually simple upgrade process in Grails has caused me a few headaches in moving from 1.2.2 to 1.3.1. I skipped the 1.3 upgrade because there were a few people having issues on the mailing list but yesterday I bit the bullet and encountered a couple of problems.
I think the release notes for Grails 1.3.x have been unusually poor so this post has the issues I’ve encountered in the hope that you won’t go quite as mad as I have. I’ll keep it updated if I find more problems. Continue reading
I just came across this problem using the datePicker tag in a gsp – it appeared that there was no way to stop the tag showing today’s date when no value was set on the bean. Continue reading
The first sign something was wrong was the JVM bombing out with a “java.lang.OutOfMemoryError: PermGen space” error. All I’d done was change a gsp, so I restarted and after a long wait the same thing happened and it was then I noticed that the compiler just kept recompiling 4 classes in a loop until the JVM bombed.
This had happened to me once before when I’d managed to set the time incorrectly on my PC so some of my files appeared to be modified in the future. However this time I’d not done anything of the sort.
[sigh] Some days just seem to be wasted trying to work out why some apparently simple task cannot be accomplished. The frequency of such days has increased somewhat since I started using Grails – while I am a fan of the framework it is still occasionally buggy and badly documented and I seem to stumble into issues every week.
I love having the ability to create property getter and setter methods in Groovy and it really simplifies all those bean accessors in Grails domain classes. At least, it does until you define one incorrectly and spend an embarrassingly long time trying to work out why data in your Grails controller isn’t being bound… Continue reading
I’ve been using the Grails RichUI plugin and have found a few of the tags it provides to be very useful. The one I’m using the most is the AutoComplete tag which I may well be writing more about in the near future. However, tonight I found a potential issue with the way it creates the YUI data source for the component – it seems it always gives it the same name: ‘autoCompleteDataSource’.