In most of our projects we use Artifactory. It is nice that artifactory comes with a REST based api. The url’s can be a bit better and the content type of the response is not what I would expect. Still the documentation is good and lost of actions are possible. In this blog post I show you the basics of interacting with the REST api using groovy. Now let us shrink the repo.

Introducing the artifactory api

The frog wiki has a wiki page dedicated to the api. This page shows the GET/DELETE/PUT requests that you can execute. It shows the url, the response and the content type. If you click the following link you jump to the definition of Folder Info. After the link an image with the same data at the time of writing.

http://wiki.jfrog.org/confluence/display/RTF/Artifactory%27s+REST+API#Artifactory%27sRESTAPI-FolderInfo

In the image you can also see the JSON response for the specific request. Have a look at the structure of the response. Look at the children. We will use it later on.

Obtaining folder info

Time to show some code. We will first have a look at a function to obtain information about the folder as provided by the caller. Since we group the functions in a class we have to look at configuration of this class as well. The constructor accepts a map that we call config. That way you can provided configuration for the server, the repository and the versions to remove. An example of the config map is.

def config = [
    server: 'http://localhost:8080',
    repository: 'libs-release-local',
    versionsToRemove: ['/3.2.0-build-'],
    dryRun: false]

Than we can ask for information about a folder. The following code block shows two functions, one to obtain information about a folder and the other to ask for a connection with the server.

def JSON folderInfo(path) {
    def binding = [repository: config.repository, path: path]
    def template = engine.createTemplate('''/artifactory/api/storage/$repository/$path''').make(binding)
    def query = template.toString()

    def server = obtainServerConnection()
    def resp = server.get(path: query)
    if (resp.status != 200) {
        println "ERROR: problem obtaining folder info: " + resp.status
        println query
        System.exit(-1)
    }
    return resp.data
}

private RESTClient obtainServerConnection() {
    def server = new RESTClient(config.server)
    server.parser.'application/vnd.org.jfrog.artifactory.storage.FolderInfo+json' = server.parser.'application/json'
    server.parser.'application/vnd.org.jfrog.artifactory.repositories.RepositoryDetailsList+json' = server.parser.'application/json'

    return server
}

We make use of the groovy SimpleTemplateEngine. As you can see we build the query string with placeholders and attach a map with parameters to the template engine. Next step is to generate the query. After obtaining the connection to the server we execute the GET request and obtain the JSON data from the response. Notice the lines in the obtainServerConnection. The last two lines add mappings for the artifactory provided content types. We want them to be treated as normal json responses or else our mapping framework (Jackson) will not be able to process the result.

Removing items

The goal for this blog post is to present a script to clean your artifactory repository. Now that we know how to obtain information about a folder in artifactory, it is time to have a look at cleaning. The idea is to take the provided path as a starting point. Go through all the folders recursively and check if we are in an artifact folder. An artifact folder contains artifacts and should not have other folders. If a folder is not an artifact folder we are dealing with a grouped (maven terms). In our case we could determine an artifact folder by its name. All artifacts have -build- in their name. Hence the following function.

private def isArtifactFolder(child) {
    child.uri.contains("-build-")
}

The next utility function is to actually delete a folder. The next function removes the provided path if we are not doing a dry run. If we did configure a dry run, we only print a message and do not actually do the delete. We again use the groovy template technology to create the query. Notice that the artifactory api uses the DELETE request.

private def removeItem(path, child) {
    println "folder: " + path + child.uri + " DELETE"
    def binding = [repository: config.repository, path: path + child.uri]
    def template = engine.createTemplate('''/artifactory/$repository/$path''').make(binding)
    def query = template.toString()
    if (!config.dryRun) {
        def server = new RESTClient(config.server)
        server.delete(path: query)
    }
}

The last piece of the puzzle is the recursive function to check a folder for subfolders and give the command to remove a folder if it is in the list of folder to be removed. The next code block shows this function.

def cleanArtifactsRecursive(path) {
    def deleteCounter = 0
    JSON json = folderInfo(path)
    json.children.each {child ->
        if (child.folder) {
            if (isArtifactFolder(child)) {
                config.versionsToRemove.each {toRemove ->
                    if (child.uri.startsWith(toRemove)) {
                        removeItem(path, child)
                        deleteCounter++
                    }
                }
            } else {
                if (!child.uri.contains("ro-scripts")) {
                    deleteCounter += cleanArtifactsRecursive(path + child.uri)
                }
            }
        }
    }
    return deleteCounter
}

The code is available online through github, check the references.

References

Cleaning up your maven repository

Other blogpost about groovy and cleaning your local maven repository automatically.

Artifactory

Homepage of the creators of Artifactory, here you can also find commercial support

Artifactory REST api

Documentation for the REST api that is provided by Artifactory

The source code

Sourcecode of the script discussed in this article.

