Archive

Archive for the ‘grails’ Category

Funktionale Webtests mit Geb @ jaxenter.de

December 21, 2010 1 comment

Auf Jaxenter [0] ist ein Artikel von mir ├╝ber Geb [1], einem neuen Webautomations- und Testframework auf Basis von Groovy und Seleniums WebDriver API, erschienen:

Funktionale Webtests mit Geb

Lesen und gl├╝cklich werden!

[0] Jaxenter – Funktionale Webtests mit Geb
[1] Geb Homepage

Categories: grails, groovy

The Micro Framework Approach

December 3, 2010 5 comments


Flattr this
The demand for Grails and Groovy is clearly raising these days – at least here in Austria and Germany. Although most of my workshops have their individual adaptions (depending on the previous knowledge and programming language experience of participants) there are parts which can more or less be found unmodified in every workshop: Groovy essentials/advanced topics and what I call micro framework examples. This article is about the idea behind micro framework examples and why I find them that useful as workshop examples.

What is a Micro Framework Example?

I strongly believe that true understanding on patterns behind frameworks like Hibernate and Spring can’t easily be treat in a bunch of slides. Explaining patterns is one thing but to actually see how those are applied is another one. One approach I’ve found to be really useful in workshops is the use of micro framework examples. A micro framework example implements the core functionality behind a specific framework – reduced to the very fundamentals. One advantage to implement a micro framework example together with participants is to force triggering a thinking process of what functionality is needed and how it can be implemented. Another side-effect is that it allows to slightly introduce the original frameworks ubiquitous language simply by using the same class and method names.

Let me give you an example. The most threatening topic for many of my clients is to understand Hibernate and its persistence patterns. One approach to create a better understanding would be to implement a micro Hibernate framework example. This can be done in a simple Groovy script MicroHibernate.groovy which defines two classes and a simple test case. The first class implements the registry pattern and is called SessionFactory:

class SessionFactory {

    private def storage

    def SessionFactory(def storage)  {
        this.storage = storage
    }

    def newStorageConnection()  {
        return storage
    }
}

The SessionFactory acts as the main access point to get a reference to some storage connection. In the micro framework example this will simply be a Map. Dealing with SQL or even a real database would uselessly complicate the example and we want to concentrate on the core essentials. Let’s go on to the next class which implements the persistence context pattern:


class Session {

    static Log log = LogFactory.getLog(Session)

    private def sessionFactory

    def Session(def sessionFactory) { this.sessionFactory = sessionFactory }

    def snapshots = [:] // a Map(Domain-Class, Map(Identifier, Properties))
    def identityMap = [:] // a Map(Domain-Class, Map(Identifier, ObjectRef))
    def modifiedPersistentObjects = [:] // a Map(Domain-Class, List(Identifier))
    
    def propertyChanged(def obj)  {
        if (!modifiedPersistentObjects[obj.getClass()]) modifiedPersistentObjects[obj.getClass()] = []

        modifiedPersistentObjects[obj.getClass()] << obj.id

        log.info "propertyChanged of object: ${obj} with id ${obj.id}"
    }

    def load(Class<?> domainClassType, Long identifier)  {
        
        if (identityMap[domainClassType] && identityMap[domainClassType][identifier])  {
            return identityMap[domainClassType][identifier]
        }
        
        def conn = sessionFactory.newStorageConnection()
        def loadedObj = conn[domainClassType][identifier]
        if (!loadedObj) throw new Exception("Object of type ${domainClassType} with id ${identifier} could not be found!")
        
        if (!snapshots[domainClassType]) snapshots[domainClassType] = [:]
        if (!identityMap[domainClassType]) identityMap[domainClassType] = [:]


        def properties = loadedObj.getProperty("props")
        snapshots[domainClassType][identifier] = properties.inject([:], { m, property -> m[property] = loadedObj[property]; m })

        log.info "create snapshot of ${domainClassType} id ${identifier} with properties ${snapshots[domainClassType][identifier]}"

        identityMap[domainClassType][identifier] = loadedObj
        
        loadedObj.metaClass.getId = { -> identifier } 
        loadedObj.metaClass.setProperty = { String name, Object arg ->
            def metaProperty = delegate.metaClass.getMetaProperty(name)

            if (metaProperty)  {
                owner.propertyChanged(loadedObj)
                
                metaProperty.setProperty(delegate, arg)
            }
        }
        
        return loadedObj
    }
}

