Original Source

Burt Beckwith has released the first version of the grails-ui-performance plugin. On a previous post he describes a handful of optimizations he has done at work, which eventually led to the birth of the plugin

I’ve been looking at performance issues for the site we’re building at work. The database is obviously going to be the biggest bottleneck, so we’ve configured 2nd-level caching for read-only tables and some read-mostly tables. We’ve also configured query caching for obvious candidates.

Currently the big hitter is the search page, and some profiling showed that we just needed a few extra indexes and some extra 2nd-level caching, but otherwise it performs pretty well. I still need to test it on production hardware with a large database – the stuff I’ve done so far is on my own high-end developer box with the database, server, and clients all running on the same box.

So I’m now working on applying the 14 rules from Steve Souders and the Yahoo performance team. YSlow has been very useful to measure improvement after each change, and of course Firebug is indispensable.

This is a Grails app, and Grails makes several parts of the process a lot easier, but of course all of these approaches apply to non-Grails apps too.

This plugin is not the first one aimed at improving the performance of a Grails application, or a regular web application for that matter, Burt makes sure to mention the Jawr plugin, here are his reasons for trying out the new plugin

One significant feature that I’m providing is versioning and far-future Expires headers and caching for images in addition to JavaScript and CSS. Of course images aren’t very compressible, so gzipping them doesn’t make much sense, but the image payload of most sites is going to be a lot larger than that of the .js and .css files, so it makes sense to try to get clients to cache those also.

Another is a taglib that helps keep javascript at the end of the page. Sitemesh gets in the way here - there can be a lot of code in your layout GSPs after the layoutBody call, so DependantJavascriptTagLib allows you to define one or more hidden JavaScript declarations in your GSPs and render them all from the layout at the end of the body (Sitemesh has “content” tags that support this but there’s a bug where script tags lose their opening bracket so I’m using a technique borrowed from here).

Finally there’s simplicity - this was designed as a Grails plugin, so it has a more focused feature set and has fewer moving parts, preferring convention over configuration.

Having said that, there are advantages and disadvantages of both approaches:

Reasons to use Jawr versus using this plugin:

• a lot more features, e.g. I18n, DWR, and JSF support, choice of minification approach, etc.
• more configurable, e.g. exclusion lists - I gzip/minify/version everything
• it’s not Grails-specific, so the time you spend learning its features will be useful when you want to use it in non-Grails apps

Reasons to use this plugin versus using Jawr:

• the bulk of the work is done during the build, so no temp files, everything is in the war and problems are caught during the build instead of after deployment
• it versions and sets Expire on images, and rewrites inner urls in css files to point to versioned images
• supports Sprites via a taglib
• helps move JavaScript to the end of the body via a taglib
• doesn’t use a servlet - only a few taglibs and a Filter, letting the container continue to serve static resources
• less processing at the server - it only needs to check if client supports gzip when rendering <javascript>, <css>, and <img> tags in GSPs

The plugin can be downloaded from Burt’s site (here) for the time being. We look forward on the next update.

more Grails-friendly - in development mode it does nothing, and is only enabled in production mode, so there’s no need to check for modifications since Grails doesn’t support that in production mode

Tags: Burt Beckwith, Grails, Plugin

Original Source

Fernando Takai has been experimenting with Oracle Coherence lately. In case you haven’t heard of Oracle Coherence before, it is a JCache -compliant in-memory distributed data grid solution for clustered applications and application servers, in other words a fast and reliable way to keep your data ready when the request load gets ugly. Fernando is also a developer fond of Grails, so he decided to test Coherence as a second-level cache for Hibernate, driven by GORM of course.

He first demonstrates the basics of running Coherence and making sure that it is working. The next step involves defining the configuration of the second-level cache (for which he provides a pastebin url, nice). Finally enabling the cache and running Grail’s console. Some useful bits of information are thrown along the way, like enabling your domain classes to be cached.

Those steps are sufficient enough to get you up to speed should you decided to try it. We are sure there are plenty of knobs and levers you can turn and switch to tweak the secon-level cache. Fernando promises to describe how to embed the cache into a real app and do some tuning in a future installment.

Tags: Fernando Takai, Grails, Howto

Original Source

Dave Cherry has written a step-by-step guide for setting JEE style role based authentication (that means realms) as a way to secure your Grails application. This guide is not for the faint of heart, it requires you to roll your sleeves and edit a couple of files residing in your GRAILS_HOME directory, not your project_home directory, meaning the changes will be system wide and not project wide. Despite this minor inconvenient Dave is sure to point to alternatives and other useful JEE security links that will help you along the way.

JEE role based security provides a means of controlling access to resources configured at the application server level. On some larger projects or within corporations this type of access control may be mandated. Due to the fact that the application server controls the security, several applications can share the same realm and therefore share the same credentials, this can be a big plus on large websites, spanning multiple applications.