http://blog.jteam.nl/2011/08/01/cleaning-up-your-maven-repository

Project structure

The structure of the project is fairly straightforward, but big enough to demonstrate some of the features that gradle has to offer. It consists of two modules:

• App
• Web-ui

We are creating an Axonframework sample, the app contains the command handling and for now the query part as well. The web-ui contains the spring mvc app with the controllers and the authentication using the spring-security framework. For now we make use of an in memory database and we want to be able to start the application without a lot of hassle. Using jetty in this case.

The modules have some shared dependencies for testing and logging. We also want to centralize the definition of some dependency versions.

Multi module gradle build

Gradle was build with multi module support from the start. So what do you need to create a multi-module build. We need a settings.gradle that defines the available modules. Next to that we need the main build.gradle as well as the modules build.gradle. Oke you can do without the per module configuration, but in my case that was not the intention. Let us focus first on the main build.gradle.

Main build.gradle

The main build.gradle is used to define some of the versions of the dependencies. The following code block shows the complete script.

axonVersion = "0.6"
springVersion = "3.0.4.RELEASE"
springSecurityVersion = "3.0.3.RELEASE"
slf4jVersion = "1.5.8"
sourceCompatibility = 1.6

subprojects {
    apply plugin: 'java'

    configurations {
        all*.exclude group: "commons-logging", module: "commons-logging"
    }

    repositories {
        mavenCentral()
    }

    dependencies {
        compile "org.slf4j:jcl-over-slf4j:$slf4jVersion",
                "org.slf4j:jul-to-slf4j:$slf4jVersion"
        runtime "org.slf4j:slf4j-log4j12:$slf4jVersion"

        compile("log4j:log4j:1.2.15") {
            exclude group: "com.sun.jdmk", module: "jmxtools"
            exclude group: "com.sun.jmx", module: "jmxri"
            exclude group: "javax.mail", module: "mail"
            exclude group: "javax.jms", module: "jms"
        }

        testCompile 'junit:junit:4.7'
    }

    group = 'org.axonframework.samples.trader'
    version = '1.0-SNAPSHOT'
    sourceCompatibility = 1.6
}

As you can see, the script starts with the definition of the versions of dependencies. Than the script contains information for all the subprojects. You see we define the java plugin for all subprojects. Next to that the repositories and the dependencies are defined. Have a look at the mechanism to exclude transitive dependencies. For log4j we explicitly exclude some transitive dependencies. We also use a mechanism to exclude commons-logging from the complete build. Using the configurations hook we exclude it for all phases.

Finally we also define the group, version and source compatibility in the build configuration.

That is it, the following code block shows the required settings.gradle and after that we move on with the build.gradle of the app and web-ui subprojects.

include "app", "web-ui"

Subprojects build.gradle

The build.gradle for the app project is almost to easy to show. But I promised I would, so here we go:

dependencies {
    compile "org.axonframework:axon-core:$axonVersion"

    compile "org.hibernate:hibernate-entitymanager:3.4.0.GA",
            "c3p0:c3p0:0.9.1",
            "org.hsqldb:hsqldb:1.8.0.10"

    compile "org.springframework:spring-tx:$springVersion",
            "org.springframework:spring-orm:$springVersion",
            "org.springframework:spring-jdbc:$springVersion"

    compile "com.thoughtworks.xstream:xstream:1.3.1"

    testCompile "org.axonframework:axon-test:$axonVersion"
}

The configuration only contains dependencies. I would like to be able to simplify the dependencies on the spring projects. Would be nice if I could group them somehow, like:

compile group:”org.springframework”, version:”$springVersion”, module:["spring-webmvc", "spring-aop"]

But the build config looks pretty clean. Now we move on to the creation of the war for the web project.

apply plugin: 'war'

dependencies {
    compile project(':app')

    compile "org.springframework:spring-webmvc:$springVersion",
            "org.springframework:spring-aop:$springVersion"

    compile "org.springframework.security:spring-security-web:$springSecurityVersion",
            "org.springframework.security:spring-security-config:$springSecurityVersion"

    compile "javax.validation:validation-api:1.0.0.GA",
            "org.hibernate:hibernate-validator:4.0.2.GA"

    runtime "javax.servlet:jstl:1.1.2",
            "taglibs:standard:1.1.2",
            "opensymphony:sitemesh:2.4.2"

    providedCompile "javax.servlet:servlet-api:2.5"
}

Again a pretty straightforward config. We use more types of dependencies. We now introduce the providedCompile. Jars that need not be included in the war should have this config for the dependency. Do mark that we have an apply plugin line at the top for creating the war. Finally have a look at the mechanism to show we have a dependency on another module of the project. We use the compile project (‘:app’) to make the war include this created jar as well.

Running with Jetty

