LD.

Grails, WebTest and JQuery.

Thu, 11 Mar 2010 15:16:30 +1100

The recently released grails-webtest 2.0.2 now installs WebTest via dependency resolution.

This allows you to work around the HTMLUnit 2.4 incompatibility with JQuery. WebTest 3.0 depends on HTMLUnit 2.4, but we can force the use of HTMLUnit 2.5 which works with JQuery.

Simply add it as a dependency in your app.

grails.project.dependency.resolution = {
    inherits "global"
    log "warn"

    repositories {
        grailsHome()
        mavenCentral()
    }
  
    dependencies {
        test('net.sourceforge.htmlunit:htmlunit:2.5') {
            excludes 'xalan' // IVY-1006 - use xalan 2.7.0 to avoid (see below)
            excludes 'xml-apis' // GROOVY-3356
        }
        test('xalan:xalan:2.7.0') {
            excludes 'xml-apis' // GROOVY-3356
        }
    }
}

Scoped Services & Proxies in Grails

Tue, 09 Mar 2010 21:46:00 +1100

Grails has supported “scoping” services for as long as I have been working with it. Surprisingly, you very rarely here of people using this feature. For my money, it’s one of the lowest cost techniques available to avoid the inherent spaghetti in referencing the session and request (for all intents and purposes) global objects.

This feature is built on top of Spring’s bean scoping. However, you don’t need to know much Spring to get value out of this in Grails.

Scoping a service is as simple as declaring a static scope property with the name of the desired scope…

class MyScopedService {
    static scope = 'session'
}

So now, for each distinct session there will be a distinct instance of MyScopedService in our application.

A shopping cart as a service

An easy to understand use case for this might be a shopping cart…

class CartService {
    static scope = 'session'
    
    
    void addCartItem(cartItem) {
        // …
    }
    
    def getPrice() {
        // …
    }
}

We would use this in our controller like so…

class CartController {
    
    def cartService
    
    def addItem = {
        cartService.addItem(/* cart item */)
    }
    
    def price = {
        println "Cart price is: " + cartService.price
    }
}

You might be wondering just which session that cartService belongs to. Grails controllers are prototype scoped beans (which means a new one is created whenever it is retrieved from the application context) and only ever created inside of a request environment. Therefore, a Grails controller always lives within the context of a session. So when the controller instance is created by Grails at the start of the request, it can be injected with the instance of cartService that correlates to the session that the request is for.

But what about objects that don’t live inside a request (like taglibs)? For that we need a scoped proxy.

Using proxies to deal with scope differences

So we want to have a taglib that renders the current price of the shopping cart. We could pass the cartService instance to the view layer via our controller action and then pass it to the taglib, but that gets tiresome real quick when you start doing it for lots of actions. Since our cart is now a Spring managed bean we could try adding it as a dependency of our taglib…

class CartTagLib {
    
    def cartService
    
    def price = {
        out << cartService.price
    }
}

If you try and do this you are going to get…

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'cartService': Scope 'session' is not active for the current thread;

Grails taglibs are singleton scoped so are created at application startup when the notion of session doesn’t make any sense. What we can do though is create a singleton proxy that delegates to the relevant cartService object at execution time (taglibs are always executed during a request so there will be session when the tag is executed).

With Grails 1.2 and earlier, we have to create this proxy manually by adding this to grails-app/conf/resources.groovy…

import org.springframework.aop.scope.ScopedProxyFactoryBean

beans = {
    cartServiceProxy(ScopedProxyFactoryBean) {
        targetBeanName = 'cartService'
        proxyTargetClass = true
    }
}

This, in effect, creates a singleton bean, which is a dynamically generated subclass of CartService, that delegates method/property calls to the cartService instance stored in the session. Check out Spring’s docs on scope proxies if you want more information on this.

Now we just rewrite our taglib to use our proxy…

class CartTagLib {
    
    def cartServiceProxy
    
    def price = {
        out << cartServiceProxy.price
    }
}

You can now use your cartServiceProxy anywhere like other services or filters. As long as the code that calls cartServiceProxy is executed in a request environment everything will work as expected in a completely thread safe manner.

Some notes on Grails 1.3 improvements

Grails 1.3 will make scoped beans even more attractive by removing the need to define your own proxies. All you will have to do is…

class CartService {
    static scope = 'session'
    static proxy = true
}

To have a proxy named cartServiceProxy created for you. You can track this new feature via the Grails issue tracker.

Grails 1.3 will also support scoped tag libs in the same manner as services.

Testing and scoped services

When integration testing scoped services, you need to be aware of the request/session lifecycle semantics.

Each test method is run in it’s own unique environment. This means two things; you must use a proxy to access a request or session scoped in a test, and each test method will have it’s own distinct underlying service instance.

class SomeTests extends GroovyTestCase {

import grails.plugin.spock.*

class ScopedServiceSpec extends IntegrationSpec {
 
    def sessionScopedServiceProxy
    def requestScopedServiceProxy
    
    void test1() {
        expect:
        sessionScopedServiceProxy.property == null
        requestScopedServiceProxy.property == null
        when:
        sessionScopedServiceProxy.property = 1
        requestScopedServiceProxy.property = 1
        then:
        sessionScopedServiceProxy.property == 1
        requestScopedServiceProxy.property == 1
    }

    void test2() {
        expect:
        sessionScopedServiceProxy.property == null
        requestScopedServiceProxy.property == null
        when:
        sessionScopedServiceProxy.property = 2
        requestScopedServiceProxy.property = 2
        then:
        sessionScopedServiceProxy.property == 2
        requestScopedServiceProxy.property == 2
    }
}

Why use scoped services and proxies?

For me it’s really about expressing intent. Some aspects of your application, like a shopping cart, are so pervasive that they end up everywhere in your code. It’s very hard to track down who is getting something from or setting something in the session or request objects in controllers, taglibs or filters. If you use scoped services, it’s very easy to see who is doing what. I can tell a controller does something with the cart because I see def cartService at the start of the class. That’s easier to spot than session.cart buried in an action. I also find it allows me to stay more focussed in the language of my problem domain.

Scoped services are a great tool to have in your arsenal. In an upcoming post, I’ll be discussing using custom scopes or lifecycles for your scoped services.

Configuration based Spring bean definition with Grails.

Tue, 09 Mar 2010 10:42:53 +1100

I released a new version of the Grails JMS plugin (0.5) over the weekend. This release features completely rewritten internals to expose every configuration aspect of the underlying Spring JMS classes. JMS is a complicated topic with lots of setup and configuration options so this level of access is necessary.

What’s novel about the approach is that it allows users to configure the underlying beans via the Grails application config, rather than via direct Spring bean configuration. This has the advantage of being more generally accessible as a lot of Grails developers still shy away from directly configuring beans. It also has the advantage of allowing the plugin to assert a certain level of control over the bean definitions.

A little bit about Grails JMS

The plugin makes it convenient to specify service methods as JMS listeners.

import grails.plugin.jms.Subscriber

class ListeningService {
    
    @Subscriber
    void interestingStuff(payload) {
        
    }
    
}

Whenever a message is sent to the topic “interestingStuff”, the message will be delivered to this service method.

There are two aspects to receiving JMS messages with Spring’s JMS support; containers and adapters. For each listener there is a distinct container and adapter pair. In a plain Spring app, you would configure a pair of these beans to receive your messages. If you have a look at those classes, there are a lot of config options. The goal of this plugin release was to give you access to those options should you need it, but not force you to define everything yourself.

The @Subscriber annotation has container and adapter parameters that default to "standard". These parameters are the names of the abstract beans that the concrete listener and adapter instances shall inherit from. There are implicit suffixes though; a container value of "standard" actually means the bean standardJmsListenerContainer and so forth. The plugin does force some properties on the concrete instances, but very few. The majority of configuration is controlled by the abstract base.

Config based bean definitions

The other half of the story is how the beans are defined based on the config. This is driven by the MapBasedBeanDefinitionBuilder that takes a name and Map of properties a certain format and registers a bean based on the map data. There are also certain MapBasedBeanDefinitionBuilder subclasses in the plugin like JmsListenerContainerAbstractBeanDefinitionBuilder that specialise in creating certain types of beans.

The default set of beans configurations look like this…

import org.springframework.jms.support.converter.SimpleMessageConverter
import org.springframework.jms.listener.DefaultMessageListenerContainer

templates {
    standard {
        connectionFactoryBean = "jmsConnectionFactory"
        messageConverter = new SimpleMessageConverter()
    }
}
containers {
    standard {
        concurrentConsumers = 1
        subscriptionDurable = false
        autoStartup = false
        connectionFactoryBean = "jmsConnectionFactory"
        messageSelector = null
        cacheLevel = DefaultMessageListenerContainer.CACHE_SESSION
    }
}
adapters {
    standard {
        messageConverter = new SimpleMessageConverter()
        persistenceInterceptorBean = 'persistenceInterceptor'
    }
}

The details aren’t important. The point is to illustrate the syntax.

Overriding defaults

This default config gets merged with the application config under the jms key (e.g. grailsApplication.config.jms). So to override the standard container to use a different connection factory we would have the following in our Config.groovy

jms {
    containers {
        standard {
            connectionFactoryBean = "someOtherJmsConnectionFactory"
        }
    }
}

Because Config.groovy is environment aware, we can also do things like

environments {
    development {
        jms.containers.standard.connectionFactoryBean = "someOtherJmsConnectionFactory"
    }
    test {
        jms.containers.standard.connectionFactoryBean = "testJmsConnectionFactory"
    }
}

You could even change the class of the default container definition.

jms {
    containers {
        standard {
            meta {
                clazz = SomeOtherListenerContainer
            }
        }
    }
}

Additional Beans

This mechanism also supports having more than one container type

jms {
    containers {
        other {
            meta {
                parentBean = "standardJmsListenerContainer"
            }
            connectionFactoryBean = "otherJmsConnectionFactory"
        }
    }
}

This creates a new container type called other that inherits all of the configuration from the standard container, but overrides the connection factory.

You would then use this container by specifying the container on the listener.

import grails.plugin.jms.Subscriber

class ListeningService {
    
    @Subscriber(container = "other")
    void interestingStuff(payload) {
        
    }
    
}

The Point

The point of this article is not specifically to talk about the JMS plugin. This approach to bean configuration seems to work quite well when users need access to the underlying beans in an optional manner. This may be an approach that other plugin authors might want to adopt.

Using Grails's JSON support with HTTPBuilder

Thu, 25 Feb 2010 13:01:00 +1100

I am currently working on a set of JSON over HTTP web services APIs between Grails applications. Producing JSON content in Grails applications is ridiculously trivial, but the story on consuming content is not so clear.

I am using Tom Nichol’s HTTPBuilder for consumption. It’s a great library, but does take a little getting used to. Fortunately, the documentation is excellent.

HTTPBuilder ships with JSON support based on Andres Almiray’s json-lib. That works fine, but I was worried about a potential impedance mismatch between json-lib’s encoding/decoding and Grails’.

Here’s how I configured HTTPBuilder to use Grails’ JSON bits for encoding/decoding JSON data…

import groovyx.net.http.HTTPBuilder
import groovyx.net.http.ParserRegistry
import groovyx.net.http.ContentType.JSON

import org.apache.http.entity.EntityTemplate
import org.apache.http.entity.ContentProducer
import org.apache.http.message.BasicHeader

// create a builder instance
def builder = new HTTPBuilder()

// the closure that takes a HttpServletResponse and returns an object
def jsonParser = { response ->
    grails.converters.JSON.parse(new InputStreamReader(response.entity.content, ParserRegistry.getCharset(response)))
}

// the closure that takes an object and returns an org.apache.http.HttpEntity
def jsonEncoder = { value ->
    def json = value instanceof Closure ? new grails.web.JSONBuilder().build(value) : new grails.converters.JSON(value)
    def producer = [writeTo: { OutputStream out -> out.withWriter { json.render(it) } }] as ContentProducer
    def entity = new EntityTemplate(producer)
    entity.contentType = new BasicHeader("Content-Type", JSON.toString())
    entity
}

// for each JSON content type, install the handler
JSON.contentTypeStrings.each {
    builder.parser."$it" = jsonParser
    builder.encoder."$it" = jsonEncoder
}

Note that you have to configure each created HTTPBuilder instance.

Here is some contrived example usage. We are calling a JSON “mirror” service that simply just returns the JSON it was sent.


import grails.plugin.spock.*

import groovyx.net.http.Method.POST
import groovyx.net.http.ContentType.JSON

class HttpBuilderWithGrailsJsonSpec extends UnitSpec {

