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.

Now, Rob Pike is not nobody (in addition to being a Google principle engineer he has C and Unix credentials), plus the Go language has the Google brand name on it, so I thought it would be a good idea to check it out….

Evaluating Go

The Go programming language is described on the website as a language geared towards system programming. That is to say, it is a new(ish), general purpose programming language developed internally at Google to scratch an itch some of their developers had and they then decided to open source it.

Evidently, judging from Rob Pike’s talk at O’Reilly, it is also intended to be a simpler alternative to C++ and Java and a more robust alternative to dynamically typed languages such as Ruby, Python and such. It is this claim that I felt was particularly intriguing, so I took a look at the language this evening by reading through the language spec and briefly glancing at the tutorials.

Creak, creak…

Well, let’s address the great big elephant in the room immediately: it would seem that “simpler alternative” is Google-speak (or Pike-speak) for “forty five years old”. It’s had a spit-polish plus language features and libraries added, but there’s no way around it — Go is a rehash of the C programming language with some Pascal thrown in for good measure. Not surprising of course, given Rob’s background, but perhaps not the great linguistic revolution you would have expected.

Just to reassure you all, I’m not exaggerating: Go is essentially C, including structs, pointers and reams of different (un)signed int types. It even includes everyone’s favorite cross-platform language feature: numeric types whose size is architecture-dependent.

Spit-shine

That’s not to say that some improvements have not been made to cover up some of the glaring problems that made C and C++ hard to handle: extern is gone as a concept, as is pointer arithmetic. Plus Go has a type definition feature, so you don’t need macro’s anymore. Also, Go has some more built-in types (such as complex numbers), support for Unicode and it can insert semicolons where needed and has both escaped and unescaped strings (both borrowed from Bourne Shell). And it places the type behind the identifier instead of in front and uses := as an assignment to distinguish from equality (borrowing from Pascal).

Back from the dead

Nevertheless, not all is well with the world. Like it’s ancestors Go still relies on an ability to export named entities (including variables), meaning you can get into the global variable mess. And guess what’s back from the dead: the goto statement, in its full and glorious horror.

So what else is new?

At the core of it, Go is a component-based language. It’s main architectural feature for this is the package, which isn’t much like Java but rather borrows from the Unit found in Turbo Pascal: a collection of exported types and identifiers, with hidden implementations. Packages serve as libraries in the language and are the main strength and source of language functionality.

In the spirit of “this is your grandfather’s technology”, Go is not an object-oriented language. Instead it is fully procedural and uses the abstract data type as its main means of abstraction. Admittedly, this is a good combination with the Unit-like library. The ADT concept has been bolstered with real language support to keep ADT functions and data structures together though. Even though the main data structures are C-style structs, the language includes the concept of a method (which is a function that is sort of legoed into a data type, creating the effect of putting a function pointer into a struct in C). Methods directly associate a callable code block with a data structure, so it’s sort of like adding real behavior to your basic data type. That’s a pretty good concession to OO thinking sure enough, but encapsulation beyond the package level and inheritance are still out.

The other major feature of the language is built-in concurrency modeled on Tony Hoare’s Communicating Sequential Processes. This is a brand of concurrency that is not based around the classic “multi-process, shared single memory” model but around a “multi-process, multi-memory” model whereby processes are linked together by channels. Each process can “toss” values to another process over a channel (or “catch” values coming in across a channel). These operations block until succeeded, which allows for synchronization. The mechanism has been proven equally powerful as Dijkstra’s standard semaphore mechanism. This is once again a typical choice for someone with Rob Pike’s background as this mechanism is also included in the Bourne Shell in the form of named pipes. Of course in such a language it must also be easy to start threads or fork subprocesses and indeed this can be accomplished with the use of a single statement.

So what are we to make of this…

The Go programming language is an interesting combination of proven language features and program architectures. Rooted firmly in the Pascal/C/Bourne Shell era, it seems a bit of a museum of 1960′s language design ideas geared towards the hardware systems environment of that era’s dreams (and possibly today’s reality): heavily multiprocessed with the distinction between local and distributed processing disappeared into the background, using ADT and component-based modularity to achieve separation of concerns.

… except perhaps a bonfire?