You think the jetty plugin for maven is easy, well check this out. We have to change only one word in the web project config. Look for the first line with apply plugin. Change the word war into jetty and you are done. Now you can run jetty with the following command from the root of the project:

gradle :web-ui:jettyRun

The wrapper

People that have gradle installed on their system can easily build the project and run jetty. But some people might not have gradle installed. You can help them to make it very easy. Gradle comes with a wrapper that downloads gradle and makes sure it’s on your path etc. The only thing the user needs to do is the following in the root of the project:

gradlew build

Pay attention to the ‘w’ at the end of the gradle command. Next step is to start jetty. This is done with the same command as before with one change, the w at the end. To help your users with this, you need to do one thing. You have to add the following task to the main build.gradle. Than run gradle wrapper, checkin the generated files into your source control system. The gradlew script can be used by the people to build the project. Good stuff or not?

task wrapper(type: Wrapper) {
    gradleVersion = '0.9-rc-1'
    jarPath = 'wrapper'
}

Intellij integration

Oke, this kinda hurts to say, but intellij support is not at a level that you would like to. At least that is what I could find out. You can easily run gradle builds from intellij. That is all nice. But I am really missing the dependency management part. Would be great to have support like for maven to setup your complete project. Wouldn’t it be great to have the import from external model feature for gradle as well? For now let us all vote for this issue, it might help:

http://youtrack.jetbrains.net/issue/IDEA-57755

I hope someone from jetbrains reeds this at thinks I am important enough to start creating this plugin

Performance

The last remarks I want to make are about the performance of gradle. At the moment I have this build for maven as well as gradle and maven2 is twice as fast as gradle. I know work is being done on this. Gradle 0.9.1 will support a new feature that at least will speed up building the project of you have to do it a lot during the day. It will do something with a running gradle service that you can call each time you start a build. There are some items on the mailing list about this specific topic if you are interested.

http://gradle.markmail.org/thread/xbqna6lowvsmm4ve

Concluding

Well that was part one of the experiment. I have not touched everything by a long run. Still I found out I like the configuration of gradle a lot better than I like maven. It is a lot cleaner and let’s you focus on the things that are important. I prefer groovy for this kind of work over xml. Still gradle has some ground to cover. For starters, tool integration. We must have something that makes working with intellij a lot better. In the future I will have a better look at plugins for release management and other stuff that I think is necessary for a good project build.

What are the tasks that we focus on right now:

• Create a new contact
• Remove a contact
• Change the name of a contact
• Register an address of a certain type for a specific contact
• Remove an address from a contact

But before we step into creating the front-end, we install some plugins that I discussed in previous posts.

Plugins

• Db-util – mainly used for testing
• Navigation – change the templates as well as add navigation stuff to the controller

Get our grails hands dirty

Task driven – Create a new contact, remove a contact, change name of a contact

Time to start working on the tasks. The first is a basic one: Create a new contact. This is one that comes out of the box, but we now have different navigation and I only want to show the fields that can actually be entered. For a contact that is only the name.

When creating new views I like to generate the views and start from the result. I took the list view first, removed the navigation part and shuffled the columns.

We move on to the create.gsp and the edit.gsp. Again we remove the input fields for items we do not need. In this case this is purely the identifier field. Of course I also remove the navigation. After testing the create screen, now without the identifier field I found out we need to change the constraints of the Contact object. We have to add nullable is true.

Let us move on to a more interesting task

Register an address of a certain type for a specific contact

At the moment we use the AddressEntryController to have a look at the addresses. This is about to change. Now we are going to show the available addresses in the contact details screen. This is also the screen where we present the tasks to remove an address and to register a new one.

We start with creating the button to add an address. We reuse the add button as provided by grails. There is a difference, the add button usually is presented in the top bar, we however want it in the bottom bar. Therefore we must add a class to the stylesheet and the following button to the bottom button bar:

<span class="button">
  <g:actionSubmit class="add" action="registerAddress"
      value="${message(code: 'orderEntry.button.registerAddress.label', default: 'Register Address')}"/>
</span>

Another part of the show Contact page we need to change is the part where we actually show the addresses of the contact. I use the generated code for the list.gsp of address entries. I remove the pagination part, but other than that it is the same. Except for one column. We do want to be able to delete addresses. Therefore I have added an image with the a link to the delete action. This link with an image is shown in the next line of code.

<g:link action="deleteAddress" id="${addressEntryInstance.id}">
    &ltimg src="${resource(dir:'images/skin',file:'database_delete.png')}" alt="delete">
</g:link>

Check out the way to create the link, just define the action and pass it an id. That is enough to be wired to the actual action method on the controller. I also like the way to create a link to an image. The resource method is used to point to a directory and the actual file. No need to think about web context url or things like that.

The final screen we need is the registerAddress form. It is mostly a copy of the edit.gsp of the address entry. I also do not want the contact name and contact identifier to be editable. Finally I changed the action of the form into saveAddress.

The final thing I want to have a look at is the groovy code of the controllers. The following code block shows all three methods that are important with respect to the addresses. The code is pretty straightforward.

    def registerAddress = {
        def contactEntryInstance = ContactEntry.get(params.id)
        def addressEntryInstance = new AddressEntry();
        addressEntryInstance.contactIdentifier = contactEntryInstance.identifier
        addressEntryInstance.contactName = contactEntryInstance.name
        [addressEntryInstance: addressEntryInstance]
    }

    def saveAddress = {
        def addressEntryInstance = new AddressEntry(params)
        if (addressEntryInstance.validate()) {
            def foundContact = ContactEntry.findByIdentifier(addressEntryInstance.contactIdentifier)
            contactCommandHandlerService.registerAddress(
                    addressEntryInstance.addressType,
                    addressEntryInstance.contactIdentifier,
                    addressEntryInstance.streetAndNumber,
                    addressEntryInstance.zipCode,
                    addressEntryInstance.city)
            flash.message = "${message(code: 'default.created.message', args: [message(code: 'addressEntry.label', default: 'AddressEntry'), addressEntryInstance.city])}"
            redirect(action: "show", params:[id:foundContact.id])
        }
        else {
            render(view: "registerAddress", model: [addressEntryInstance: addressEntryInstance])
        }
    }

    def deleteAddress = {
        def addressEntryInstance = AddressEntry.get(params.id)
        if (addressEntryInstance) {
            contactCommandHandlerService.removeAddress(addressEntryInstance.addressType, addressEntryInstance.contactIdentifier)
        }
        def foundContact = ContactEntry.findByIdentifier(addressEntryInstance.contactIdentifier)
        redirect(action: "show", id: foundContact.id)
    }

Again a lot of copy paste from the generated controller. But here we use the contactCommandHandlerService to create the commands that are send back to the server. In all three methods we use the query datasource to obtain the contact data. As you can see, we do not store anything in the query database. That is all handled by the commands and events. Than in the event listener we receive the domain events and update the query database. The following and last code block gives you the action that handles the AddressDeletedEvent.

    private void doHandle(AddressRemovedEvent event) {
        ContactEntry foundContact = ContactEntry.findByIdentifier(event.aggregateIdentifier.toString())
        AddressEntry foundAddress = AddressEntry.findByAddressTypeAndContactIdentifier(event.addressType,foundContact.identifier)
        if (foundAddress) {
            foundAddress.delete()
        }
    }

Oke because I actually forgot to implement this correct at first, the listener for ContactDeletedEvent. I forgot to remove the addresses for the contact. We have a table with contacts and a table that combines the contact information with the address information. Therefore we have to do two delete actions.

    private void doHandle(ContactDeletedEvent event) {
        ContactEntry foundContact = ContactEntry.findByIdentifier(event.aggregateIdentifier.toString())
        List<AddressEntry> foundAddresses = AddressEntry.findAllByContactName(foundContact.name)

        foundContact.delete()

        foundAddresses.each {address ->
            address.delete()
        }
    }

The following image gives you an idea about the screen.

That is it for now, in my next and final blogpost about this example I will show the advantage of having these simple screen oriented tables.

What does grails do in this picture. Isn’t grails about rapid application creation? Well, yes. It is a good platform to rapidly create web applications using the groovy language and still be able to use existing libraries. Personally I really like the Gorm library of grails. I think that gorm would be an excellent choice to wrap the query datasource. Of course the gsp technology and the groovy language are nice to have when working with the web applications as well.

In this blog post I’ll discuss the integration between grails and axon. How can we create an application with grails that makes use of Axon to implement CQRS. I’ll discuss the way to create commands and send these to axon. I’ll also discuss responding to events coming from axon. First I have to show some aspects of a grails project that you need to know before you can use Axon. I’ll try to take you with me when I take the steps to create a good integration between Axon and Grails.

Sources

The sample I am using is the same sample that is provided by axon with a flex client. The AddressBook is used to show the different possibilities of axon and a client. You can create contacts, and register addresses of a certain type for contacts. You can register home, work and holiday addresses.

You can find the sources of the sample at github:

http://github.com/jettro/axon-addressbook-grails

Configure grails to use Axon

Grails has a pretty elegant way to configure libraries to be used by the project. You can make grails look for libraries in remote maven repositories as well as your local repository. I need to enable the local repository since I am working with a SNAPSHOT version of axon at the moment of writing.

Each normal grails project contains a folder grails-app/conf. In this folder is a file called BuildConfig.groovy. This file contains the build configuration, you did not see that one coming did you? In this file there is a closure called grails.project.dependency.resolution. Within this closure you can configure the repositories and the dependencies. As I said before you need to uncomment the mavenLocal() and add the following two lines to the dependencies.