    void "test it all works like it should"() {
        given: "a configured HTTP builder"
        def builder = new HTTPBuilder("http://jsonmirror.org")
        // configure the builder as per above
        
        when: "I post '{a: 1}' to the JSON mirror service"
        def requestMethod = POST
        def responseContentType = JSON
        def result = builder.request(requestMethod, responseContentType) {
            def requestContentType = JSON
            send(requestContentType) {
                a = 1
            }
        }
        
        then: "I get the JSON '{a: 1}' returned"
        result.a == 1
    }
}

Automatically packaging inline plugins in Grails 1.2

Tue, 23 Feb 2010 19:09:18 +1100

Working with module Grails applications via in-place plugins is currently not as convenient as it could be. One of the major sticking points is the need to package-plugin all of your inline plugins manually before using them in your application’s build.

If you try to build your app without packaging your in-place plugins first you will see something like…

The inplace plugin at [«plugin path»] does not have a plugin.xml. Please run the package-plugin command inside the plugin directory.

This gets tiresome real quick when you have a lot of in-place plugins. Fortunately the workaround isn’t too bad.

Add a build event listener

Add the following to scripts/_Events.groovy…

eventInitInplacePluginsStart = {
    pluginSettings.inlinePluginDirectories.each { resource ->
        if (!new File(resource.file, 'plugin.xml').exists()) {
            def descriptor = pluginSettings.getDescriptorForPlugin(resource)
            generatePluginXml(descriptor.file)
        }
    }
}

That’s going to generate any missing plugin.xml’s for you… but there is a catch

Lazily load classes in the plugin descriptor

The event code above has to compile the *GrailsPlugin.groovy plugin descriptor in order to read the metadata to generate the plugin.xml. This is done before the classes in the plugin are compiled and therefore any classes that you import in your plugin descriptor are not going to be available.

The solution is to load the classes lazily via the application classloader…

class MyGrailsPlugin {

    def version = "0.1"
    def grailsVersion = "1.2.* > *"

    def doWithSpring = {
        def awesomeClass = application.classLoader("grails.plugin.my.Awesome")
        // …
    }
}

While this is slightly inconvenient, it beats manually running package-plugin in a bunch of directories.

The good news

This issue is well known about, but the fix is non trivial. It will be fixed for Grails 1.3 though.

Instantiating the right class in Groovy dynamic constructors

Sun, 21 Feb 2010 12:46:00 +1100

I just came across some Groovy code that essentially looks like this…

def installConstructor(Class clazz) {
    clazz.metaClass.constructor = { Map params ->
        def instance = clazz.newInstance()
        // do some stuff with params
        instance
    }
}

Looks innocent at first right?

Consider this…

class Parent {}
class Child extends Parent { String name }

ExpandoMetaClass.enableGlobally() // enable metaclass inheritance

installConstructor(Parent)
def c = new Child(name: "LD")

The issue here is that c is not going to be what you expect. You are going to get back an instance of Parent from this constructor call because our newly added constructor added to Parent is hardcoded to return Parent instances.

The fix is easy…

def installConstructor(Class clazz) {
    clazz.metaClass.constructor = { Map params ->
        def instance = delegate.newInstance() 
        // do some stuff with params
        instance
    }
}

For a dynamic constructor implementation, delegate refers to the actual target class of the construction. So unless you are doing some really wild stuff and deliberately returning objects of a different class, you always want to use delegate as the target class.

Brute force fixture cleanup in Grails

Fri, 19 Feb 2010 17:09:23 +1100

I am currently working on establishing a suite of functional tests. I am using the functional test features of the spock plugin to do this, which I’ll be writing more on in the near future.

Naturally, I am using the fixtures plugin to load my test data in the functional tests. However, the plugin provides no support for tearing down data. You generally don’t need to worry about this in integration tests because integration tests are by default wrapped in rollback-only transactions. This is not possible due to the nature of functional tests though.

In order to get something up and running quickly, I implemented this…

import groovy.sql.Sql
import grails.plugin.spock.FunctionalSpec

abstract class FunctionalSpecSupport extends FunctionalSpec {

    def dataSource
    def sessionFactory
        
    def cleanup() {
        sessionFactory.currentSession.flush()
        def sql = new Sql(dataSource)
        sql.execute("SET FOREIGN_KEY_CHECKS = 0")
        grailsApplication.domainClasses.each { domainClass ->
            sql.execute "DELETE FROM " + sessionFactory.getClassMetadata(domainClass.clazz).tableName
        }
        sql.execute("SET FOREIGN_KEY_CHECKS = 1")
        sessionFactory.currentSession.clear()
    }
    
}

All of my actual functional tests extend this FunctionalSpecSupport class. The cleanup() method is to Spock what tearDown() is to standard JUnit tests. That is, it’s invoked after every test. Also, due to historical reasons the project I am working on uses MySQL so the SQL above may be specific to that DB, I don’t know.

That lacks finesse, but it get’s the job done.

Integration Testing Grails Filters

Tue, 16 Feb 2010 15:54:00 +1100

Grails currently doesn’t ship with any support for testing filters, other than via a functional test. It’s pretty easy to roll your own filter integration tests though.

Here is an example:

import grails.util.GrailsWebUtil

class MyFilterTests extends GroovyTestCase {
    
    def filterInterceptor
    def grailsApplication
    def grailsWebRequest
    
    def request(Map params, controllerName, actionName) {
        grailsWebRequest = GrailsWebUtil.bindMockWebRequest(grailsApplication.mainContext)
        grailsWebRequest.params.putAll(params)
        grailsWebRequest.controllerName = controllerName
        grailsWebRequest.actionName = actionName
        filterInterceptor.preHandle(grailsWebRequest.request, grailsWebRequest.response, null)
    }
    
    def getResponse() {
        grailsWebRequest.currentResponse
    }
    
    def testFilterRedirects() {
        def result = request("home", "index", someParameter: "2")
        assertFalse result
        assertTrue response.redirectedUrl.endsWith(/* something */)
    }
    
}

Note that filterInterceptor.preHandle() executes all of your filters, which is what you really want in an integration test. It also returns the return value of the last executed filter. When issuing a redirect, we return false in our filter handler to prevent any further request processing so we are testing for that here.

If you are interesting in unit testing your filters, you might want to check out the mailing list thread on the topic.

Dealing with common test support across test types

Tue, 16 Feb 2010 13:08:10 +1100

Grails ships with several different test superclasses to make your testing life easier. This is great, but what if you have your own common testing bits that you want to provide in a superclass? Even worse, what if you are using the Spock plugin and have a completely different class hierarchy to work with?

The current project I am working on has a mix of Spock and JUnit tests of different types. Most of the tests also require some relatively common context establishment regardless of the test type. The solution I came up with was to use a test support object instead of a super class. That might seem straightforward, but it gets interesting when you need dependency injection.

Let’s take a look at the test support class…

import org.codehaus.groovy.grails.commons.ApplicationHolder

class TestSupport { 
    
    @Lazy fixtureLoader = getBean('fixtureLoader')
    @Lazy someOtherService = getBean('someOtherService')
    
    protected getBean(name) {
        ApplicationHolder.application.mainContext[name]
    }
    
    def loadFixture(fixtureParams) {
        // load fixture here
    }
    
    // Other common methods and stuff
}

Why the use of ApplicationHolder to get at the application context and the beans? Well, we are trying to avoid mixing test and production code by having the TestSupport class in tests/integration, which means we can’t make it a service. We also can’t selectively create an autowired instance via grails-app/conf/resources.groovy because classes in tests/integration are not available to the classloader that deals with loading the application context. So while the use of the static holder bothers me, it’s the only tool we have to get the job done at the moment. Also, not the use of Groovy’s @Lazy transformation.

Here is how I use the test support class in a Spec…

import grails.plugin.spock.*

class SomeSpec extends IntegrationSpec {
    
    @Delegate TestSupport testSupport = new TestSupport()
    
    def "some stuff should happen"() {
        given:
        loadFixture(/* fixture options */)
        when:
        someOtherService.doStuff()
        then:
        someOtherService.stuffHappened
    }
    
    def "some other stuff should happen"() {
        given:
        loadFixture(/* fixture options */)
        when:
        someOtherService.doOtherStuff()
        then:
        someOtherService.otherStuffHappened
    }
}

The use of Groovy’s @Delegate transformation makes the actual test code look like it’s using a support superclass, but it isn’t, which is the whole point of this exercise. You can now use your common test support methods in any kind of test case.

Panic! At The Disco: Pretty Odd

Sat, 13 Feb 2010 19:03:16 +1100

A very underrated album that kind of slipped past without much fanfare. I despised these guys from their first single. It dropped around the same time My Chemical Romance were getting airplay and there was way too much guyliner and mascara going on. Shitty Emo fashion aside the first album was ok. Not great, but ok. This one really shines though.

It plays like a modern day Sgt. Peppers with solid arrangement and unexpected musicianship. If you enjoy melodically rich tunes and can get past the band’s image and persona then I recommend checking it out.

Providing non-domain validateables in Grails plugins.

Wed, 10 Feb 2010 15:50:00 +1100

Grails now (1.2+) supports making arbitrary classes validateable. This is easy enough, but what if you have a plugin with a non-domain class that needs to be validateable?

What you might try is adding the necessary config into the Config.groovy in your plugin. This is not going to work though because that’s not going to be sourced when your plugin is deployed into an application.

So here’s a solution:

package grails.plugin.radness

class RadnessGrailsPlugin {
    def loadBefore = ['validation'] // important

    def doWithDynamicMethods = {
        if (!application.config.grails.validateable.classes) {
            application.config.grails.validateable.classes = []
        }
        application.config.grails.validateable.classes << RadnessValidateable
    }
}

The RadnessValidateable class gets configured with all the validation bits. You don’t need to annotate the class with org.codehaus.groovy.grails.validation.Validateable, the above is enough to make it work.

TextMate Interactive Input and Snow Leopard

Thu, 10 Sep 2009 21:14:00 +1000

I had some fun today upgrading tm_interactive_input.dylib to make it work with Snow Leopard. Previously, it was busted in a pretty decent way.

I can’t be exactly sure, but it seems that malloc() on Snow Leopard calls read() for some strange reason. Since our overloaded read() implementation does quite a few things, including a lot of malloc()ing we have a problem. The end result was that anything loaded with our library injected explodes.

The solution was to use a thread local flag via the pthreads thread local storage to mark when we entered any of our overloaded code paths. This is simple enough, but I couldn’t for the life of me getting working due to a nasty issue which I hadn’t anticipated.

To use the pthread library’s thread local storage stuff, you need to create a token using pthread_key_create() which you can later use to retrieve a thread specific value for. So in C library, how do you handle initialisation code? It turns out that library constructors solve this exact problem.

News to me.

So I initialise the key in a library constructor and litter my code with the appropriate checks and so forth. No dice. I am still seeing the exact same behaviour. To make things more interesting I can’t use GDB because of the nature of the library and I can’t use printf statements because they use malloc() internally which just exacerbates the problem. I can however use write(), so that’s something.

After littering the code with write()s, I discovered that my read() implementation is being called before my library constructor. I don’t know why this is the case but I am guessing that somehow the dynamic linker has made the overloaded functions in our library available to the host binary during the loading process. Either that, or the linker itself is calling our overloaded functions. Either way, kinda strange.

Once I worked out that this was going on, it was trivial to fix. Simply set an ‘initialised’ flag in our library constructor and don’t use our overloaded functions until that is set.

GitHub has the commit for more info, or grab the binary directly (see here for install instructions).

This should be included in the next TextMate distribution.

Reclaim your home life with AppleScript

Sun, 06 Sep 2009 23:25:00 +1000

Anyone using Mail.app to both work and home combined with MobileMe sync is probably like me and unable to avoid reading work email when at home because you just can’t resist taking a look when you see something new there. A co-worker came up with a good solution to this problem: stop Mail.app from checking for new email in your work account during non work hours.

Here is a simple AppleScript you can use to take an account out of the auto fetch schedule:

tell application "Mail"
    set include when getting new mail of account "account name" to false
end tell

Why I do Open Source

Mon, 26 Jan 2009 21:20:00 +1100

(This was inspired by Andres Almiray)

I did not have a lot of exposure to Open Source software during my formative computing years. I come from a Classic Mac OS (I saw the last few releases of 7) background and was blissfully ignorant to Linux. The move to OS X exposed me to a plethora of previously unavailable software and during this time I was becoming interested in coding. As a student surrounded by other “Computer Scientists” who were interested in anything but coding, my only real available avenue for growth was to participate in virtual communities of developers.

While it wasn’t an intentional move, the ideals and general culture of typical open source developer communities resonate very naturally with me (open information, need before greed etc). Also, I am attracted to the artistic side of writing software as opposed to just being in it for the utility. In my experience (which granted isn’t vast) you can find extremely talented people who are true artists, not just laborers, gathered around open source projects. If you are putting your work up in front of these people then you are forcing yourself to improve, and to me that is what it’s about.

I am sure not all Open Source Software is of a high calibre, but I bet you that in almost every case that man hour for man hour an open source project will trump a closed commercial project in terms of quality almost every time. If you want to improve your skills, hang out with the best around.

Apart from this self interested reason, I also enjoy creating software that other people use. There is not much better than getting an email from someone you don’t know and them thanking you for the hours you put into something because it has helped them achieve something.

Gldapo Validation

Wed, 03 Dec 2008 20:52:00 +1100

I am about to commit the new GORM inspired validation mechanism to Gldapo. Here is what it is going to look like…

Declaring your constraints

Instead of a DSL like GORM, we are using annotations…

import gldapo.schema.annotations.

class Person {