And yet, I can’t say that I’m overly impressed with Go. Mostly I don’t see the point. Sure, its well-suited to the multiprocessing environment that we have nowadays. But its support for domain modeling and domain driven design is poor, based as it is on the ADT concept — a serious failing in a modern language if you ask me. And a language that isn’t architecture independent in a Cloud-based platform era? Come on… But most of all I don’t see the new language idea that is supposed to make this language better than all others. I don’t see a refreshing combination of functional and OO paradigms like Scala, or an “easily-typed shell over a large Java class library” like Groovy. I don’t really see what Google thinks it has accomplished with Go.

In addition to that, I don’t see proof for the claim of simplicity. Sure, it covers up the worst pointer-related problems in C/C++. Sure, multithreading is less verbose than it is in Java. But on the whole the language is no simpler than Java, as far as I’m concerned. I don’t like the lacking encapsulation, the poor man’s OSGi modularity, the way methods are tacked on to external data types rather than syntactically part of data structures. And I don’t think first-class lambda functions (popularly called closures) are all that special and I don’t think that having channels as a built-in language element is a great advantage over having them in a separate library (like C++ or Java do).

So what do I think of Go’s future? Well, it certainly has one major weapon in its arsenal: the Google logo, which still makes everything cool that it touches. So Go might get somewhere based on that. But on its own merits I can’t think of any reason to prefer it over another language.

To my opinion, the blog looks even better. The twitter items look better than before as well as the authors with the amount of blog items.

If you spot problems, please let me know.

This post is mainly about flex and Parsley. We will go into depth of the architecture of the client and how to talk to the server. I will describe the communication with the application that makes use of the axon framework, but I will not go into a lot of details. If you want more information about the Axon Framework I suggest you go to the website http://www.axonframework.org. There is good documentation available in the reference manual. If you want to learn about flex and the Parsley framework in general, please read on.

What is Parsley and why use it?

Parsley is all about decoupling. It is a dependency injection framework and is has strong support for messaging. I like the way the dependency injection as well as message handling is configured. By using [INJECT] on a parameter, you tell parsley to inject an object of the type as specified by the parameter. We will see examples of the usage later on. Other things to inject are the [MessageDispatcher] that enables dispatching messages from each component.

The final component I want to mention is the DynamicCommand object. I use it more as a controller, still it is an interesting concept. We create one component that receives a message, does a remote call and handles the result of that call. All in one object. Again, an example will follow later on.

Structure of the Parsley solution

The following image gives you an idea of the overall solution of parsley. The image shows you the relationship between the view components, the controllers and the model. Messages are send from the view to the controller. The controller interacts with the remote components, updates the model and determines which view should be active. The controllers can also respond to remote push notifications, more on that later on.

Configure parsley

To enable injection and message handling, parsley needs it’s own context to be setup. The easiest way to do this is using an mxml object and an mxml ContextBuilder object. The next code block shows you the complete configuration of the framework. Within the configuration you can see the controllers being configured as DynamicCommand objects. You also find there the RemoteObject, the Consumer and the model objects. They should all be familiar from the previous image.

<mx:Object xmlns:mx="http://www.adobe.com/2006/mxml"
           xmlns:sf="http://www.spicefactory.org/parsley"
           xmlns:commands="org.axonframework.examples.addressbook.commands.*"
           xmlns:model="org.axonframework.examples.addressbook.model.*"
           xmlns:cons="org.axonframework.examples.addressbook.consumer.*"
        >
    <mx:RemoteObject
            id="remoteAddressService"
            destination="addressService"
            endpoint="messagebroker/amf"
            showBusyCursor="true"/>
    <cons:Consumer/>

    <sf:DynamicCommand type="{NewAddressController}" messageType="{NewAddressMessage}"/>
    <sf:DynamicCommand type="{NewContactController}" messageType="{NewContactMessage}"/>
    <sf:DynamicCommand type="{SearchAddressController}" messageType="{SearchForAddressesMessage}"/>
    <sf:DynamicCommand type="{SelectContactController}" messageType="{SelectContactMessage}"/>
    <sf:DynamicCommand type="{ShowContactsController}" messageType="{ShowContactsMessage}"/>
    <sf:DynamicCommand type="{UpdatedContactController}" messageType="{UpdatedContactMessage}"/>
    <sf:DynamicCommand type="{UpdatedContactAddressController}" messageType="{UpdatedContactAddressMessage}"/>
    <sf:DynamicCommand type="{RemoveAddressController}" messageType="{RemoveAddressMessage}"/>
    <sf:DynamicCommand type="{RemovedItemController}" messageType="{RemovedItemMessage}"/>
    <sf:DynamicCommand type="{RemoveContactController}" messageType="{RemoveContactMessage}"/>

    <model:AddressModel/>
    <model:ContactModel/>

    <mx:Script><![CDATA[
        import org.axonframework.examples.addressbook.commands.*;
        import org.axonframework.examples.addressbook.messages.*;
        ]]></mx:Script>