A Session object can be used to retrieve already persistent objects and to persist so-called transient objects. I like to start by implementing the load method which loads a persistent object from the storage connection of the current session factory. Of course, this is not an example for Groovy beginners but with a little knowledge of MOP and with some programming guidance it should not be a big thing to understand what is going on. At the end let’s define some test case which shows how both classes are actually used:

def storage = [:]

class Person {
    String name

    String toString() { name }

    static props = ['name']
}

storage[Person] = [:]
storage[Person][1 as Long] = new Person(name: 'Max Mustermann')
storage[Person][2 as Long] = new Person(name: 'Erika Mustermann')

def sessionFactory = new SessionFactory(storage)
def session = sessionFactory.newSession()

def person = session.load(Person, 1)

Interestingly, even without considering SQL, DB connection handling, threading issues etc. participants already get a feeling of several Hibernate gotchas beginners otherwise often struggle with:

  • the first level cache
  • the need for proxies or MOP modifications
  • Hibernate’s use of object snapshots
  • the IdentityMap pattern
  • repeatable read transaction isolation level
  • etc.

It is amazing how much can be explained by implementing some framework’s core functionality in about 5 minutes. The Session functionality gets than extended by flush, discard and save/delete functionality. If programmers have been through the process of implementing such a micro Hibernate example they often get a basic and fundamental understanding of how an orm framework could work and what the main challenging problems are. By keeping the class and method names in sync with the concrete Hibernate implementations participants learn the framework’s basic domain language.

GSamples – A Repository for Sharing Workshop Examples

The example mentioned above is available in a public github repository what I called GSamples [0], a collection of Groovy and Grails workshop examples. At the time of publishing this article it contains two micro framework examples, the other one is a simple dependency injection container. In addition, GSamples holds Groovy scripts dealing with Groovy Essentials and another one dealing with advanced Groovy topics like the Meta-Object Protocol and Closures. Feel free to extend, distribute or use it!

[0] GSamples – https://github.com/andresteingress/gsamples

Grails Quickie: How to Load Dependency Sources and Javadocs

November 18, 2010 1 comment

Once you start a new Grails project and you want to access all the source code of dependent libraries, you have to manually reference the according source files. This is a boring, time-consuming and error-prone task – something like mvn dependency:sources is definitely missing. Luckily, there exists a workaround which can be done using the eclipse-scripts [0] plugin:

grails install-plugin eclipse-scripts 
grails compile 
grails download-sources-and-javadocs 
# run twice to download everything 
grails download-sources-and-javadocs 
# grails create-eclipse-files # run this one to create .classpath/.project Eclipse/STS files

Executing download-sources-and-javadocs loads the docs and copies them into the Ivy cache directory.

Thanks to Lari Hotari who came up with this solution on the Grails mailing-list [1].

[0] Eclipse Helper Scripts Plugin
[1] Nabble Grails User Mailing-List – Grails Dependency Sources

Categories: grails, plugins

Happy Messaging with ActiveMQ and SI (Part 1)

October 14, 2010 1 comment


Flattr this
In one of my current projects we needed to set up a communication channel between two distinct Grails applications. One of them is the master application which runs an embedded ActiveMQ message broker [0]. The second one – the slave application – provides service APIs to the master application.

Since Grails heavily relies on Spring, we decided to use Spring Integration as messaging framework [1]. Spring Integration is a messaging framework which supports various Enterprise Application Integration Patterns [2], without being bound to any specific messaging protocol. Since our project team chose to use ActiveMQ we go with JMS as underlying messaging protocol in our project.

Setting up an embedded ActiveMQ message broker

ActiveMQ is a fully JMS 1.1 compliant messaging provider which is available under the Apache Software License. It has quite a bag of features, the most important ones for us where persistent messages support. Besides running ActiveMQ as a distinct server, one can choose to run ActiveMQ as an embedded server inside the application.

Configuring an embedded ActiveMQ broker using Grails’ Beans DSL is pretty straight-forward (once you get used to the Beans DSL of course):

xmlns amq:'http://activemq.apache.org/schema/core'

def brokerName = 'myEmbeddedBroker'