compile 'org.axonframework:axon-core:0.5-SNAPSHOT'
runtime 'com.thoughtworks.xstream:xstream:1.3.1'

I did not get the grails project to work in a way that SNAPSHOT dependencies are updated. So if I compile a new version of axon, I manually delete the library in the grails cache. The libraries are stored in the ivy cache on your computer. In my case the jars are in the folder:

<user_home>/.ivy2/cache/org.axonframework/axon-core/jars/axon-core-0.5-SNAPSHOT.jar

Structure of the project

If you create a normal grails application you usually stick to the conventional project setup. Within the grails-app folder you have folders for domain classes, controllers, services, and others.

The domain model

When creating a CQRS application the domain becomes a different beast. It is the domain that commands act upon and the events are generated by the domain. For now let us call the domain from CQRS perspective the core-domain and the grails domain classes the query domain. The query domain resides in the normal grails location. Each grails project also contains a src folder with the groovy and java classes. This is where we will store the core domain.

A very important thing to stick in your brain is that the controllers must not use the standard way of grails to save domain objects. If you would do that, you only update the query database and no commands are created and send to the Axon backend.

Grails services and axon commands

We interact with axon by making use of command objects. To make this easy from the grails perspective we create a service class around the command creation. This makes it easier to create a transactional scope and to have just one location where we actually send data to axon. This service is more like a proxy to the Axon command bus.

Grails controllers

The controllers are normal grails controllers, they make use of services to send data to the backend and they use gorm to query the data.

Axon event listeners

The event listeners are used to receive updates about the core domain and reflect this in the query domain. The listeners make extensive use of gorm to update data in the query domain.

The following image gives you an idea about the directory layout of the project.

Scaffolding

One of the nice options of grails to create applications very fast is to use scaffolding. When using axon this is still possible, but only to do the first steps very fast. I recommend creating your own views and controllers when you know what you want and you need to create better useable screens. You cannot use the scaffolding controllers. They would only use the query domain. We need to call the services from the controllers. I do generate the controllers and then adjust them to my needs.

To get an idea what I reused from the generated controllers, let us have a look at the changes I made to the generated controller methods. For now I did not change views, so they are still using the scaffolding versions. Beware that this is not a final solution. To give you an idea, registering an address for a contact means that you have to manually copy the uuid of the contact to the create new address screen. Of course I will change this as well, but that will be the topic of a next blog post.

As a rule of thumb, all methods that actually change data need to be altered.

def save = {
    def contactEntryInstance = new ContactEntry(params)
    if (contactEntryInstance.validate()) {
        def uuid = contactCommandHandlerService.createContact(contactEntryInstance.name)
        def foundContact = ContactEntry.findByIdentifier(uuid)

        flash.message = "${message(code: 'default.created.message', args: [message(code: 'contactEntry.label', default: 'ContactEntry'), foundContact.name])}"
        redirect(action: "show", id: foundContact.id)
    }
    else {
        render(view: "create", model: [contactEntryInstance: contactEntryInstance])
    }
}

Line 4 show that we use the service instead of the query domain object. In line 5 we do use the query domain object to find the created contact.

Configuring the event and command bus using grails and spring

Grails uses a lot of spring udner the hood. But they also give you a very easy way to use spring yourself as well. Grails comes with a special domain specific language for configuring spring. You can find the file resources.groovy in the grails-app/conf/spring folder. In this file we configure the event bus, the command bus, the event listener and the command handlers. The following code block shows the beans, it should be straightforward and not to hard to understand.

beans = {
    contactRepository(ContactRepository) {
        eventBus = ref("eventBus")
        eventStore = ref("eventStore")
    }

    contactEventListener(ContactEventListener, ref("eventBus"))

    createContactCommandHandler(CreateContactCommandHandler, ref("contactRepository"), ref("commandBus"))
    updateContactCommandHandler(UpdateContactCommandHandler, ref("contactRepository"), ref("commandBus"))
    removeContactCommandHandler(RemoveContactCommandHandler, ref("contactRepository"), ref("commandBus"))
    registerAddressCommandHandler(RegisterAddressCommandHandler, ref("contactRepository"), ref("commandBus"))

    // axon beans
    commandBus(SimpleCommandBus)

    eventBus(SimpleEventBus)

    eventStore(FileSystemEventStore, ref("xstreamSerializer")) {
        baseDir = "file:/Users/jcoenradie/temp/axonrepo"
    }

    xstreamSerializer(XStreamEventSerializer)
}

Creating a bean is easy, some of the beans are direct axon classes. The contactRepository, contactEventListener and all the command handlers are not. These are groovy classes that reside in the src directory.

Axon components in groovy

I am not going to write extensively about Axon. The website from Axon does a much better job. I do want to mention the most important components and show some of the groovy code to make it work.

Sending data using commands

The data send is in the command objects. The commandBus is used to dispatch the commands. Each command must have a registered command handler. Axon provided a special mechanism to use annotations to register handlers. For now I register the handlers manually. Let us have a look at the handler for contact creation. The spring configuration already shows that the handlers use the contactRepository as well as the commandBus.

class CreateContactCommandHandler implements CommandHandler<CreateContactCommand> {
    ContactRepository contactRepository

    def CreateContactCommandHandler(contactRepository, commandBus) {
        this.contactRepository = contactRepository;
        commandBus.subscribe(CreateContactCommand.class, this)
    }

    Object handle(CreateContactCommand command) {
        ContactAggregate contact = new ContactAggregate(command.newContactName)
        contactRepository.save contact
        return contact.identifier.toString()
    }
}

As you can see we need to implement the interface CommandHandler. In the constructor we subscribe the handler with the command bus. Now focus on the handle method. We create the contact aggregate and store it in the repository by calling the save method.

Core domain

Now the contact is created, but we also must update our query database. To understand what happens there, we must have a look at the core domain class. The following code block shows the constructor and that it applies an event for a contact being created.

    ContactAggregate(String name) {
        apply(new ContactCreatedEvent(name))
    }

Event listener

Now that we have the events, we want to listen for them and update our query database. When creating the event listener, we need to provide the eventBus. In the constructor of the listener we register the listener with the eventBus. The handle method receives the events. In this method we check if we support the provided event. If we support it, we call one of the available doHandle methods that make use of overloading to determine the right method. The following code block shows the handle method and two of the doHandle methods.

void handle(Event event) {
    println "Contact event listener recevied an event : ${event.class.simpleName}"
    if (event.class in [ContactCreatedEvent, ContactNameChangedEvent, ContactDeletedEvent, AddressAddedEvent]) {
        doHandle(event)
    } else {
        println "Event not supported"
    }
}

private void doHandle(ContactCreatedEvent event) {
    def contact = new ContactEntry(name: event.name, identifier: event.aggregateIdentifier.toString())
    contact.save()
}

private void doHandle(ContactNameChangedEvent event) {
    ContactEntry foundContact = ContactEntry.findByIdentifier(event.aggregateIdentifier.toString())
    foundContact.name = event.newName
    foundContact.save()
}

The ContactEntry is the query domain object. See how we query for an existing contact and how we store the new or updated contact in the query database.

Summary

That is about it for now. I have showed you some basic Axon components in groovy. I introduced you to the concept of a state datastore and a query datastore. Next to that I also told you about the commands. I did not tell you anything about the datastore used for storing the state. The sample makes use of the file based event sourcing datastore. Check the Axon documentation to find out more.

In the following blog posts I will improve the sample by making better screens and controllers. i will also talk more about the axon options. Try to use annotations to see if that makes the event listeners and the command handlers easier to understan.

Hope to see yo back.

The best learning source for me consists of a number of manning books:

• Grails in Action
• Groovy in Action (2nd edition)

The first thing I did was creating some scripts, I mainly copied some sources from others. I also wrote a blog post about the groovy goodness:

http://www.gridshore.nl/2009/11/20/analyzing-beet-results-with-groovy/

Again I was amazed by the way groovy is used to obtain a webpage and print the contents of the page. The following code block shows the script.

#!/usr/bin/env groovy
def NEW_LINE = System.getProperty("line.separator")
def address = "http://www.applenieuws.nl/?feed=rss"
def urlInfo = address.toURL()
println "URL: ${address}${NEW_LINE}"
println "URL Text: ${urlInfo.text}${NEW_LINE}"
println "Host/Port: ${urlInfo.host}/${urlInfo.port}${NEW_LINE}"
println "Protocol: ${urlInfo.protocol}${NEW_LINE}"
println "User Info: ${urlInfo.userInfo}${NEW_LINE}"
println "File: ${urlInfo.file}${NEW_LINE}"

But since you are reading this I guess you are already interested in groovy. This post is not for experts in groovy. It is more focussed on people trying to find out if groovy is going to help them work more effectively or just for the fun of it.

Integration

I love the integration of groovy and java. You can implement a java interface with groovy. You can call a groovy class from java code. One of the things you are able to do is use spring annotations like @Autowired and @Component in groovy. The following code block shows a listener that can function within an Axon application to receive events. Nice stuff isn’t it?

@Component
class GroovyAddressListener implements org.axonframework.core.eventhandler.EventListener {

  @Autowired
  GroovyAddressListener(SimpleEventBus eventBus) {
    eventBus.subscribe this
  }

  void handle(Event event) {
    if (event instanceof AddressRegisteredEvent) {
      println "a new address in city ${event.address.getCity()} is received."
    }
  }
}

If you are not familiar with the Axon Framework, check the website www.axonframework.org. I am also planning a blog post around a sample I am creating with a tight integration of Axon and Grails.