</mx:Object>

That is all that parsley needs to know. The final step is to build the context using the special mxml tag. I have included the next tag in my Main.mxml.

	<sf:ContextBuilder config="ParsleyConfiguration"/>

Next we will focus on the different components

Messages

We make use of two types of messages:

• CommandMessage – tells the receiver to do something.
• NotificationMessage – tells the receiver that something happened

View

Each view component should focus on presenting data and sending messages. The data is injected as a model object. Messages can be dispatched by the special parsley provided dispatcher. Than parsley also provides a Context object that can be used when pop-ups are needed. The following code block shows you the configuration of these mentioned parameters from the ContactsView.mxml component. You can also find a function that is called by pushing a button to send a message to obtain details about a certain contact.

[Inject]
[Bindable]
public var contactModel:ContactModel;
[MessageDispatcher]
public var dispatcher:Function;
[Inject]
public var context:Context;

private function showContactDetails(event:ListEvent):void {
    dispatcher(new SelectContactCommandMessage(event.currentTarget.selectedItem as Contact));
    currentState = 'detail';
}

This is all pretty straightforward, if you need the code check out the sources from the google code project. Let us follow what happens when obtain details button is pushed and the SelectContactMessage is dispatched.

Controller

By dispatching this message, parsley selects the SelectContactController since the argument of the execute method is that exact message. The following code block gives you the complete implementation of the SelectContactController. The super class of all controllers contains a method to handle the faults coming from the remote calls and it makes the dispatcher as well as the remote object available. This class is also in the code block. In the code check how the dispatcher, the RemoteObject and the contactModel are injected. Another thing to notice here is that we only go to the server if we have not cached the contact details locally. So what if the contact details get updated on the server? Or if new contacts are added on the server? More on that in the next section.

public class BaseController {
    [MessageDispatcher]
    public var dispatcher:Function;

    [Inject(id="remoteAddressService")]
    public var addressService:RemoteObject;

    public function BaseController() {
        // default constructor
    }

    public function error(fault:Fault):void {
        dispatcher(new ErrorNotificationMessage(fault.faultString));
    }

}

public class SelectContactController extends BaseController {
    [Inject]
    public var contactModel:ContactModel;

    private var findAddressesFor:Contact;

    public function SelectContactController() {
        super();
    }

    public function execute(message:SelectContactCommandMessage):AsyncToken {
        var cachedContact:Contact = contactModel.findContactByIdentifier(message.contact.uuid);
        contactModel.selectedContact = cachedContact;
        findAddressesFor = cachedContact;

        if (!cachedContact.detailsLoaded) {
            return addressService.obtainContactAddresses(message.contact.uuid);
        }
        return null;
    }

    public function result(addresses:ArrayCollection):void {
        var cachedContact:Contact = contactModel.findContactByIdentifier(findAddressesFor.uuid);
        cachedContact.addresses = addresses;
        cachedContact.detailsLoaded = true;
    }
}

You have now seen the most important parts of the mechanism to go from a view to a controller. Did you notice that we send an ErrorNotificationMessage when something goes wrong in the server communication? The notification messages are handled in the OverallView component. Other notification messages are also handled in this component. The following code block gives a piece of code that handles the message.

[MessageHandler]
public function handleActivityLogEvent(message:NotificationMessage):void {
    createNotification(message.message, Notification.INFO);
}

Communication with the server

The server is used to send data to and of course to obtain data from. The easiest way is when the flex client takes control. As we saw in the parsley configuration, the remote object is configured as you would in any flex client. In the code from the SelectContactController we can see the call to the server. The result function is called when the server returns a result. This is not very complicated to understand.

Let us have a look at how this is handled on the server. Using spring blazeds integration this becomes very easy as well

BlazeDS and Spring BlazeDS Integration

Doing flex remoting with the Spring BlazeDS integration is so easy that anybody can use it. In the web.xml you configure the dispatcher servlet. The config file is loaded using the following tag in a spring configuration file.