    @GldapoNamingAttribute 
    String uid

    @Required
    String sn

    @Required
    @Matches(/[A-Z]./)
    String givenName
}

Plugging in your own constraints

You can register your own constraints quite easily. There are two parts, the constraint annotation and the validator.

The constraint annotation (has to be in Java since you can’t define annotations in Groovy 1.5.x)…

import java.lang.annotation.*;
import gldapo.schema.annotation.Validator;
import gldapo.schema.attribute.validator.EqualsValidator;

@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
@Validator(EqualsValidator) // 
public @interface Equals
{
    Object value();
}

As you can see it’s a stock standard annotation, that is itself annotated with @Validator to tell Gldapo how to validate this type of constraint.

The validator looks like this…

package gldapo.schema.attribute.validator

class EqualsValidator extends AbstractFieldValidator {

    def validate(obj) {
        if (obj != this.constraint.value()) {
            return ['notequals', "notequals.${this.constraint.value()}"]
        }
    }

}

Validators have to extend gldapo.schema.attribute.validator.AbstractFieldValidator and implement validate(obj). This method takes the value to validate and returns either a single error code, or a list of error codes. If the value is valid it should return null.

Gldapo will register several error codes if validation fails. If a class called Person has it’s name field annotated with @Equals('Luke') and it fails validation, the following error codes will be registered…

notequals
notequals.Luke
person.notequals
person.notequals.Luke
person.name.notequals
person.name.notequals.Luke

If the usage of error codes seem a bit weird here, then you should check out 7.4 Validation and Internationalization in the Grails user guide as the concept is exactly the same.

Finally, you need to register your constraint with Gldapo. You do this by listing your custom constraint types as a list under the contraintTypes key in the config…

Gldapo.initialize(
    contraintTypes: [Equals]
)

Performing validation

This side of things works exactly like GORM…

def p = new Person(uid: "ld", givenName: "Luke" sn: "Daley")
    if (!p.save()) {
        p.errors.allErrors.each {
            println it
        }
    }

There is also the validate() method if you just want to perform validation without trying to write the object back.

If you haven’t used validation in GORM, check out this chapter in the user guide, because it will all hold true (except how constraints are defined) with Gldapo.

Grails TextMate bundle is being improved

Sun, 21 Sep 2008 22:01:00 +1000

I am working on a grails app (more info to come), as such I am making some long needed improvements to the Grails TextMate bundle. If you are using this, you might want to subscribe to the bundle changes feed.

I have made two changes already; a snippet for the tag in GSPs, and a command to run a single test case (the currently open file in TM).

Gldapo 0.7.1 Released

Sun, 21 Sep 2008 21:52:51 +1000

This release has only one change which fixes an issue with password attributes.

Gldapo 0.7 Released

Sun, 24 Aug 2008 01:29:08 +1000

Gldapo 0.7 (and a corresponding grails plugin) is now available.

This release primarily fixes some bugs with password attributes and brings the following major features/improvements:

The addition of an LDAP filter DSL (thanks to Siegfried Puchbauer)
Drastic improvement to the API for creating and moving objects.
JavaDoc for commonly used classes (thanks to new GMaven features)

Release Notes

Sub-task

[GLDP-66] - Base the location of entries in the directory on a ‘parent’ directiory rather than the ‘rdn’ attribute
[GLDP-69] - Make defining a naming attribute mandatory (i.e. throw exception if none defined)
[GLDP-70] - Add documentation for @GldapoNamingAttribute
[GLDP-79] - Raise exception if rdn is set with a different naming attribute
[GLDP-82] - Raise exception if naming attribute is changed directly (i.e. not via move() or replace())
[GLDP-86] - Create ‘GldapoEntry’ abstract base class and document

Bug

[GLDP-76] - Converting raw array values to native (groovy) values with schema-custom mapper raises GldapoTypeMappingException
[GLDP-77] - Reading an entry with a password attribute raises exceptions
[GLDP-81] - Static properties on schemas are not ignored
[GLDP-91] - GldapoSynonymFor breaks GldapoNamingAttribute

Improvement

[GLDP-47] - When moving/replacing an object, the in memory value of the naming attribute should be updated to reflect the change
[GLDP-58] - Fix JavaDoc generation and use that as the definitive documentation source
[GLDP-60] - Sanitise API for replacing/moving objects
[GLDP-72] - Consolidate overloaded rdn setter on schema objects
[GLDP-73] - Fetch raw values from contexts as objects, not strings
[GLDP-74] - Implement tests for schema-custom TO FIELD type mappers
[GLDP-75] - Implement tests for schema-custom TO TYPE type mappers
[GLDP-87] - Rename ‘rdn’ property to ‘brdn’

New Feature

[GLDP-41] - Provide way to name object based on particular attribute
[GLDP-68] - Add a Filter DSL to ease LDAP querying
[GLDP-71] - Support password type attributes
[GLDP-78] - Add ‘namingValue’ property to entries
[GLDP-83] - Add move(String,Object) method to move an object by naming value and parent
[GLDP-84] - Add replace(String,Object) method to replace an object by naming value and parent
[GLDP-85] - Add replace() method
[GLDP-89] - Provide find() and findAll() variants that take a filter builder closure
[GLDP-90] - Typemapping for Boolean type

Enjoy.

New Java and JavaDoc TextMate bundles

Sat, 05 Jul 2008 03:57:00 +1000

Finally, I got the new Java and JavaDoc TM bundles up to scratch and got them promoted from review.

If you are using TM for Java, you’ll want to update your bundle.

Moving/Replacing entries with Gldapo 0.7

Fri, 04 Jul 2008 05:30:29 +1000

Following on from the previous post, Gldapo 0.7 makes dealing with the location of LDAP objects much easier. This impacts the move() and replace() methods. I’ll focus on replace() here, but pretty much everything applies to move().

0.7 introduces a new signature of replace(String namingValue, Object parent). Let’s look at some usage then I’ll explain.

What we want to do here is replace an object with cn=Luke and sn=Daily with an object with sn=Daley (note: we could do this with a search, mod, save admittedly, but this is just an example).

I am using the person schema class from the previous post.

First, 0.6 style…

def p = new Person(
    cn: "Luke",
    sn: "Daley"
)

p.replace("cn=Luke")

In 0.7…

def p = new Person(
    sn: "Daley"
)

p.replace("Luke", null)

Or…

def p = new Person(
    cn: "Luke",
    sn: "Daley"
)

p.replace()

Because we now know which attribute defines the name, we don’t need to duplicate that information in the replace() call.

The second argument to replace(String,Object) is the parent of the object to replace. Say we wanted to replace an object in a different ou…

p.replace("Luke", "ou=people")

The move(String,Object) method follows similar semantics. Note though that there is no move() method, cause that just wouldn’t make sense.