• compatibility with Grails 1.3.x. Be aware, Grails 1.3 – 1.3.3 are suffering from http://jira.codehaus.org/browse/GRAILS-6427, so either use Grails 1.2.x, or be brave and use a recent git build of Grails 1.3.4.SNAPSHOT.
• usage of Neo4j 1.1 (released today just a few hours ago, so get it while it’s hot).

All changes:

• [GRAILSPLUGINS-2302] – “home” link broken in the org.codehaus.groovy.grails.plugins.neo4j.Neo4jController views
• [GRAILSPLUGINS-2303] – Problems with annotation Neo4jEntity
• [GRAILSPLUGINS-2345] – upgrade to Neo4j 1.1
• [GRAILSPLUGINS-2346] – <domainclass>.get() throws exception if id is not invalid
• [GRAILSPLUGINS-2347] – <domainClass>.findAllBy<Field>(value) fails
• [GRAILSPLUGINS-2349] – provide compatibility for Grails 1.3.x

When support for a new language is requested, all you have to do is translating messages.properties. So far so good – this make i18n really easy.

But: when the project evolves, there’s a good chance that some of your i18n properties in messages.properties gets orphaned. Assume you remove a block of code from a gsp. It happens often that the i18n properties used in this block are not removed from messages*.properties because at some point you are not sure if it is referenced elsewhere. So what would be really useful here would be a list of all referenced i18n properties from your *.groovy/*.gsp files.

Doing so is pretty easy, just add a new gant script to your Grails application’s script folder, let’s name it i18nList.groovy. This script basically contains:

includeTargets << grailsScript("Init")
 
target(main: "create a list of all i18n properties used in groovy code and gsp templates") {
 
    def properties = []
 
    new File(".").eachFileRecurse {
        if (it.file) {
            switch (it) {
                case ~/.*\.groovy/:
                    def matcher = it.text =~ /code:\s*["'](.*?)["']/
                    matcher.each { properties << it[1] }
                    break
                case ~/.*\.gsp/:
                    def matcher = it.text =~ /code=["'](.*?)["']/
                    matcher.each { properties << it[1] }
                    break
            }
        }
    }
    println properties.sort().unique().join("\n")
 
}
 
setDefaultTarget(main)

(sorry the color coding seems to fail for some Groovy regexes) The script recursivly iterates over all *.groovy and *.gsp files in your project and extract the part after the ‘code’ attribute of the message tag using a regex. The regex result are collected into an array. This array is sorted, unique’d and printed to the console. That’s it.

One word of caution: this gant script ‘works for me’. So depending on your code, you might notice that the used regex are not sufficient or even fail. Feel free to modify them for your needs, even better send back your modifications.

This plugin’s goal is to simplify the deployment of a grails application to a cluster consisting of multiple tomcat instances and an Apache httpd mod_proxy_balancer.

It assumes you have an Apache mod_proxy_balancer running in front of multiple tomcat instances in order to provide a) high-availability and b) load-balancing to your Grails application. In such a scenario, upgrading the running application to a newer release is painful and error-prone when done manually. This plugin’s goal is to simplify that procedure by performing a “rolling upgrade”. Calling ‘grails tomcat redeploy’ performs these actions:

1. take first node offline in loadbalancer
2. undeploy app on first tomcat node
3. deploy app on first tomcat node
4. check if app responds on first tomcat node
5. take first node online in loadbalancer
6. proceed the same procedure with next node

To solve this, we’ve forked the 1.3.1 release of the tomcat plugin an added the following capabilities:

1. deploying to multiple hosts and
2. emitting lifecycle events: PreDeploy, PostDeploy, PreUndeploy, PostUndeploy
3. provide support for ‘grails tomcat redeploy’

These changes have been included in a pull request to the upstream plugin, so I’m hoping they will find their way into Grails 1.3.2.

The rest of the work has been put into the modproxybalancer plugin, taking care of remote controlling the loadbalancer  by catching up these events. mod_proxy_balancer comes with a simple management frontend called balancer-manager. This consists of some simple HTML forms that can be easily triggered using htmlunit. When the forked tomcat plugin emits a “PreUndeploy” event, the loadbalancer disables the respective tomcat node, then a normal undeploy und deploy happens. After this, the freshly deployed tomcat is checked for availablity and taken back online in the loadbalancer.

The plugin is licensend under the WTFPL.

Side note: this is my first Grails plugin with it’s sources residing on github.com. Thanks to Peter Ledbrook’s excellent blog post, I was able to use GitHub pages for the documentation.

def beforeInterceptor = {
   if (!["127.0.0.1", "0:0:0:0:0:0:0:1"].contains(request.remoteAddr)) {
      render(status: 401, text: 'Access limited to localhost')
      return false
   }
}

Grails calls the beforeIntereceptor closure prior every action in a controller. Only if it returns true, the action is executed. In the code above if the client has a non-local IP address, a 401 error is returned with an error message. Note that localhost in IPv6 is 0:0:0:0:0:0:0:1, so it work both in IPv4 and IPv6 networks.

• performance improvement by no longer calling map constructor in createInstanceForNode
• fixed transaction handling by replacing interceptor with a “real” servlet filter
• support for primitve arrays as properties in domain classes
• bugfix: handling of bidirectional many-to-many relationships
• bugfix: setProperties does no longer null out properties that have not been set
• support for encodeAsXXXX methods from CodecsGrailsPlugin. In previous versions encoding did not work, since the ‘node’
  property of the domain classes could not be encoded (it’s a neo4j internal class!). Workaround: add getNode()==null method
  in AST transformation.

Everyone using the 0.2 release is recommended to upgrade.

openssl pkcs12 -in protected.p12.orig -nodes -out temp.pem
 
openssl pkcs12 -export -in temp.pem  -out unprotected.p12
 
rm temp.pem

The first command decrypts the original pkcs12 into a temporary pem file. pem is a base64 encoded format. The second command picks this up and constructs a new pkcs12 file. During this, the new passphrase is asked. By simply typing ‘return’ here, it set to nothing. When using unprotected.p12 in the OpenVPN connection, you’re no longer asked for a passphrase.

A word of warning: I do not recommend doing this generally. From my perspective it’s okay, if your unprotected pkcs12 file is protected by other means, e.g. harddisc encryption.

export JAVA_HOME=<jdk-dir>
 
export GROOVY_HOME=<groovy-dir>
 
export PATH=$GROOVY_HOME/bin:$PATH

With that, it’s possible to run all the stuff in $GROOVY_HOME/bin, e.g. the groovyConsole on the N900. It terribly slow, the groovyConsole takes abount 60 secs to come up, the keyboard has a very long lag when typing – but it works!

Anyone else got a ‘groovy’ smartphone?

The key features / changes of this release are:

• domain classes managed by Neo4j can now co-existing with traditional domain classes (aka mapped by Hibernate)
• Upgrade to Neo4j 1.0
• usage of Grails dependency resolution instead of embedding the jars in /lib directory
• added a seperate controller to inspect the Neo4j node space
• major refactoring using AST transformation, just like in the couchdb plugin
• support for the Neo4j indexer
• support for non-declared properties
• support for traversers

In more detail:

Co-existence with other domain implementations

In the initial 0.1 release there was no possibility to have hibernate-based domain classes and neo4j-bases domain classes within the same application. By massively learning from the implementation of the CouchDB plugin, the neo4j plugin shares now the same principles:

• each domain class annotated with “@Neo4jEntity” is managed by Neo4j
• the @Neo4jEntity  annotation triggers a Groovy AST transformation at compile time. This transformation e.g. injects a reference to the Neo4j node instance in each domain class.
• the plugin class delegates most of its work to a singleton-style plugin support class
• the plugin support class uses Groovy MOP to inject (most of) the GORM methods into the domain classes

Upgrade to Neo4j 1.0

About two weeks ago, the Neo4j team released their 1.0 version. In order to keep pace, the 0.2 version of the plugin upgrades to this version.

Using dependency resolution

In its recent versions Grails provides a powerful dependency resolution DSL. Using this feature, the Neo4j plugin does not contain the neo4j jars itself any longer. Instead they are automatically downloaded upon plugin installation from the Neo4j’s maven repository.

Controller for visualizing the node space

The plugin contains a Neo4jController that provides an easy way to inspect and walk through the nodespace. All the properties and relationships are visible and navigable, see the screenshot.

Aside from navigating through the nodespace, the Neo4jController also provides an action for viewing some statistics: counting nodes an relationship by type, and an inspector for viewing the Grails domain class structure. One word of warning: do not expose this controller to the public! Instead use e.g. the acegi plugin and protect it from public access.

Support for Neo4j Indexer

Since there is no easy way to ask the nodespace questions like “Give me all cars with more than 250 hp?”, Neo4j provides an addon that indexes property values. The plugin supports this in two ways:

• Defining index properties in a domain class by annotating the properties to be indexed with @Neo4jIndexed
• Using the indexer when the GORM methods ‘findBy<prop>’ or ‘findAllBy<prop>’ are called on an indexed property

The following code example will make that clearer:

import grails.plugins.neo4j.*
@Neo4jEntity
class Car {
   String licenseTag // normal, aka non-indexed property
   @Neo4jIndex
   String color  // indexed property
}

Support for non-declared properties

Since Neo4j is a schema-less database, there is no limitation on what properties are allowed for a certain node. A Grails domain model is much more strict on this. To fill this gap, the plugin supports non-declared properties:

def car = new Car(licenseTag:'ABC123', color:'red')
car.save()
assert 'red' == car.color // declared property
assert null = car.numberOfSeats // N.B: numberOfSeats is _not_ declared
car.numberOfSeats = 5
assert '5' == car.numberOfSeats

Using non-declared properties has one limitation: since there’s no type information available, they are stored as String. That’s why the last assert need ‘5′ in quotes.

Support for traversers

A very powerful method to search and find nodes in the nodespace are traversers. The plugin supports them on two levels:

• static:  DomainClass.traverse uses the reference node as starting point and
• instance: <domainClassInstance>.traverse uses the domainClassInstance as starting point.

Both variants come with some overloaded implementations:

traverse(StopEvaluator stopEvaluator, ReturnableEvaluator returnableEvaluator, Object... args)
traverse(Traverser.Order order, StopEvaluator stopEvaluator, ReturnableEvaluator returnableEvaluator, Object... args)
traverse(Closure stopEvaluator, Closure returnableEvaluator, Object... arg)
traverse(Traverser.Order order, Closure stopEvaluator, Closure returnableEvaluator, Object... args)

Note that StopEvaluators and ReturnableEvaluator might be coded in a ‘groovy’ way as closures:

def traverser = car.traverse(
 { true },  // StopEvaluator
 { it.currentNode().getProperty("color",null)=="red"} // ReturnableEvaluator
)

One thing I have been struggling with is synchronizing my PIM data. On the notebook or desktop computer I’m using thunderbird together with the lightning extension (and some other useful addons) holding my contact and calendar data. This stuff should be synced to and from the N900.

The N900’s default solution for syncing is Nokia’s PC suite. Since I’m on Linux, this is no option at all. I tried to use Opensync – without succeeding. A few days ago the InternetTabletBlog published a great german article on syncing the N900 against ScheduleWorld.com. Using this information, it was pretty simple to adopt the procedure to work with Funambol.

Setting up Funambol

The installation procedure of the Funambol server is very well documented, so I’ll cover here only the main steps without going into detail.

• Download the Funambol Server from https://www.forge.funambol.org/download/
• sudo sh ./funambol-8.0.2.bin installs the server software by default to /opt/Funambol
• startup the server: /opt/Funambol/bin/funambol start
• Using funambol’s admin tool, set the server’s URL to a reasonable value
• check if http://<servername>:8080/funambol/ds return a page like this:

  Funambol Data Synchronization Server v.8.0.1
  
  Man=Funambol
  Mod=DS Server
  SwV=8.0.1
  HwV=-
  FwV=-
  OEM=-
  DevID=funambol
  DevTyp=server
  VerDTD=1.2
  UTC=true
  SupportLargeObjs=true
  SupportNumberOfChanges=true
  Ext=X-funambol-smartslow

Setup thunderbird

• Install Funambol Mozilla Sync Client and configure it to use the URL from the previous step.
• Provide an arbitrary login and password, Funambol adds an user accout automatically.
• Run the sync, your PIM data should now be copied to the Funambol server
• Check if data was transferred by logging into http://<yourserver>:8080/funambol/webdemo

Configuring the N900

This is described in detail here, so I’ll just repeat the main steps:

• install syncevoltion from http://people.debian.org/~ovek/maemo/syncevolution_0.9.1-0_armel.deb
• create a syncevoltion profile:

  syncevolution -c Funambol

• edit the config file of the created profile to match your setup:

  leafpad /home/user/.config/syncevolution/Funambol/config.ini

• run the sync:

  syncevolution Funambol

… and hopefully your done.