<flex:message-broker services-config-path="classpath*:services-config.xml"/>

Now I use annotations to explicitly export some of the functions as remote services. The following code block gives you the example of obtaining address details for a contact. Notice that the name of the method is the same as the method call used in the flex code. By adding the annotation @RemotingInclude we tell spring to expose this as a remote service using BlazeDS.

    @RemotingInclude
    public List<AddressDTO> obtainContactAddresses(String contactIdentifier) {
        List<AddressDTO> foundAddresses = new ArrayList<AddressDTO>();

        List<AddressEntry> addressesForContact =
                repository.findAllAddressesForContact(UUID.fromString(contactIdentifier));
        for (AddressEntry entry : addressesForContact) {
            foundAddresses.add(AddressDTO.createFrom(entry));
        }
        return foundAddresses;
    }

The repository is based on the query database of Axon. I am not going into all the Axon Framework details here. Check the references if you want to learn more about Axon.

That is all there is to it, now you can obtain data from the server. Sending data to the server is done exactly the same.

Receiving events

I already mentioned that we cache data in the flex client. Still we want to have up-to-date data. Using the Axon framework and Spring BlazeDS integration it is not hard to push data to the client from the server when new or updated data is available. Again this blog does not have the intention to fully discuss the axon framework.

Catching and dispatching events on the server

We focus on the event that a new contact is created. The following code shows how you can register a listener for new contacts being created using the Axon framework. The listener makes use of the UpdateMessageProducerForFlex. Axon registers listeners based on the annotation @EventHandler and the argument of the method, in this case the ContactCreatedEvent.

private UpdateMessageProducerForFlex producer;
@EventHandler
public void handleContactCreatedEvent(ContactCreatedEvent event) {
    logger.debug("Received and event with name {} and identifier {}", event.getName(), event.getEventIdentifier());
    ContactDTO contactDTO = new ContactDTO();
    contactDTO.setName(event.getName());
    contactDTO.setUuid(event.getAggregateIdentifier().toString());
    producer.sendContactUpdate(contactDTO);
}

This is the Axon part, the producer is used to send the message to the clients. Sending the message to the flex client is done using the spring BlazeDS integration. The following piece of code shows the producer. After that the configuration of the server.

public class UpdateMessageProducerForFlex {
    private MessageTemplate template;

    @Autowired
    public UpdateMessageProducerForFlex(MessageTemplate template) {
        this.template = template;
    }

    public void sendContactUpdate(final ContactDTO contactDTO) {
        template.send(contactDTO);
    }
}

    <flex:message-destination id="event-bus"/>

    <bean id="defaultMessageTemplate" class="org.springframework.flex.messaging.MessageTemplate">
        <property name="defaultDestination" value="event-bus"/>
    </bean>

The value for the default destination “event-bus” is very important. This needs to be configured in the client as well. Speaking of the client …

Catching and dispatching events at the client

Within the parsley configuration we have configured an object called Consumer. This object configures the client side of the poller and registers it on startup. This registration needs to be done at the right time. Parsleys provides the [Init] notation for that.

The consumer receives messages from the server and dispatches new Notification messages to the client side application. Controller objects pick up these events and update the model. The following code block shows the complete consumer object. Notice the configuration of the ChannelSet and the consumer.

<mx:Object xmlns:mx="http://www.adobe.com/2006/mxml">
    <mx:Script><![CDATA[
        [Init]
        public function init():void {
            consumer.subscribe();
        }

        [MessageDispatcher]
        public var dispatcher:Function;

        public function messageHandler(event:MessageEvent):void {
            if (event.message.body is Contact) {
                dispatcher(new UpdatedContactNotificationMessage(event.message.body as Contact));
            } else if (event.message.body is Address) {
                dispatcher(new UpdatedContactAddressNotificationMessage(event.message.body as Address))
            } else if (event.message.body is Removed) {
                dispatcher(new RemovedItemNotificationMessage(event.message.body as Removed));
            }

        }

        public function faultHandler(event:Event):void {
            dispatcher(new ErrorNotificationMessage("Fault while receiving message" + event.toString()))
        }

        ]]></mx:Script>
    <mx:Consumer id="consumer" destination="event-bus" channelSet="{cs}" message="messageHandler(event)"
                 fault=" faultHandler(event)"/>

    <mx:ChannelSet id="cs">
        <mx:AMFChannel url="messagebroker/pollingamf"/>
    </mx:ChannelSet>