If you are not familiar with role based authentication look at Using Role based security and tomcat realm how to. Also note that Grails has other options for handling security including the ones listed here grails security plug-ins.

In order to use role based authentication with Grails, several changes are required. Unfortunately one of the cases requires that the actual runtime be changed. However, this change is very straightforward and documented here. Note any references to grailshome, actually refer to the directory where Grails itself is installed and not a Grails project.

Continue reading the full article at The Coder’s Corner.

Tags: Dave Cherry, Grails, Howto, Security

Marcel Overdijk has written a couple of entries regarding a common problem faced when paginated views are involved and how he found a solution with Grails.

With the default Grails scaffolding each time you navigate away from the list page (e.g. going to the show page) the state of the list is lost when you return. This can be annoying when you paged to a certain page within the list.

His first attempt solves the problem right away at the source, in other words, at the controller’s action being invoked. The next iteration refactors the remembering strategy into its own method, and it includes a slicker syntax thanks to the Elvis operator. The last iteration is one step further into customization, in Marcel’s words

In my Grails project I’ve added a ‘restoreState’ method dynamically using the ExpandoMetaClass to all Controller classes. The method is simply added in BootStrap.groovy

Here are the links to each version and their code

• Remembering state of a Grails list page 1
• Remembering state of a Grails list page 2
• Remembering state of a Grails list page 3

The last iteration may as well be packaged in its own plugin don’t you think?

Tags: Grails, Marcel Overdijk, Tips

Dimitry Kopylenko has announced that GraisCrowd is now live. GrailsCrowd is a online community/social networking site for Grails developers. Dimitry has worked on the project since last December, you can follow his thoughts on the project at @grailscrowd.

GrailsCrowd is not only driven by love of Grails, it is also run by Grails. The code will most likely be open sourced in the future, as Dimitry said.

Tags: Dimitry Kopylenko, Grails

Original Source

• Bill Bejeck tutorial on Flex and Grails
• RPU’s blog on mocking file uploads
• Peek in Grails - Adobe Air widget for Grails Reference docs
• Groovy Reference Card
• GMaven plugin 1.0-rc3 released.
• DZone Interview with Andy Glover
• JSilhouette 0.1 released
• PasswordKeeper port released.
• Groovy to Approach Java speed? on CK’s blog.
• Glen’s Message Driven POGO blog
• BIRT Plugin released.
• Grails Runtime Logging Plugin v0.3
• Include Plugin released
• jBPM Plugin released
• GrailsFlow 0.3 Workflow and Process Engine released

Tags: Audio, Grails

Original Source

DeveloperWorks has published the latest installment of Scott’s Mastering Grails series: The Grails Event Model. This article lays out the basis for event handling in Grails, both at the macro and micro levels. The macro level is build and application wide. Grails (and its huge library of plugins) usually publish events whenever a script runs or an artifact is changed, according to the plugins needs. You have the option to listen on those events and react accordingly. The micro level happens at the domain layer, where domain classes publish four events whenever they interact with the database.

Building a Web site is a study in event-driven, reactive development. Your application sits idle, anxiously waiting for the user to send in a request. It passes back the response and then goes back to sleep until the next call. In addition to the traditional Web life cycle of HTTP requests and responses, Grails provides a number of custom touch points where you can tap into the event model and provide behavior of your own.

In this article, you’ll discover the myriad of events being thrown in during the build process. You’ll customize the startup and shutdown of your application. And finally, you’ll explore the life cycle events of Grails domain classes.

Scott demonstrates in a few and simple steps how to plug into Grails’ events on the macro level (build), his recommendation is that once you get used to working with events you place your event handler scripts inside the project’s script directory, that way your customization will be saved in version control too. The other type of macro events are application events, whenever the application starts (init) or shutdowns (destroy). Grails includes a BootStrap.groovy script inside your project’s configuration, from there you can typically setup initial data required by the application (DomainBuilder is really handy in this situation), conversely you may delete any data saved. Or you could trigger a webservice call, it doesn’t have to be database related, the point is that you can put there whatever your application requires.

He finalizes with the micro level events, those fired by domain classes whenever they come in contact with the database, those events are: beforeInsert, befortUpdate, beforeDelete, and onLoad. The names should be self-explanatory, still Scott gives a good example of their usage.

Events throughout Grails can help you further customize the way your application behaves. You can extend the build process without modifying the standard Grails scripts by creating an Events.groovy file in the scripts directory. You can customize the startup and shutdown process by adding your own code to the init and destroy closures in the BootStrap.groovy file. And finally, adding closures like beforeInsert and beforeUpdate to your domain class allows you to add behavior such as timestamping and geocoding.

Tags: Grails, Scott Davis

Original Source

Glen Smith delivers the second half of his ‘concoction’ of JMS/Grails/OpenMQ. If you remember the first time he described how the Grails JMS Plugin can be used to post messages to a queue from a service. The other half of the solution involves Message Driven POGOs (no, not the jumping sticks, but Groovy beans).

When we last left this story, I was talking about integrating Grails and JMS so that groovyblogs can put all of its feed and thumbnail fetch requests on a JMS queue. Now it’s time to look at the second half of the story. How my standalone groovy feed/thumbnail fetcher can pick requests off the queue, and put a response back on a different queue.

First a little background. Spring makes writing message driven POJOs really tidy. Groovy makes it even tidier. To implement a POGO (Plain Old Groovy Object) that listens on given Queue, I just have to implement the MessageListener interface, and provide an onMessage routine. Spring will setup the necessary background thread poller that will invoke my bean when a new message arrives on the queue. It will also look after the connection pooling to my JMS server so I’m not creating/dissolving connections every time. Nice.

But if I want to put something on the queue? Then it’s time to use Spring’s JmsTemplate class which provides the necessary convertAndSend that I’ll need to put my Map object back on the queue with my thumbnail result.

Due to the fact that Grails sits atop the Spring framework, Message Driven POGOs are trivial to implement, almost criminal as some say. As Glen describes the steps are simple:

• have your MD POGO implemente javax.jms.MessageListener
• add a jmsTemplate property, it will be injected by Spring
• call jsmTemplate.convertAndSave() when you want to post something to the queue
• don’t forget to setup the required bean mappings on your application context

Of this steps perhaps the most verbose is the setup of the application context (Glen went with the XML version) but perhaps Grails’ Spring BeanBuilder can help in reducing the angle bracket noise, don’t you think?

Tags: Glen Smith, Grails

Original Source

This articles comes from Adobe’s Developer connection. Bill Bejeck, a software engineer for Near Infinity in northern Virginia, demonstrates how a Flex client can communicate with a Grails applications. He lays out pretty well everything you need to follow the steps (tools and code).

The Grails framework greatly simplifies the task of building a Java web application. This article illustrates one approach to integrating a Flex application with a Java server application using Grails. The sample application for this article is a simple Flex search application, but the principles shown here still apply for building more complex applications.

While there are many great options available for connecting Flex applications with a server application, for example, LiveCycle Data Services ES or its open source counterpart BlazeDS, the sample application uses a RESTful approach for client-server communication. It is true that using the aforementioned frameworks offer several powerful advantages, but there are benefits to using a XML/RESTful approach that should not automatically be discounted. Chief among these are:

1. RESTful services are straightforward to implement and maintain.
2. The server and client applications, respectively, either respond with XML or parse responses sent in XML, freeing them from dependence on any particular platform. Note: Using XML is not required; the approach outlined here could be used with JSON.
3. No mapping files of any kind are required.
4. There is less of a learning curve if this is the first experience building a Flex client with a Java server application.

The article starts heavily on the Flex side, but don’t be discouraged, it is only a matter of a small refactoring on a previous application he built, just to be sure the RESTful connections are in the proper state. The Grails side is pretty straight forward, as you would expect, the SearchController outputs everything in XML, a rather simple job given the powerful abstractions founs in Grails’s controllers.

Tags: Bill Bejeck, Flex, Grails

Original Source

Christopher M Judd describes how to enable a simple ajaxy feature that every web 2.0 site needs theses days: a background operation feedback animation icon. Given that Grails is an open source project built on open source projects it is no surprise that it relies in the popular Prototype/Script.aculo.us pair to achieve this task. With all things Grails, getting this feature to work is pretty straight forward, as Christopher shows.

For standard page requests, browsers use an animated icon as an indicator to the user that the browser is waiting for the request to complete. However, for AJAX calls that are initiated via JavaScript in a separate thread the browser icon does not animate. So, typically the application developers use an animated icon within the page to notify the user the page is waiting for a request to complete. In an effort to simplify web development Grails automatically includes an animated spinner icon when using the Prototype or script.acolo.us AJAX frameworks.

To enable the Grails AJAX spinner you must include the Prototype or script.acolo.us JavaScript typically using the <g:javascript library=”prototype”></g:javascript> or <g:javascript library=”scriptaculous”></g:javascript>. But these declarations can not be included just any place within your page. These declarations must come before the tag since it includes the application.js file that registers the spinner with Prototype and requires Prototype variables to be available.

Christopher outlines the current options either using the standard layout (the available one when you generate views or use scaffolding) or when a custom layout is used. You may find the required GSP code at this link.

Tags: AJAX, Christopher M Judd, Grails