amq.'broker'(brokerName: brokerName, useJmx: true, persistent: false) {
  amq.'managementContext'  {
    amq.'managementContext'(connectorPort: 2011, jmxDomainName: 'embeddedBroker')
  }

  amq.'plugins'  {
    amq.'loggingBrokerPlugin'
  }

  amq.'transportConnectors'  {
    amq.'transportConnector'(name: 'openwire', uri: 'tcp://localhost:61616')
  }
}

The code above configures an embedded broker called myEmbeddedBroker which only persists messages in-memory (persist: false), exposes itself as JMX bean (useJmx: true) and configures a transport connector using Openwire over TCP.

In order to let the master application (which holds the configuration above) connect to its embedded message broker, we need to set up a connection factory:

connectionFactoryLocal(ActiveMQConnectionFactory)  {
  brokerURL = "vm://${brokerName}"
}

After all, we will define two message queues one for outgoing API requests to the slave application and one for incoming responses:

"requestQueue"(org.apache.activemq.command.ActiveMQQueue, "QUEUE.REQUEST")
"responseQueue"(org.apache.activemq.command.ActiveMQQueue, "QUEUE.RESPONSE")

Spring Integration comes into play

So far we have set up an embedded message broker which could be used for plain JMS API message exchange. In our project we decided to go with Spring Integration because it already implements several EAI patterns (e.g. router, gateway, etc.) and abstract from the underlying messaging protocol.

A reference manual on Spring Integration can be found at [3], but let me give you a short introduction. Spring Integration (SI) is a messaging framework which implements patterns found in the book Enterprise Application Integration Patterns [4]. That is, SI is all about messages and message exchange. To exchange a message from point A to point B there needs to be a channel between A and B. Besides messages, channels are the second most important domain entity in SI.

Channels are injected into your application components just like any other Spring bean. The basic MessageChannel interface is pretty rudimentary:

public interface MessageChannel {

	boolean send(Message<?> message);
	boolean send(Message<?> message, long timeout);
}

The use-case in our project was to automatically create a message and send it to some preconfigured channel whenever the programmers chooses to call a service API method:


def someApi

def doSomething()  {   
   someApi.executeRemotely('first param', 'second param') // this should trigger message creation and sending/receiving
}

A call to executeRemotely should automatically create a message object from the input parameters and send it to some sort of API request channel.

Luckily, SI provides the concept of gateways which solve that particular problem. At runtime, a gateway is a proxy object for a particular interface which, on a method call, creates a message object and sends it via some preconfigured channel. Like channels, gateways are Spring beans and can therefore be configured via the Beans DSL:

xmlns integration:'http://www.springframework.org/schema/integration'
xmlns jms:'http://www.springframework.org/schema/integration/jms'

integration.'channel'(id: 'apiChannelRequest')
integration.'channel'(id: 'apiChannelResponse')

integration.'gateway'(id: 'someApi', 'service-interface': org.ast.SomeApi.class.getName(), 'default-request-channel': 'apiChannelRequest', 'default-reply-channel': 'apiChannelResponse')  {

  integration.'method'(name: 'executeRemotely')  {
    integration.'header'(name: 'API_METHOD_NAME', value: 'executeRemotely')
  }
}

As you can see from the configuration snippet above, the gateway has a request/reply channel configured since gateways are synchronous (in SI 2.0 there is asynchronous gateway support) and bidirectional. The SomeApi interface uses SI annotations for further message configuration:

interface SomeApi {
    Boolean executeRemotely(final @Header("HEADER_NAME") String param1, final String param2)
}

From the gateway’s view the interface above means: whenever executeRemotely is called, put param1 into a message header with name HEADER_NAME and put the second parameter into the message’s payload. Maybe you noticed the API_METHOD_NAME parameter in the gateway configuration above – that was a message header too. We needed to manually inject a unique method identification token (in our case the method name only was enough) in order to call the correct method on the slave application side.

Configuring JMS messaging

So far we’ve set up an environment with an embedded ActiveMQ message broker and two ActiveMQ message queues. Now we need to configure the link between the SI channels configured in the last section and those JMS queues. Since gateways are bidirectional, SI needs to store some reply channel information whenever instantiating an API request. This is automatically done via the gateway implementation. If we would run inside a SI environment only we wouldn’t need to care about this fact. In our case, we chose to use gatways to communicate between a master and a slave application which are in production deployed on separate server instances.

In SI, a JMSOutboundGateway can be used for those JMS request/reply scenarios. It is the clue between SI channels and out ActiveMQ JMS queues:

jms.'outbound-gateway'(id: "jmsGateway", 'connection-factory': 'pooledJmsConnectionFactoryLocal', 'request-destination': "requestQueue", 'request-channel': "apiChannelRequest", 'reply-destination': "responseQueue",'reply-channel': 'apiChannelResponse')

In the slave application, there needs to be an inverse configuration using a JMS inbound gateway:

jms.'inbound-gateway'(id: 'jmsInbound', 'connection-factory': 'pooledJmsConnectionFactoryRemote', 'request-destination-name': 'QUEUE.REQUEST', 'request-channel': 'incomingRequest', 'reply-destination-name': 'QUEUE.RESPONSE')

The configuration snippet inside the slave application simply routes incoming messages to the incomingRequests channel. Notice that no reply channel has been specified in order to keep the reply channel which has been added by the master application in the message.

In the next part of this article series we’ll have a closer look at the slave application and how it is configured to invoke methods an Grails service beans.

[0] ActiveMQ Message Broker
[1] Spring Integration
[2] Enterprise Application Integration
[3] Spring Integration – Reference Manual
[4] Amazon: Enterprise Integration Patterns

Grails: Splitting up resources.groovy

October 13, 2010 1 comment


Flattr this
Grails provides a neat way to specify Spring bean definitions with its custom Beans DSL [0]. The bean definition is found in grails-app/conf/spring/resources.groovy:

beans = {
    myBean(SomeBeanClass)  {
        someProperty = ref('someReference')
    }
    // ...
}

Another way to specify beans is via XML definitions:

<beans:beans
        xmlns:beans="http://www.springframework.org/schema/beans"
        xmlns:util="http://www.springframework.org/schema/util"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="
            http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
            http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-3.0.xsd">

    <beans:bean id="myBean" class="org.ast.beans.SomeBeanClass">
        <beans:property name="someProperty" ref="someReference" />
    </beans:bean>
    <!-- ... -->
</beans:beans>

These can be specified in grails-app/conf/spring/resources.xml.

Grails watches resources.groovy and resources.xml for changes and reloads them at runtime if necessary.

Splitting up with Bean XML files

As the bean definition count raises, it is preferable to split resources.groovy into separate bean definition files. Using Spring’s bean definition XML this can be done via the <beans:import/> XML tag:

<beans:beans
        xmlns:beans="http://www.springframework.org/schema/beans"
        xmlns:util="http://www.springframework.org/schema/util"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="
            http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
            http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-3.0.xsd">

    <beans:import resource="common.xml"/>
    <beans:import resource="job-definitions.xml"/>
    <!-- ... -->
</beans:beans>

It is considered good practice to split up a large Spring bean definition file into multiple files, whereas each file contains beans of the same thematic context (e.g. all beans related to batch jobs go to ‘batch-common.xml’, all beans related to data-source config goto to ‘data-source.xml’, etc.).

Splitting up in Beans DSL

So far for XML bean definition files, but what about splitting resources.groovy into separate groovy definitions?

Since Grails 1.2, there is a way to do this (although not explicitly documented in the Grails reference documentation). Grails’ Beans DSL is interpreted via a grails.spring.BeanBuilder instance which in turn provides method

public void importBeans(String resourcePattern) { 
// ...
}

This method can be used inside the Beans DSL to load arbitrary Spring definitions either specified in XML or Bean DSL groovy files:

beans = {
    importBeans('classpath:grails-app/conf/spring/common.xml)
    importBeans('classpath:grails-app/conf/spring/job-definitions.xml)
    importBeans('classpath:grails-app/conf/spring/integration.groovy)
    // ...
}

The String parameter of importBeans might be an arbitrary resource pattern which is resolved at runtime using Spring’s org.springframework.core.io.support.ResourcePatternResolver, e.g. it would be possible to import multiple XML and/or groovy files using ‘*’ like:

importBeans('classpath:grails-app/conf/spring/*.xml)

[0] Grails Beans DSL

[1] BeanBuilder should support import

Categories: grails

Data Binding and One-To-Many Associations


Flattr this
Data Binding in Grails is referred to as the process of binding incoming request data, typically only available as key/value string pairs, to some domain object.

Let’s take a look at the BlogController’s save closure out of an example project I’ve been showing at the last Austrian EJUG meeting [0]:

    def save = {
        def blogInstance = new Blog(params)
        if (blogInstance.save(flush: true)) {
            flash.message = "${message(code: 'default.created.message', args: [message(code: 'blog.label', default: 'Blog'), blogInstance.id])}"
            redirect(action: "show", id: blogInstance.id)
        }
        else {
            render(view: "create", model: [blogInstance: blogInstance])
        }
    }

The second line in the save closure creates an instance of the Blog class. As you might already know, creating objects can be done in multiple ways when working with Groovy. In this case, we use Groovy’s feature to invoke the “default constructor” and bind the given map containing property values immediately to the fresh instance.

def blogInstance = new Blog(params)

However, when updating an already persisted blog instance we need to use a mechanism provided by Grails: the properties property.

You can use the properties property to assign a map of key/value pairs to a domain class instance, thus updating the object. By the way: Grails uses Spring’s data binding capabilities to perform data binding [1]. This means that you can use all the possibilities provided by Spring, e.g. defining custom PropertyEditor classes.

So far so good. But what happens when it comes to binding many-to-one or one-to-one associations? The answer is pretty simple: it just works [2]. GrailsDataBinder even supports lazy object instantiation of domain classes. Whenever the other side of the association does not exist, it is created by Grails and populated with the given request parameter values:

/blog/save?title=Bla&author.name=John%20Doe

But what happens when working with unidirectional one-to-many associations?

In my EJUG example we had such a one-to-many association between a Blog and multiple BlogPost instances. The design decision was to keep all domain class relationships as lean as possible, therefore we decided that a relationship between a blog post and its blog is not necessary, as the Blog is a domain aggregate [3].

A bit of digging into Grails’ GrailsDataBinder revealed method bindCollectionAssociation:

private void bindCollectionAssociation(MutablePropertyValues mpvs, PropertyValue pv) {
  Object v = pv.getValue();

  Collection collection = (Collection) bean.getPropertyValue(pv.getName());
  collection.clear();
  final Class associatedType = getReferencedTypeForCollection(pv.getName(), getTarget());
  final boolean isArray = v != null && v.getClass().isArray();
  final PropertyEditor propertyEditor = findCustomEditor(collection.getClass(), pv.getName());

  // ...
  if(isArray) {

    Object[] identifiers = (Object[])v;
    for (Object id : identifiers) {
      if (id != null) {
        associateObjectForId(pv, id,associatedType);
      }
    }

    mpvs.removePropertyValue(pv);
  }
// ...

As you can see in the code snippet above, whenever the given property value v is an array, it assumes that it is an array of identifiers. Than it iterates over the identifiers and tries to associate an object for the current identifier with the associated type retrieved via getReferencedTypeForCollection.

In associateObjectForId it uses MOP programming to invoke the associations addTo* method:

// ...
MetaClassRegistry reg = GroovySystem.getMetaClassRegistry();
MetaClass mc = reg.getMetaClass(target.getClass());
final String addMethodName = "addTo" + GrailsNameUtils.getClassNameRepresentation(name);
mc.invokeMethod(target, addMethodName,obj);
// ...

Given a one-to-many association this means that we can simply use Grails default data binding functionality to bind this type of associations. In the view we could use a multi select box to map all selected blog post identifiers to a single request parameter:

<g:select name="blogPosts" from="${org.ast.domain.BlogPost.list()}" multiple="yes" optionKey="id" size="5" value="${blogInstance?.blogPosts}" />

As a result, the properties property can be used to automatically bind one-to-many associations.

blog.properties = params

The only requirement is the array type which is important to notice when constructing the identifiers list manually:

params['blogPosts'] = someList as String[]
blog.properties = params

Conclusion

Data Binding in Grails is based on Spring’s validation and data binding mechanisms. When binding unidirectional one-to-many associations the GrailsDataBinder automatically associates objects due to the given identifiers.

[0] Grails Talk at the Austrian EJUG meeting in June ’10
[1] Spring Data Binding and Validation Documentation
[2] Data Binding – Grails Documentation
[3] Domain Driven Design Patterns: The Aggregate

Categories: grails

EJUG Austria: Grails Talk

June 30, 2010 1 comment

I talked about Grails at the Austrian EJUG meeting. Feel free to download the slides via PDF or watch the presentation on YouTube.

PDF (6,5 MB): Grails – The Search is Over.
YouTube: Grails – The Search is Over.

Categories: grails, Intro