Due to the easy integration of groovy and java, people that like groovy create wrappers around existing java libraries to make them better useable. On of those examples is the HttpBuilder project. This is a project that wraps the apache http client.

Building groovy

Using maven

What is with software that it needs to be build. In java land we have maven. Nowadays (maven 3), maven is even powered by groovy. If you want to integrate groovy with java, a maven build seems very logical. There is a good maven plugin for building groovy. Checkout the following page to learn about the maven configuration.

http://btilford.blogspot.com/2010/02/groovy-170-and-gmaven-12-multi-module.html

If you want to compile groovy classes into java classes and use them in your own application, you need to add the groovy library to your classpath. The groovy maven plugin itself is easy to configure. The following code block shows an example that makes use of the groovy maven plugin.

<dependencies>
    <dependency>
        <groupId>org.codehaus.gmaven.runtime</groupId>
        <artifactId>gmaven-runtime-1.7</artifactId>
        <version>1.2</version>
    </dependency>
    <dependency>
        <groupId>org.codehaus.groovy</groupId>
        <artifactId>groovy-all</artifactId>
        <version>1.7.0</version>
    </dependency>
<dependencies>
<build>
    <plugins>
        <plugin>
            <groupId>org.codehaus.gmaven</groupId>
            <artifactId>gmaven-plugin</artifactId>
            <executions>
                <execution>
                    <goals>
                        <goal>generateStubs</goal>
                        <goal>generateTestStubs</goal>
                        <goal>compile</goal>
                        <goal>testCompile</goal>
                    </goals>
                    <configuration>
                        <providerSelection>1.7</providerSelection>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Using grails

Cannot get easier than this, just create a project and use the grails commands. Grails also makes it very easy to add libraries to the project. These libraries can be used in the normal grails classes: domain, controller, service. But you can also use them in your own groovy classes. I use this extensively in the grails/axon integration sample.

In your grails project go to the directory grails-app/conf. There you can find the BuildConfig.groovy. Within this file you can find the dependencies. The following code block gives you an example to include the axon framework as a compile time dependency and xstream as a runtime dependency. To be able to use this you have to uncomment the mavenLocal() in de dependencies part of the same file.

  dependencies {
    compile 'org.axonframework:axon-core:0.5-SNAPSHOT'
    runtime 'com.thoughtworks.xstream:xstream:1.3.1'
  }

Of course you could obtain libraries from other maven repositories, but since we use the snapshot that is not available in a repository we use the local maven repository.

The complete dependency model of grails is pretty extensive and a bit to much to discuss in detail.

Using Gradle

If you are only doing groovy, maven might not be the best choice. Even if you are combining java and groovy some people say maven is not the right choice. I think it is a matter of taste although I do think maven is pretty verbose. An alternative in groovy landscape is Gradle. Gradle uses convention over configuration. It needs less lines of code than ant (without custom libraries) and gives more freedom than maven. Maybe the best about grails is that it does not use xml, but it uses groovy instead.

Peter Ledbrook is doing a good job in using gradle to build grails projects. Read his blog post : http://www.cacoethes.co.uk/blog/groovyandgrails/building-a-grails-project-with-gradle. Personally I do think this is one step to far. For me the grails build system is good enough. I also had a lot of tooling problems when combining gradle and grails in intellij. I did not get the classpath like I wanted to. Using the mechanism as described in the grails part of build works for me. I do think they borrowed some good ideas (dependency management) from gradle.

Grapes

The last tool you can use when running groovy I would like to mention is Grapes. I like the idea for dependency management in scripts. There is a very easy way to add libraries to your classpath by using the grab mechanism. I like the example as published on the page about the groovy Http builder. I am not going to reprint the example here. It all has to do with the grab annotation. The following line only shows the grab command.

@Grab(group='org.codehaus.groovy.modules.http-builder', module='http-builder', version='0.5.0-RC2' )

So even in a command line script you can now use libraries managed by Grapes.

That is it for now, more to follow the next months.

This is the third post in a series of post about grails. In this series I am describing an application I am creating with grails. It is a scheduling application for scheduling people on projects. You can find the previous posts here:

• http://www.gridshore.nl/2009/12/20/starting-with-grails/
• http://www.gridshore.nl/2010/01/04/continuing-with-grails/

In this post I will discuss the following topics:

• Creating meeting notes using the grails-ui rich text editor
• Create a search using the searchable plugin on the meeting notes
• Introducing rss to subscribe to new meeting notes

Meeting notes

Create the basics

For the meeting notes we want a large text field that can contain html to make it look better. We start of with the domain object. We give it three fields: a weekNr a User and the notes. The notes field must become a Text field in the database and a textarea on the screen. To accomplish this, we add a mapping element with the following contents as well as the constraints to make it an html textarea element. (Yes I know this feels strange)

class MeetingNotes {
    int weekNr
    User user
    String notes
    static constraints = {
        notes(blank:false, widget:"textarea")
    }
    static mapping = {
        notes type:"text"
    }
}

Next step is the controller, for now we add the scoffold property and configuration to add it to the navigation. The next code block shows the first implementation.

class MeetingNotesController {
    def scaffold = true

    static navigation = [
            group: 'tabs',
            order: 110,
            subItems: [
                    [group: 'tabs', action: 'create']
            ]
    ]
}

The create screen now looks like this:

Use the rich text editor

In include the rich text editor, we generate the views and make changes to those. Than we change the create.jsp in views/meetingnotes. We start by removing the navigation. Than we add the following line to the head element.

<gui:resources components="richEditor"/>

Then we just need to make a small change to the gsp. Look for the line with g:textArea. We replace this input item with the following line.

<gui:richEditor id='notes' value='add your weekly notes here ....'/>

This results in the following screen:

The same changes need to be made to the edit.gsp. I also removed the navigation from the other gsp’s. Time to move on, now we are going to include the searchable plugin and make the weekly meeting notes searchable.

The searchable plugin

Let us start with the basics and install the plugin, configure the MeetingNotes domain class to be searchable, and look at the generated search screen. You can find these steps as well in the quick start from the plugin documentation.

grails install-plugin searchable

Now the hard part to make our MeetingNotes searchable, we have to add the following line to the MeetingNotes domain class.

static searchable = true

For real, that is it. Now you can browse to the controller that serves the search.

I have created three items that all contain data, the following screen shows the standard search controller. Only two items will be returned if I look for the project name cqrs4j

That is all nice, but it does not really integrate with our site. Therefore we want to make a controller that does the search thing and an input box beneath the header menu.

First I add a line to the UrlMappings that maps the /search request to the SearchableController that comes out of the box. Check the file UrlMappings.groovy in the conf folder.

"/search" (controller:"searchable")

Now we will override the view of that comes with the plugin and make it look more like our own. This page, Controller and view, describes how you can do that. I copied the index.gsp from the path ${user.home}/.grails/1.2.0/projects/MyScheduling/plugins/searchable-0.5.5/grails-app/views/searchable/index.gsp to the same location in my own application. Then I alter that index.gsp, add the template, remove some styling and I have a better looking page. I also copied the form into the main.gsp layout so we have a search box on each page. The following screendump shows the result.

There you have it, basic search implemented in our own application. Looking really integrated.

There is topic that I also want to mention, this is suggestions. You know them from google and more advanced search solutions. You know what, we have an advanced search now as well. We just have to configure that we want to use suggestions. With this option configured, the results page shows a link to try the search again with suggestions. As an example try to search for holday, you get no results, try the suggestions and you get the following screen.

To do this, we change the searchable part of the MeetingNotes into the following lines:

    static searchable = {
        spellCheck "include"
    }

The search plugin has a lot of options and functionality. I urge you to have a look at the plugin page.

Rss feed

A very often method used to be informed for new items is rss. I want to create a feed for all meeting notes. That way people get notified when a new Meeting Note is created. To create the feed, I use the feeds plugin.

Again it all starts with the installation of the plugin. The plugin makes use of the framework Rome. So if you are familiar with that, this should not be to hard. Not that it is hard if you do not have the knowledge.

grails install-plugin feeds

Now adding the feed consists of two parts. The first part is to add a feed method to the MeetingNotes controller. The second part is two add the special html tag, which is done using a grails tag.

<feed:meta kind="rss" version="2.0" controller="meetingNotes" action="feed"/>

    def feed = {
        render(feedType:"rss", feedVersion:"2.0") {
            title = "Meeting Notes feed"
            link = "${grailsApplication.config.grails.serverURL}/meetingNotes/feed"
            description = "All meeting notes that have been written per week"
            MeetingNotes.list().each() { note ->
                entry("weekNr : ${note.weekNr}") {
                    link = "${grailsApplication.config.grails.serverURL}/meetingNotes/show/${note.id}"
                    "Meeting notes for week number ${note.weekNr} by ${note.user.userRealName}" // return the content
                }
            }
        }
    }

The code is so easy I hardly need to explain anything. One thing that had a problem at the moment is hard wiring the name of the server to get the feed from. The only trick I want to point out is the way to construct the link (line 4 and 8). We use the special mechanism to read parameters from the config that can be environment specific. The grails.serverURL parameter is by default configured in the Config.groovy configuration file.

In safari I now have the following result.

That is it for this post. I am still amazed by how easy things are using grails. Most of the time I spend on getting the ui done. In the next post I will not introduce new plugin, but I will focus on getting the solutions better. Add validation, better configured access control, internationalization. Those kind of topics.

Hope to see you back.