</mx:Object>

Wrapping up

That is it. We have touched all components. I like how clean you can develop flex clients using Parsley and how easy it is to interact with a server using the Spring BlazeDS integration. Also the way to handle events using Axon makes this a very nice way to keep the data in your flex client up to date.

Hope you likes the sample, sources can be found in google code. Check the addressbook sample project of the axon framework.

The following image shows a screendump of the sample, after that are some references.

• http://code.google.com/p/axonframework/source/browse
• http://www.spicefactory.org/parsley/
• http://www.springsource.org/spring-flex
• http://www.axonframework.org

In this blog post I go step-to-step through a solution that analyzes the xml file and plots the results in a chart generated with jfreechart.

Introduction

In one of my previous posts I have discussed a nice framework for easy performance measurement called Beet. You can find this post here: Using beet to monitor your (springframework) application. The result of a monitor session with beet can be an xml file. Nice, but how do you analyze this file? By hand? No way, you need a tool. Excel or Numbers can be fine, but it can be a lot faster. Therefore I decided to create a small groovy application.

The first requirement for me was very easy, read the events in the xml file and calculate the average of all events of a certain type. I asked a few of my collegues about their estimated effort when having to do it in java. They varied from 1 hour (pretty optimistic) to half a day. Curious how much time it took me?

First iteration

The first iteration was to calculate the overall average, an optimist of 2 hour java work. First you locate the file, than you slurp the xml out of the file. With the xml file in your hand, you obtain all events with a child element type with the value method. The following code block shows these three lines of code, yes for real, three lines.

def file = new File("beet-integration-web-perf.xml")
def xml = new XmlSlurper().parse(file)
def methodEvents = xml.event.findAll {it.type == "method"}

The next step is to take all durations from the found events. Using these durations, calculating the average is very easy.

def file = new File("beet-integration-web-perf.xml")
def xml = new XmlSlurper().parse(file)
def methodEvents = xml.event.findAll {it.type == "method"}
def durations = methodEvents*."duration-ms"
println "Average duration is ${durations.sum {it.toBigDecimal()} / durations.size()}"

That is it, this took me 10 minutes. And yes for 5 lines of code that is still a lot, but cut me some slag man, I am still learning groovy . What I forgot to mention is that I use the groovyConsole to create and run the application.

Second iteration

The total average is nice, but with hundreds of measurements, not very useful. Of course we want more information on the data. To stretch myself a little bit, I had the idea to take the average of each minute and print that on screen. The next code block does just that, it calculates the averages of all measurements in the same minute and prints the result on the screen. When reading the code, take this tip. We create an array with all durations for each minute and put the result in a map with the minute as a key and the array with durations as a value.

def averages = [:]
def start = methodEvents[0].start.text()[0..16]
def minuteItems = []
methodEvents.each {
    def duration = it."duration-ms".toBigDecimal()
    def currentStart = it.start.text()[0..16]

    if (start == currentStart) {
        minuteItems.add duration
    } else {
        averages.put ((start),minuteItems)
        minuteItems = [duration]
        start = currentStart
    }
}

averages.each {key,value ->
    println "Minute : ${key} has average duration of ${value.sum {it.toBigDecimal()} / value.size()}"
}

Third and final iteration

Having this data written to the screen is oke, but a nice graph would be even better. For this I used a sample I found via google. Since the code is pretty straightforward, I just copy it in here.

def dataset = new DefaultCategoryDataset()
dataset.with{
    avarages.each {key,values ->
    def value = (values.sum {it.toInteger()} / values.size())
        addValue value , "average", key[-3..-1]
    }
}

def labels = ["Registered events total ${methodEvents.size()}", "Minute", "Average"]
def options = [true, true, true]
def chart = ChartFactory.createLineChart(*labels, dataset,Orientation.VERTICAL, *options)
def swing = new SwingBuilder()
def frame = swing.frame(title:'Groovy LineChart',
        defaultCloseOperation:WC.EXIT_ON_CLOSE) {
    panel(id:'canvas') { widget(new ChartPanel(chart)) }
}
frame.pack()
frame.show()

For those java people, check the way you can work with arrays in line 5. Counting from the end of the array, nice.

The result is shown in the next image.

That is about it, just two last things. First you need to add two jars to the classpath of groovy: jcommon-1.0.16.jar, jfreechart-1.0.13.jar. These are in the jfreechart download package. I used the mechanism to create a folder .groovy/lib in your root and add the jars to that folder.

The other thing I wanted to mention is the option to create a shell script from groovy. Just add the following line at the top and make your file executable and you are good to go.

#!/usr/bin/env groovy

That is it, in total 2 hours of work, not bad I think for a beginner in groovy with access to google. If you are good at groovy and you spot improvements, please let me know, I am eager to learn more.

This post I will talk you through a grails application I have created for a project of mine. I also take you through some of the things I learned last week. Finally I’ll show you that you can create a google app engine application using grails. There are ways to create grails applications, I’ll show you how to do it using the latest intellij 9 beta release.

Training

As mentioned in the introduction I attended the spring source groovy and grails training. The training was given by Peter Ledbrook, author of grails in action. I am not going to give a detailed description of the training. I did like the training, it gave a good overview of the possibilities of grails as well as the groovy language. And yes, I am now very interested in the options of groovy. Especially for creating web based applications with grails, groovy just shines. Not sure when I should use groovy and when normal java. Have to explore to find out. Some of the things I liked about groovy are:

• Assignment of parameters that are evaluated immediately ${age} or when used ${->age}
• Using negative indexes in arrays: [1 .. -2] strips of the first and last item from an array
• Groovy truth, explicit use of values in a comparison. null, 0, “” and [] are all false in a comparison
• Closures, still hard to determine when to use a closure and when a method. But closures are used very often in groovy.
• Out of the box test integration with things like: MockFor, Expando, and as a plugin GMock.

Of course we learned a lot more than this, check the training or the book yourself if you want more. Next up was grails. I did look at grails before at grails, but tool support was pretty limited back than, and the plugins were not really widely available. A lot has changed since than. SpringSource came out with grails support in SpringSource Tool Suite, and Intellij has grails support as well. To be honest, intellij was much more productive than STS. Actually STS was almost not useable. Since it was the first release with grails support it will most probably improve the coming releases. Intellij worked very nice out of the box (I did use the beta version of intellij 9. Some of the features I liked during the training are:

• Gorm, I must mention this Groovy/Grails Object Relational Mapping framework first. This is very important for grails and why it is so productive. I just love these dynamic finders (more later).
• Plugin architecture, the easy of installtion and usage of plugins is very nice. I like the db-util plugin for its simplicity and the help when working with internal memory databases. A killer plugin during development.
• Scaffolding, for auto responding to CRUD like operations.
• flash parameter to be used for adding something to the session for just one request. Ideal for passing messages.
• Using templates, ideal for doing ajax calls and reuse of small view elements.

Oke time to get our hands dirty, next up is a short introduction in the sample I am going to create. Than some code (which is acutally not that much)

The application to create

For a customer at JTeam, we have a large amount of servers that we need to prepare. The actual preparation is mostly done by the hosting provider. Sometime we have no idea what the status is of some servers. We started to use an excel sheet to communicate the status among our team. This is not ideal and I decided to create a small grails application for this. It’s all very basic, but useable.

Every server has a status, some comments and an external ip address. Each server is also part of a number of vlans and belongs to an environment (dev,test,accep,prod).

The code

The code is available online at github. Yes I know, it is not at google code. I got extra motivated to start using git since the training. Peter was working so flexible with his source code, I want that too. The best way to learn something is by doing it. Therefore I create a git repository at github. You can find out more at the following url. There is a very easy way to download the complete source code without using git, check the page.

http://github.com/jettro/MyServerPark

The basics

Starting a grails project is very well documented on the grails website. Except for one controller, the OverviewController, all controllers use: def scaffold = true. Which means I don’t write any code. Also not view components. I did create some domain classes that have relationships with each other. The next sections cover the different elements of the application.

The domain model

Some things to know about the domain model:

• belongsTo is used to declare a relationship of many-to-one, the next line gives an example for Comment. This gives the comment a property server.

static belongsTo = [server:Server]

• The comment class also gives meta data about the mapping and the type used for the database as well as constraints. In the example we create a field for larger amounts of text.

class Comment {
    String name
    String content

    static belongsTo = [server:Server]

    static mapping = {
        content type: "text"
    }

    static constraints = {
        name(blank:false, maxSize:50)
        content(blank:false, widget:"textarea")
    }
}

• The previous code block also shows one of the things that might be a bit strange. With widget:”textarea” you indicate the type of field to be used at the front end. Might be a bit strange in a domain model.
• A one-to-many relationship is also easy to implement, check the following line from Environment:

static hasMany = [servers:Server]

Check the code for more examples of relationships.

Scaffolding controllers and views

Grails makes use of scaffolding, this can be static and dynamic. In the static case, code is being generated and can be altered. The dynamic case is evaluated runtime. In this project I tried to use dynamic scaffolding as much as possible. Usability might not always be what you want. In that case you should use static scaffolding or create something yourself. I managed to do well with the scaffolding on dynamic (except for the google app engine sample). But let us focus on the customer controller.

The overview controller

Grails makes use of convention over configuration. This is also true for controllers and views. The overview controller listens to the /overview url and points to the overview.gsp file. The following code block gives the complete OverviewController groovy class.

class OverviewController {
    def show = {
        redirect(uri:"/server/show/${params.id}")
    }

    def comments = {
        def currentServer = Server.findById(params.id.toLong())
        def allComments = Comment.withCriteria {
            server {
                eq("id",currentServer.id)
            }
        }
        render(template:"/shared/comment",model:[comments:allComments, server:currentServer])
    }

    def index = {
        def environments = Environment.list()
        [environments:environments]
    }
}

There are three methods in the controller. The show does a redirect to the show method of the server controller. The index returns list of all environments and uses the view index.gsp. The comments method is a different cup of thee. This responds to an ajax call and returns a fragment. focus on the last line for now. You can see we use the render call. This makes use of a template. Using the render call, we obtain the html and push it back to the client. The section about views will give a bit more detail. Next up are the dynamic finders

Dynamic finders

The previous code block gives a few examples of finders. In index we obtain all the environments with Environment.list(). This is the most basic finder. Another finder is in the comments method. There we obtain the server by an id. The call is findServerById and you provided an id. Another calls could be: findByFunction, findByFunctionLike “%database%”, findByFunctionIlike “%DataBase%”. You can also make combinations with And/Or and multiple parameters. Pretty cool.

The comments method also shows the Criteria API for looking up all comments for a specific server. These type of queries, limited by a related item, are not supported by the dynamic finders.

Gsp for views

Creating the views is not very hard. If you want to learn how it works, I suggest generating the scaffolding views. I want to focus on something that is just a little bit more advanced. Ajax calls. In my project I want to obtain all comments for a server using an ajax call. In the overview page we use a special tag from grails, the remoteLink. This tag does an ajax call to the server and prints the result in the div with provided id.

<g:remoteLink action=”comments” params=”[id:server.id]” update=”comments”>comments</g:remoteLink>

As you can see, we provide the server.id and we update the div with id comments.

This does not work out of the box, you must specify the prototype javascript library to be included. You can do this in the file:

views > layouts > main.gsp

Add the following line:

<g:javascript library=”prototype” />

Now everything should be fine and you can test the application. A command like grails run-app should be enough.

Documentation

If you want more information about grails, try the following references:

• http://grails.org/doc/1.1.x/
• http://groovy.codehaus.org/groovy-jdk/
• http://www.manning.com/gsmith/
• http://www.jetbrains.com/idea/nextversion/index.html
• http://www.springsource.com/training/grv001
• http://www.springsource.com/products/sts

Grails and google app engine

Grails uses plugins for all additional functionality. There is also a plugins available for google app engine. There is already good documentation available for this plugin. Therefore I keep this short. The following code block shows the commands. For more information, check the website of the plugin:

http://grails.org/plugin/app-engine

# grails create-app share-this
# grails uninstall-plugin hibernate
# grails install-plugin app-engine
choose jpa when asked
# export APPENGINE_HOME=<path to your sdk install of google app engine>
# grails app-engine run
# grails set-version 1
# grails app-engine package
# $APPENGINE_HOME/bin/appcfg.sh update ./target/war
# grails install-plugin gorm-jpa

Than I used intellij to create some domain classes and controllers. Take the following into consideration.

• Put domain classes in a package or it won’t work
• Put Controller classes in the same package
• generate views, the auto scaffolding seems not to work.

You can look at the result here : http://share-this.appspot.com/. It could well be that the app does not start the first time, a refresh might help. I’ll have a look at this in the future. There is a problem with the CPU consumption and my grails application.