Grails Web Services

In this blog we’ll expose a Grails service as a SOAP service. According to good practice we’ll build the WSDL first and then write the implementation code.
First things first. Let’s create a new grails application and call it grails-soap

grails> create-app grails-soap



For SOAP support we’ll be using the Grails CXF plugin. Just add the following line in the plugin section of your BuildConfig.groovy file to enable the plugin. Documentation for the plugin can be found here.

compile ':cxf:1.1.1'



We’ll start with building the WSDL for the service. The service will be called DepartmentService and will return some Department data for a given id. We’ll place the WSDL in the src/java folder.

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions name="DepartmentService"
	targetNamespace="http://devjournal/DepartmentService" xmlns:wsdl=""
	xmlns:xsd="" xmlns:soap12=""
		<xsd:schema xmlns="">
			<import namespace="http://devjournal/DepartmentService"
				schemaLocation="DepartmentService.xsd" />
	<wsdl:message name="DepartmentServiceRequestMessage">
		<wsdl:part name="in" element="tns:DepartmentServiceRequest" />
	<wsdl:message name="DepartmentServiceResponseMessage">
		<wsdl:part name="out" element="tns:DepartmentServiceResponse" />
	<wsdl:portType name="GetDepartmentById">
		<wsdl:operation name="getDepartmentById">
			<wsdl:input message="tns:DepartmentServiceRequestMessage" />
			<wsdl:output message="tns:DepartmentServiceResponseMessage" />
	<wsdl:binding name="GetDepartmentByIdSoap12" type="tns:GetDepartmentById">
		<soap12:binding transport=""
			style="document" />
		<wsdl:operation name="getDepartmentById">
				style="document" />
				<soap12:body use="literal" parts="in" />
				<soap12:body use="literal" parts="out" />
	<wsdl:service name="DepartmentService">
		<wsdl:port binding="tns:GetDepartmentByIdSoap12" name="GetDepartmentByIdSoap12">
			<soap12:address location="" />

The underlying xml schema file contains the response element. This file will also be placed in the src/java folder.

<?xml version="1.0" encoding="UTF-8"?>
<schema attributeFormDefault="unqualified" elementFormDefault="qualified"
 <element name="DepartmentServiceRequest">
    <element name="Id" type="int"/>
 <element name="DepartmentServiceResponse">
    <element name="Department" type="tns:departmentType" maxOccurs="1"
 <complexType name="departmentType">
   <element name="Id" type="int"/>
   <element name="Name" type="string"/>
   <element name="Location" type="string"/>



Now that we have the WSDL it’s time to generate the Java stubs. Although the CXF plug-in comes with a wsdl-to-java command it kept giving me a “GroovyCastException” when I tried to run it. To workaround this problem, I downloaded the latest apache-cxf distribution here (2.7.11 at the time of this writing) and used its wsdl2java command to generate the stubs.

$ $CXF_HOME/apache-cxf-2.7.11/bin/wsdl2java DepartmentService.wsdl

After running this command from within the /src/java directory, the following stub classes are added to your grails application:

wsdl2java classes

wsdl2java classes



Now everything is in place, we can start implementing the service. First create a new grails service component called DepartmentService

grails> create-service department

We’ll have this service implement the generated @WebService interface GetDepartmentById and override the getDepartmentById method (corresponding with the SOAP operation of the same name) For simplicity sake, we’ll just hardcode a response:

package grails.soap

import javax.jws.WebService

import org.grails.cxf.utils.EndpointType

import devjournal.departmentservice.DepartmentServiceRequest
import devjournal.departmentservice.DepartmentServiceResponse
import devjournal.departmentservice.DepartmentType
import devjournal.departmentservice.GetDepartmentById

@WebService(targetNamespace = "http://devjournal/DepartmentService", name = "GetDepartmentById", serviceName = 'DepartmentService',
portName = 'GetDepartmentById')
class DepartmentService implements GetDepartmentById {

	static expose = EndpointType.JAX_WS_WSDL
	static soap12 = true
	static address = 'DepartmentService'
	def serviceMethod() {

	public DepartmentServiceResponse getDepartmentById(
			DepartmentServiceRequest departmentServiceRequest) {

		DepartmentType department = new DepartmentType(id:, location:'Amsterdam', name: 'Sales')
		return new DepartmentServiceResponse(department:department)

As you can see in the code above, we’ve implemented the GetDepartmentById interface and added the @WebService annotation to the service. With the serviceName and portName attributes we can influence the WSDL that’s eventually being served.
The cxf-plugin allows further configuration by means of static properties. Setting the soap12 property to “true” makes the DepartmentService adhere to the SOAP 1.2 specification. With the address property we can adjust the endpoint of the service. By default it would be the default address of the grails service, i.e. “/services/department”. In the above example the endpoint will be “/services/DepartmentService”. Refer to the cxf-plugin documentation for an overview of available properties.

Testing the web service

Now let’s fire up the application and give it a spin

grails> run-app

The WSDL should be available at http://localhost:8080/services/DepartmentService?WSDL and can be tested with SoapUI. The screenshot below shows the result.

DepartmentService Test

DepartmentService Test



In this blog I’ve shown how easy it is to expose a grails service via SOAP. Although the service had been turned into a SOAP service it’s still available as a normal grail service to the rest of the application, so there’s no violation of the DRY principle and code can be reused.

Grails in the Cloud Foundry

In this blog I’ll show you how easy it is to get a small Grails app up and running on Cloud Foundry making use of a mysql service provided by Cloud Foundry. We’ll be using the Groovy & Grails Toolsuite (ggts) for this, but I’ll also show you the grails commands you can use to accomplish each individual step.


  • At the time of this blogpost I’m using ggts version 3.1.0.RELEASE based on Eclipse Juno 4.2.1, which can be downloaded right here;
  • ggts comes with a full Grails installation. To make use of command line grails commands outside of the IDE, set the following environment variables. If you’re an Ubuntu user like me, just add these two lines to your ~/.bashrc file:
    • export GRAILS_HOME=<ggts_home>/grails-2.1.1;
    • export PATH=$PATH:$GRAILS_HOME/bin;
  • Apply for a Cloud Foundry account right here. You’ll receive an email of approval which will contain your  password;
  • Enable Cloud Foundry Integration in ggts. Click the Extensions link on the Dashboard, scroll down to Cloud Foundry Integration for Eclipse and install it.
Screenshot from 2013-02-17 15:40:52

Cloud Foundry Integration for Eclipse

Building a simple Grails app

We’re gonna develop a very simple Grails app. Just enough for demonstration purposes. It’ll be an app that enables you to create notes and store them in a database. We’ll call it one-note.

Grails Project

Choose File > New > Grails Project and supply the project-name. Alternatively you could use the command line and type:

grails create-app one-note

There’s also a command line interface available in ggts itself (Navigate > Open Grails Command Prompt). All commands are available here (just ommit the grails prefix), except for the creation of an application.

Screenshot from 2013-02-24 16:54:11

Grails Command Prompt

Domain Class

Choose File > New > Domain Class and name it Note. The Note.groovy domain class will be created for you. You can also create the class via this command line:

grails create-domain-class note

Add two simple fields to the domain class, so it looks like this:

package one.note

class Note {

    String content
    Date dateCreated

    static constraints = {

The dateCreated is a standard field which will be supplied for by the Grails framework, the content field will contain the actual note.


Choose File > New > Controller and name it NoteController. The NoteController.groovy controller will be created for you. The equivalent command would be

grails create-controller note

Add scaffolding and reroute the index action to the list action. Your controller should now look like this

package one.note

class NoteController {

    def scaffold = true

    def index() {

Testdrive the application

That’s basically all we need to run the application locally and make use of an in-memory hsqldb. Select Run > Run As > Grails Command (run-app), and point your browser to http://localhost:8080/one-note and you’re good to go. Select the NoteController in the Overview page, create some notes and your application should resemble the picture below.

Screenshot from 2013-02-24 18:05:49

one-note Grails application

Alternatively you could achieve the same via the command line:

grails run-app

Publish to Cloud Foundry

Although not entirely necessary, it’s a good practice to change your production configuration in the Datasource.groovy file. Add the following lines

environments {
    production {
        dataSource {
            dbCreate = &quot;update&quot;
            driverClassName = &quot;com.mysql.jdbc.Driver&quot;

Furthermore edit the BuildConfig.groovy and add the following dependency:

dependencies {
runtime &quot;mysql:mysql-connector-java:5.1.23&quot;

Cloud Foundry Integration style

Add a new server (File > New > Other > Server) and select Cloud Foundry as the type.

Screenshot from 2013-02-24 18:33:21

New Server > Define a New Server

Fill in your Cloud Foundry account information and press Validate Account to make sure you entered everything correctly.

Screenshot from 2013-02-24 18:33:35

New Server > Cloud Foundry Account

Now go to the Applications tab and Add the one-note application from Available to Configured and click Finish.

Change Runtime to Java 7, click Next >

Screenshot from 2013-02-24 18:38:11

Application > Application Details

Note the Deployed URL and click Next >

Screenshot from 2013-02-24 18:39:22

Application > Launch deployment

Click Add Service to add a mysql service, give it a name (I choose one-note) and select MySQL database as the type and click Finish.

Screenshot from 2013-02-24 18:40:33

Add Service > Service Configuration

Make sure, the new mysql service is selected and click Finish.

Screenshot from 2013-02-24 19:14:44

Application > Services selection

Now the application will get started and you’ll get a nice overview of your application running in Cloud Foundry.

Screenshot from 2013-02-24 18:49:41

Application overview

Also take note of the Remote Systems window in ggts. Here you can for one take a look at all the log files in your Cloud Foundry environment.

Screenshot from 2013-02-24 13:17:11

Remote Systems

That’s it. You can now test your application on the following url:

Screenshot from 2013-02-24 19:00:21

one-note in the cloud

Command line style

To enable Cloud Foundry commands via the command line you have to add a plugin to the application:

grails install-plugin cloud-foundry

Next add the following two lines to the ~/.grails/settings.groovy file:
grails.plugin.cloudfoundry.username = “yourusername”
grails.plugin.cloudfoundry.password = “yourpassword”

Now you can push the one-note application to Cloud Foundry:

grails prod cf-push

Accept the default url and  choose y at “Would you like to create and bind a mysql service” and n at the same question for a postgresql service.

While building the war for deployment, you might see and Error about a missing migrations directory. This is caused by the database-migration plugin. It’s harmless, but if you want to get rid of it, just add the migrations directory in the grails-app subdirectory of the application.

That’s it. You can test the application via the same url we used before when we used Cloud Foundry Integration:

There are lots of command available in the plugin. There are for example commands for restarting and deleting a deployed app or service. You can display the list of available commands with:

grails cf-help


In this blogpost we’ve built a simple Grails application and pushed it to Cloud Foundry, making use of a mysql database service. We’ve shown how to do it via the command line as well as via the Groovy/Grails Tool Suite with the Cloud Foundry Integration plugin. Whichever way you prefer, both ways are very powerful very easy to use. I myself often use a hybrid approach. For the creation of components and pushing the application to the cloud, I use the command line approach . And for managing the deployed applications, I make use of the nice overview interface that the Cloud Foundry Integration Plugin provides.


Mule – Building a webservice proxy

In this blogpost we’ll develop a simple webservice proxy using the latest Mule Studio Community Edition (currently version 1.3.1 which uses Mule ESB v.3.3), which can be downloaded here. The proxy will do some basic routing. No transformation will be done. That area will be explored in a future blogpost.

webservice proxy

mule proxy service

The webservice which will be used for proxying is a simple jax-ws webservice for retrieving employee data based on their department id. The webservice will be exposed via the following url: http://localhost:8083/HR/hrManagerService?wsdl. See this blogpost for building a simple jax-ws webservice on your own.

Creating a new Mule project

First we’ll create a new Mule project based on Maven. This can be done in 3 simple steps. First select File > New > Mule Project. Give the project a Name and a Description and click Next >.

Screenshot from 2013-01-03 12:35:35

New Mule Project – Step 1 of 3

Now, create a flow for the project. Give it a Name, File name and a Description and click Next >.

Screenshot from 2013-01-03 12:35:55

New Mule Project – Step 2 of 3

Finally select the option for creating the Maven pom.xml file and fill in a Group Id and Artifact Id and click Finish.

Screenshot from 2013-01-03 12:39:13

New Mule Project – Step 3 of 3

That’s all. We’ve created the skeleton for our web service proxy and are now ready to implement the flow.

Building the flow

Open the mule-proxy.mflow file and drag a Flow Scope into it. Give it an appropriate name, like MuleProxyFlow.



Now let’s build the flow for the proxy service back to front. We’ll begin with adding a HTTP Endpoint to the flow which will resemble the webservice we’re gonna proxy. Right click the Endpoint and select Convert to an outbound endpoint. Next select Properties, clear the Host and Port values and fill in the endpoint of the webservice in the Address field.

Screenshot from 2013-01-03 14:34:20

HTTP Outbound Endpoint Properties – General

Screenshot from 2013-01-03 14:41:01

HTTP Outbound Endpoint Properties – Advanced

Next, we’ll create a client for the web service. Select a SOAP Component and drag it to the left of the HTTP Endpoint. Change the Operation field to Proxy client.

Screenshot from 2013-01-03 14:54:31

SOAP Component – Proxy client

Now for the actual proxy service. Select another SOAP Component and drag it to the left of the Proxy client SOAP Component. Change the Operation to Proxy service. Fill in the Namespace and Service as well. They have to match the targetNamespace and name of the webservice as defined in the wsdl we’re gonna use for the proxy. Make sure that the Payload of the Proxy service and Proxy client match (in this example I choose to only exchange the SOAP body).

Screenshot from 2013-01-03 15:12:52

SOAP Component – Proxy service – General

In the Advanced section we’ll fill in the WSDL Location of the actual wsdl, which will serve as the wsdl for the proxy service. In this simple example, the wsdl of the proxy will match the wsdl of the actual webservice. I’ve raken the liberty to copy the wsdl and xsd files to the src/main/resources/wsdl and src/main/resources/xsd directories of the project. But for the sake of simplicity, you could also pick up the wsdl from it’s actual location, i.e. http://localhost:8083/HR/hrManagerService?wsdl and use that as the WSDL Location in the case of this example.

Screenshot from 2013-01-03 17:57:42

SOAP Component – Proxy service – Advanced

Finally, we’ll need to add the HTTP inbound endpoint. Again, clear the Host and Port fields and add the Address you’d like to use for the proxy, in this example it will be http://localhost:8081/hrManagerServiceProxy.

Screenshot from 2013-01-03 15:27:38

HTTP Inbound Endpoint Properties – General

Screenshot from 2013-01-03 15:27:50

HTTP Inbound Endpoint Properties – Advanced

That’s it. If you followed these steps correctly, your flow should resemble the flow below.



The xml configuration (src/main/app/mule-proxy.xml) should look like the code below.

<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns:cxf="" xmlns:http="" xmlns="" xmlns:doc="" xmlns:spring="" version="CE-3.3.0" xmlns:xsi="" xsi:schemaLocation=" ">
  <flow name="MuleProxyFlow" doc:name="MuleProxyFlow">
    <http:inbound-endpoint exchange-pattern="request-response" address="http://localhost:8081/hrManagerServiceProxy" doc:name="HTTP"/>
    <cxf:proxy-service namespace="" service="HRManagerServiceImplService" payload="body" doc:name="SOAP" enableMuleSoapHeaders="false" wsdlLocation="wsdl/hrManagerService.wsdl"/>
    <cxf:proxy-client doc:name="SOAP" payload="body"/>
    <http:outbound-endpoint exchange-pattern="request-response" address="http://localhost:8083/HR/hrManagerService" doc:name="HTTP"/>

Testing the proxy

Mule Studio

Now, let’s run the Mule proxy. You can do this directly inside Mule Studio by choosing Run As > Mule Application.


You can also use maven via the command line:

mvn clean install

There’s a small issue with the generated pom.xml file in this version of the Community Edition. If you use it as is, you’ll get an error concerning missing dependencies. To fix this, open the pom.xml file and search for the following snippet:

<!-- Xml configuration -->

Replace it with this one:

<!-- Xml configuration -->

Also you need to have a mule server running for this to work. See this blogpost for details. The install goal will deploy the mule project to the $MULE_HOME/apps directory of the mule server installation and if the server is running, it wil startup the project automatically.


Regardless of the way you’re running the mule project, be it via Maven or via Mule Studio, you should be able to test the proxy now with soapUI. Create a New Project, point it to the wsdl of the proxy, i,e. http://localhost:8081/hrManagerServieProxy?wsdl, and add a default TestSuite. Now you can run a TestCase against the proxy and it should yield the same result as it would when you’d call the webservice behind it directly.

Screenshot from 2013-01-03 21:26:50

soapUI – Testing the proxy


In this blogpost we’ve created a simple webservice proxy which does some basic routing without any kind of transformation. In the next post we’ll add some transformation and basic logging to the mix.

Getting started with Mule

I intend to write a few blogs about Mule, probably the most-used open source Enterprise Service Bus out there. This blog will cover the basics to get Mule up and running.

Installing Mule

Installation of Mule is pretty straightforward:

  • Download the latest Mule ESB Community Edition here;
  • Extract the downloaded archive to a directory of your choice;
  • If you plan to use Maven, set the MULE_HOME environment variable, eg. in your .bashrc file for Ubuntu:
    export MULE_HOME=~/Applications/mule-standalone-3.1.2
  • You can now run the server via the following command (on Ubuntu):

Hello World!

To build a simple Hello World example directly in Eclipse follow this tutorial on the Mule website. It also shows you how to install and use the mule plugin for eclipse.

Using Maven

If you’re like me and like to use Maven, there’s a maven plugin available to quickly create a basic mule standalone project.
The basic command for creating a mule project with the plugin is

mvn mule-project-archetype:create -DartifactId=HelloMule -DmuleVersion=3.1.2

To quickly setup a basic project check out this site. If you follow the example a simple maven project is created.
You can “eclipsify” this project via the following maven command:

mvn eclipse:eclipse

Now, you can import the project in Eclipse.

The generated project

The generated project contains a simple mule configuration:

  &lt;flow name=&quot;main&quot;&gt;
        &lt;vm:inbound-endpoint path=&quot;in&quot; exchange-pattern=&quot;request-response&quot;/&gt;
        &lt;vm:outbound-endpoint path=&quot;out&quot;/&gt;

As you can see, the example is very simple. It contains two in-memory queues. You can send some text in the vm://in queue and it gets echoed out into the vm://out queue.

Fixing the testcase

Before you can run the example, there’s an error in the generated test case, that needs to be solved first (or you can skip the test when running maven of course).
The configuration for the test case, called artifactId-functional-test-config.xml is similar to the main configuration:

    &lt;flow name=&quot;main&quot;&gt;
        &lt;vm:inbound-endpoint path=&quot;in&quot; exchange-pattern=&quot;request-response&quot;/&gt;
        &lt;test:component appendString=&quot; Received&quot;/&gt;
        &lt;vm:outbound-endpoint path=&quot;out&quot;/&gt;

As an extra bonus it appends ” Received” to the input string before it is sent to the vm://out queue.
The unit test contains the following code:

    public void testHelloMule() throws Exception
        MuleClient client = new MuleClient(muleContext);
        MuleMessage result = client.send(&quot;vm://in&quot;, &quot;some data&quot;, null);
        assertFalse(result.getPayload() instanceof NullPayload);
        assertEquals(&quot;some data Received&quot;, result.getPayloadAsString());

If you run the test goal, this test case will fail on line 7. The problem is that the input string is sent to the vm://out queue, hence the synchronous result is an empty mule message. To fix this, you can either change the configuration, so that the input is not passed to the vm://out queue, like this:

    &lt;flow name=&quot;main&quot;&gt;
        &lt;vm:inbound-endpoint path=&quot;in&quot; exchange-pattern=&quot;request-response&quot;/&gt;
        &lt;test:component appendString=&quot; Received&quot;/&gt;

The other option is to adjust the test case, so that the result is read from the vm://out queue:

    public void testHelloMule() throws Exception
        MuleClient client = new MuleClient(muleContext);
        client.send(&quot;vm://in&quot;, &quot;some data&quot;, null);
        MuleMessage result = client.request(&quot;vm://out&quot;, 5000);
        assertFalse(result.getPayload() instanceof NullPayload);
        assertEquals(&quot;some data Received&quot;, result.getPayloadAsString());

Installing the mule project

After you fixed the bug in the testcase, you can install the application.

mvn clean install

This will package the project into a zip file and copy this file to the $MULE_HOME/apps directory. Here Mule will pick it up and deploy the file.

For now it doesn’t do much besides creating the 2 in-memory queues. In the next blog, I’ll dive a little deeper into Mule and show some basic configurations.


As a small reference, there’s a DZone refcard available containing an overview of Mule 3 commands.

Developing a contract-first JAX-WS webservice

In this blog i’ll develop a simple webservice using JAX-WS. I’ll first start with the contract (wsdl and xsd’s). The contract will be used for generating the necessary JAXB artifacts. Getting the webservice up and running will be a piece of cake after that all thanks to Maven and JAX-WS.
First things first, let’s create a new Maven project. I’m using Netbeans as IDE for this.

New Maven Web Application

First Create a new Maven Web Application

and call it hello_person for example

The Contract

The webservice will accept a Person graph with a first and last name and will return a concatenated “Hello first name last name!”. Not very original but good enough for the example.
First we’ll define the xsd called helloPersonService.xsd for the request and response. The request will contain a Person object with a first and last name, the response will contain a Greetings string. We’ll store it in src/main/resources/xsd.

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd=""
    <xsd:element name="HelloPersonServiceRequest" type="HelloPersonServiceRequestType"/>
    <xsd:element name="HelloPersonServiceResponse" type="HelloPersonServiceResponseType"/>

    <xsd:complexType name="HelloPersonServiceRequestType">
        <xsd:element name="Person" type="PersonType"/>
    <xsd:complexType name="HelloPersonServiceResponseType">
        <xsd:element name="Greetings" type="xsd:string"/>

    <xsd:complexType name="PersonType">
            <xsd:element name="FirstName" type="xsd:string"/>
            <xsd:element name="LastName" type="xsd:string"/>

Now we’ll define a wsdl called helloPersonService.wsdl and we’ll store it in src/main/resources/wsdl

<?xml version="1.0" encoding="UTF-8"?>
        <xsd:schema targetNamespace="">
            <xsd:import schemaLocation="../xsd/helloPersonService.xsd"
    <wsdl:message name="HelloPersonServiceRequest">
        <wsdl:part name="HelloPersonServiceRequest" element="tns:HelloPersonServiceRequest"/>
    <wsdl:message name="HelloPersonServiceResponse">
        <wsdl:part name="HelloPersonServiceResponse" element="tns:HelloPersonServiceResponse"/>
    <wsdl:portType name="HelloPersonServicePortType">
        <wsdl:operation name="greetPerson">
            <wsdl:input name="HelloPersonServiceRequest" message="tns:HelloPersonServiceRequest"/>
            <wsdl:output name="HelloPersonServiceResponse" message="tns:HelloPersonServiceResponse"/>
    <wsdl:binding name="HelloPersonServiceBinding" type="tns:HelloPersonServicePortType">
        <soap:binding style="document" transport=""/>
        <wsdl:operation name="greetPerson">
            <soap:operation style="document" soapAction=""/>
            <wsdl:input name="HelloPersonServiceRequest">
                <soap:body use="literal"/>
            <wsdl:output name="HelloPersonServiceResponse">
                <soap:body use="literal"/>
    <wsdl:service name="HelloPersonService">
        <wsdl:port name="HelloPersonServicePort" binding="tns:HelloPersonServiceBinding">
            <soap:address location="/service/helloPersonService" />

Getting the pom right

Next up is adding the necessary component to the pom file. We need the jax-ws runtime libraries, the jetty plugin as we use jetty as the servlet container, and the jaxws-maven-plugin for generating the java code from the contract. I’ve highlighted these dependencies in the pom file below.

<project xmlns="" xmlns:xsi=""
    <name>hello_person Java EE 6 Webapp</name>
            <name>Repository hosting the jee6 artifacts</name>
            <name>Repository hosting the jee6 artifacts</name>





                        <connector implementation="org.eclipse.jetty.nio.SelectChannelConnector">



Writing the implementation

First, let’s do a Clean and Build in NetBeans. This will generate the JAXB/JAX-WS artifacts from the contract.
Notice that the jaxws-maven-plugin has generated an interface called nl.example.hello_person.service.generated.HelloPersonServicePortType for the PortType in the wsdl. This is the interface we have to implement. The code for the implementation is pretty straightforward. I’ve added it below for convenience. Notice that the implementation class is called nl.example.hello_person.service.HelloPersonServiceImpl. We’ll need this in one of the next steps. Also notice the necessary @WebService annotation. The endpointInterface atribute points of course to the generated interface.

package nl.example.hello_person.service;

import javax.jws.WebService;
import nl.example.hello_person.service.generated.HelloPersonServiceRequestType;
import nl.example.hello_person.service.generated.HelloPersonServiceResponseType;

public class HelloPersonServiceImpl implements nl.example.hello_person.service.generated.HelloPersonServicePortType {

    public HelloPersonServiceResponseType greetPerson(HelloPersonServiceRequestType helloPersonServiceRequest) {
        HelloPersonServiceResponseType helloPersonServiceResponse = new HelloPersonServiceResponseType();
        helloPersonServiceResponse.setGreetings("Hello " + helloPersonServiceRequest.getPerson().getFirstName() + " " + helloPersonServiceRequest.getPerson().getLastName() + "!");
        return helloPersonServiceResponse;


The web.xml file

Now, add a web.xml file to the project (you can do this via New File > Web > Standard Deployment Descriptor (web.xml)) and add the proper configuration for the jax-ws servlet to it:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns=""
        <description>JAX-WS endpoint</description>
        <display-name>The JAX-WS servlet</display-name>

The sun-jaxws.xml file

The last step is adding the sun-jaxws.xml file to the WEB-INF directory of the project. This is the content of the file:

<?xml version="1.0" encoding="UTF-8"?>
        url-pattern='/helloPersonService' />

Notice that the implementation attribute is pointing to our implementation class.

Running the service

Add jetty:run as custom action (via Run > Set Project Configuration > Customize > Actions) and run it.
Now open a browser and check the following url http://localhost:8083/hello_person/helloPersonService. If you see the following screen, the webservice is up and running!

Testing the service

For testing I’m using the soapUI plugin for Netbeans.
After you’ve installed the plugin, you can create a new Web Service Testing Project (New Project > SOA > Web Service Testing Project)

Point the initial WSDL property to the url you’ve seen on the Web Services page: http://localhost:8083/hello_person/helloPersonService?wsdl.

The testsuite now contains a greetPerson Test Step. You can now test if the service works. If all goes well, you should see something similar to the picture below.

Cloning a VirtualBox openSUSE image

I recently tried to clone an openSUSE VirtualBox image. I thought it would be as simple as just copying the virtual disk image (vdi) file and create a new virtual machine based on it. So that’s what i did. But when i tried to couple the new hard disk file to the virtual machine VirtualBox gave me the following error:

Apparently a new virtual disk image in VirtualBox needs a unique identifier key. So after some research i found out it’s possible to make a clone of a hard disk that has a different unique identifier. But unfortunately that’s not all of the story. You have to make some additional changes to the clone to make it all work. So here are the steps you need to follow to make a successful clone.

1. Clone the hard disk

To clone the hard disk open a terminal window and issue the following command:

VBoxManage clonevdi <original>.vdi <clone>.vdi

2. Create a new Virtual Machine

Now create a new virtual machine with basically the same settings as the original virtual machine and couple it to the new cloned virtual disk image. As this image has been given a new unique identifier, you should have no problem registering it now.

3. Alter the hard disk identifiers

Having cloned the virtual disk image, i thought i was ready to roll. But on startup i encountered the following problem:

Apparently part of the UUID of the virtual disk image is used to identify the hard disk on startup. We have to change these references to their appropriate new ids.

3a. Startup in rescue mode

To startup the openSUSE vm in rescue mode insert the iso file you used for installation in the CD Drive of the vm. Upon startup select the Rescue System option from the menu.

3b. Mount the hard disk

Login as root and mount the hard disk (on my system this was /dev/sda2, this could be different on your system) via the following command:

mount /dev/sda2 /mnt

3c. Alter the identifiers

Now first find out what the new identifier of the hard disks should be. Issue the following command

hdparm -i /dev/sda

Note the identifier called SerialNo. This is the one you need. On my system it was VBa79c17fb-f28bb7c1.
Now there are 2 files you need to alter. First edit the file /mnt/etc/fstab and alter all the identifiers between /dev/disk/by-id/ata-VBOX_HARDDISK_ and -partx with the new identifier.
Next make corresponding changes to the file /mnt/boot/grub/menu.lst.
After this you can reboot the system

shutdown now -r

4. Repair your network settings

If you made no typos, openSUSE should start up with no problems. There’s one piece of configuration to do though. The clone has messed up the network configuration. This can be easily repaired via the YaST GUI tool. Open it and select Network Devices > Network Settings. You should see 2 Ethernet Controllers. One of them is not configured. Configure this controller with default settings and delete the other one. Now your clone is ready for use.

Devoxx 2010 impressions – day 2

My second and (unfortunately) last day at Devoxx i visited two completely different talks.

The first talk was about Cassandra, one of the many nosql databases that have emerged in the last years. Nosql was definitely one of the biggest topics on Devoxx. Four university slots were reserved for it. Apart from the Cassandra talk, there was a talk on Hadoop, MongoDB and HBase.

The second talk discussed two of the most used JavaScript libraries today, Prototype and jQuery.

Cassandra by Example

by Jonathan Ellis

Cassandra is one of the many nosql databases around. It offers scalability, reliability and high availability. It has good clustering and failover capabilities. It also integrates some Hadoop functionality for analyzing its datastore. Currently it has support for Pig and Hive. The scalability and reliability comes at price though. Cassandra doesn’t support ACID transactions and has only limited support for ad-hoc queries (hence the name nosql). This makes it especially suitable for very large internet applications where ACID isn’t that big a deal. Applications like Twitter and Facebook come to mind.

The idea behind Cassandra (and other nosql databases) is that IO should be optimized. Data closely related to each other is stored (often redundantly) close together on disk, thus significantly reducing IO overhead. Compared to relational databases, where scaling is accomplished predominantly by increasing cpus and memory, Cassandra scales by optimizing IO which comes at the cost of increased disk space. But since disk space had become relatively cheap these days, as compared to memory and processor units, this is a fair price to pay.

There is a another price to pay however. As mentioned, Cassandra stores a lot of data redundantly. Data related to a particular query eg. is stored in one row. This highly increases complexity. Since Cassandra doesn’t support referential integrity, so there’s no such thing as a cascaded delete for example, it’s up to the application (hence the programmer) to make sure that the stored data remains consistent with the datamodel. And as mentioned before there is limited support for ad-hoc querying

A good deal of the talk showed some examples on Cassandra’s shell client and Cassandra’s java api Hector. The examples were pretty complex, and coding against the API comes with a lot of boilerplating. Jonathan made and interesting comparison. He compared Hector with JDBC (for relational databases) and foresaw a JPA-like API in the near future. Now this would be really interesting from a JEE programmer point of view. JPA could abstract away the fact that you’re programming against a nosql database! All the examples Jonathan showed,  belonged to an online example Twitter-like application called Twissandra. The example project regarding Hector is called Twissjava.

At the end Jonathan mentioned some more advanced features of Cassandra

  • Batch insertions;
  • Secundary indexes, i.e. the ability to add indexes on additional columns in a row;
  • SuperColumns, which are basically maps of columns, used to denormalize data to avoid extra queries;
  • RipCord, a management suite for Cassandra;
  • JMX monitoring.

All in all, a very interesting talk. I’m definitely going to dive in in this topic in the near future.

And here’s a link to the slides.

Ajax Library Smack down: Prototype vs. jQuery

by Nathaniel Schutta

In the first half of his very inspiring talk Nathaniel Schutta compared two of the most used JavaScript libraries, i.e. Prototype and jQuery. Both have their pros and cons and which one is best suited for the job is mostly a matter of taste.

Both libraries offer a lot of the same goodies:

  • cross browser abstractions;
  • simplified AJAX;
  • CSS selectors;
  • event handling;
  • widgets, effects, animations;
  • javascript utilities.

Both have excellent online documentation available, are widely used, have good community support and are very small libraries.

Apart from the similarities, there are also a lot of differences between the two. According to Nathaniel Prototype has been developed from a programmer’s viewpoint (API centric), whereas jQuery is more focussed on HTML elements. Here’s a list of the pro’s and con’s.

Prototype pros:

  • adds useful functions to core elements (on very very large pages this can cause a significant memory footprint);
  • widgets and effects available via;
  • ruby flavored javascript;
  • widely used.

Prototype cons:

  • no minified version;
  • performance not always a priority;
  • pollutes the global namespace.

jQuery pros:

  • focussed on HTML elements;
  • doesn’t pollute global namespace;
  • dom traversal is a snap;
  • extensive array of plugins available.

jQuery cons:

  • parameter ordering in apis not alway intuitive;
  • plugins required for a variety of functionality;
  • some functions reassign this.

I’m definitely not an expert on using either one of these libraries but after Nathaniel compared both libraries i think jQuery has a slight advantage. This is because it had plugins in mind when it was first designed. There are a lot of plugin libraries available and you can pick the ones you need and omit the ones you don’t need. In Prototype you only have two options: with or without

In the second half of his talk he showed some nice examples on using jQuery. One of the points he made is that contrary to public opinion JavaScript isn’t that hard a language. And indeed all his examples where pretty simple. He also stressed the point that code should be self explanatory, so the name of a method for example is very important and should clearly and without any reason for debate state what the method actually does. And of course on more than one occasion he made a case that the question of using one of the open-source JavaScript libraries or not is a no-brainer.
All probably very open doors to most programmers, but still i honestly believe that in practice a lot of these rules are violated.

Here’s a link to the slides.


Get every new post delivered to your Inbox.

Join 72 other followers

%d bloggers like this: