The Server Labs Blog

Thoughts on Devoxx

Kevin McCormack — Mon, 15 Dec 2008 08:32:12 +0000

Wow! What an intense 3 days Devoxx is. Between the conference and the traveling and (of course!) those famous Belgian beers, it was an action-packed trip.

We enjoyed the conference a lot. It was professionally organised, had good speakers and had great food too. They even managed to keep the wireless network more-or-less functional with over 3000 bandwidth-hungry developers trying to use it all at once.

Unsurprisingly, the talks reflected the current themes in the Java world. There was a large focus on RIA (Rich Internet Application) technologies, dynamic languages and modularization.

JavaFX and Flex grabbed all the attention in the RIA category at the expense of some of the more traditional UI Technologies (JSF 2.0 and Dojo/DWR). I personally was quite disappointed with the standard of the JavaFX presentations, especially since it was one of the topics I was most interested in learning about. Inevitably JavaFX as a technology is going to be compared against Flex but I feel I didn’t even see enough code or information to make a comparison. The Flex presentations were of a considerably higher standard.

The second day opened with a keynote from Mark Reinhold about Java 7 in general and, more specifically, the project to modularize the JDK - Project Jigsaw. Later Alex Buckley gave us more details on the possible Java language changes to support modularization. Modularization was also heavily in evidence in the Springsource DM Server presentations that we attended. It’s been obvious for a while now that this is the way forward for Java.

Talk of the conference probably went to Joshua Bloch who gave an interesting and dynamic keynote on Effective Java that taught us a thing or two that we didn’t know about Java. The man was just a bundle of enthusiasm and energy on the stage.

Other talks that caught our attention were ones on Scala, REST and JAX-RS. Scala because we’d not had a chance to take a look at the language and the REST/JAX-RS talks because they summed up the technologies in such a way that they became clearer and easier to understand.

Finally, we’d like to mention the talk given by Ari Zilka on Terracotta as a great example, based on their Examinator web reference application, of a presentation on the usage of a technology in the real world - something that is sadly lacking sometimes at conferences such as these which are, understandably, focussed on promoting new technologies via simple ‘hello world’ examples.

That’s all for now. In the coming days, we’ll write in more detail about some of the more interesting things that we saw….

Hello from Devoxx

Kevin McCormack — Wed, 10 Dec 2008 09:12:51 +0000

This week, some The Server Labs employees are at the Java Devoxx conference in Antwerp, Belgium.

We’ve just had a human beat box guy warming the crowd up and he was great - some of the speakers are gonna have a problem to follow him!

We’ve taken a look at the schedule for today and it looks like we’re gonna see some really cool presentations on Spring, Security/Hacking, Performance/Concurrency and lots of rich internet apps - they’re giving the JavaFX keynote as I write this - lots of Adobe Flex and Air talks and even a Microsoft Silverlight talk.

We’ll try and give you some updates later on some of the more interesting talks.

Distributed JUnit testing with GridGain

Alfonso Olias — Mon, 24 Nov 2008 14:36:23 +0000

Recently we have been running some problems while testing distributed applications with JUnit. The main problem was that we were running the client and the server within the same host. Although the test passed because the application logic was correct. Running the application distributed failed due to some errors related with the naming of the processes that were related to localhost.

How to test distributed applications with JUnit?. The only product that can do that is GridGain. GridGain is an open source framework for distributed computing. It also provides a way of running tests distributed across many nodes. This means that we can parallelize our JUnit tests on different nodes and improve the overall time to get them done. But what it is more important for us. How to test distributed applications that require client server interaction.

Configuration
GridGain is easy to set up. Once you have downloaded and uncompressed the zip file. You only have to set up two environment variables JAVA_HOME and GRIDGAIN_HOME. Now you are ready to launch your remote execution node by executing the following script ./gridgain-junit.sh

Let’s make a JUnit test

I am using eclipse, but you can use your preferred java builder. Once you have created a project you only have to import the jar files included in the libs folder and also the gridgain-2.0.3.jar file. And you will be ready to implement you unit tests.

ServerTest class: This test just runs a server socket waiting for incoming calls. Reads a Date object instance sent by the client and prints it out.

import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.net.InetAddress;
import java.net.ServerSocket;
import java.net.Socket;
import java.net.UnknownHostException;
import java.util.Date;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;

public class ServerTest {
    /**
     * Set up logic.
     * @throws Exception Thrown in case of any error.
     */
    @Before
    public void beforeTest() throws Exception {
        System.out.println("Preparing for test execution: " + getClass().getSimpleName());
    }

    /**
     * Tear down logic.
     * @throws Exception Thrown in case of any error.
     */
    @After
    public void afterTest() throws Exception {
        System.out.println("Tearing down test execution: " + getClass().getSimpleName());
    }

    /**
     * Example test method.
     */
    @Test
    public void testServer() {
      boolean stop = false;
      ServerSocket serverSocket = null;
      final String hostName = "gaiawl06.net4.lan";
      try {
          InetAddress addr = InetAddress.getLocalHost();

          // Get IP Address
          byte[] ipAddr = addr.getAddress();
          // Get hostname
          if (hostName.compareTo(addr.getHostName())==0){
              serverSocket = new ServerSocket(4000);
              while (!stop){
                  Socket client =  serverSocket.accept();
                  System.out.println(getClass().getSimpleName() +" Incomming DATA! " + client.getInetAddress());
                  ObjectInputStream in = new ObjectInputStream(client.getInputStream());
                  ObjectOutputStream out = new ObjectOutputStream(client.getOutputStream());
                  final Date date  = (Date)in.readObject();
                  System.out.println(getClass().getSimpleName() +" Socket read Object from client " + date);
                  in.close();
                  out.close();
                  stop = true;
              }
          }
      } catch (UnknownHostException e) {

          e.printStackTrace();
      } catch (IOException e) {
          e.printStackTrace();
      } catch (ClassNotFoundException e) {
          e.printStackTrace();
      }finally{
          try {
              if(serverSocket != null){
                  serverSocket.close();
              }
          } catch (IOException e) {
              e.printStackTrace();
          }
      }
      System.out.println(getClass().getSimpleName() + "Output from TestC.testMethod1().");
    }
}

ClientTest class: This test just opens a socket to the remote server and sends a Date object instance to the remote server.

import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.net.Socket;
import java.util.Date;

import org.junit.After;
import org.junit.Before;
import org.junit.Test;

public class ClientTest {
    /**
     * Set up logic.
     * @throws Exception Thrown in case of any error.
     */
    @Before
    public void beforeTest() throws Exception {
        System.out.println("Preparing for test execution: " + getClass().getSimpleName());
    }

    /**
     * Tear down logic.
     * @throws Exception Thrown in case of any error.
     */
    @After
    public void afterTest() throws Exception {
        System.out.println("Tearing down test execution: " + getClass().getSimpleName());
    }

    @Test
    public void testClient() {
        try {
             System.out.println(getClass().getSimpleName() +" Wait 5 seconds server to start ");
             Thread.sleep(5000);
             final String hostName = "xxxxxxxxxxx";
             // open a socket connection
             Socket socket = new Socket(hostName, 4000);
             // open I/O streams for objects
             ObjectOutputStream ou = new ObjectOutputStream(socket.getOutputStream());
             ObjectInputStream in = new ObjectInputStream(socket.getInputStream());
             ou.writeObject(new Date());
             ou.flush();
             ou.close();
             in.close();
           } catch(Exception e) {
             System.out.println(e.getMessage());
          }
    }
}

You have to bear in mind that the ServerTest has to run at the remote host were the GridGain daemon is running. Just if you want the client to be able to connect the remote server.

Now is were the magic comes. We have to ensure that the ServerTest runs on the remote host and the ClientTest runs on the local host (my computer). In order to get this working we need three more classes:

RemoteTestSuite
LocalTestSuite
DistributedTestSuite

RemoteTestSuite class: It is used to set up the tests we want to run distributed. We only have to add the @GridifyTest annotation and we will enable this suite to run in our GridGain grid. This does not prevent the test to run locally, so if we want to enforce the test to run on the remote host we have to add the following JVM parameter -DGRID_ROUTER_PREFER_REMOTE=true

import org.junit.runner.RunWith;
import org.junit.runners.Suite;
import org.junit.runners.Suite.SuiteClasses;
import org.gridgain.grid.test.GridifyTest;

@RunWith(Suite.class)
@SuiteClasses(ServerTest.class)
@GridifyTest
public class RemoteTestSuite {
}

LocalTestSuite class: is used to run the client test locally. We only have to add the @RunWith(GridJunit4LocalSuite.class) annotation to enforce this test to run locally.

import org.gridgain.grid.test.junit4.GridJunit4LocalSuite;
import org.junit.runner.RunWith;
import org.junit.runners.Suite.SuiteClasses;

@RunWith(GridJunit4LocalSuite.class) // Specify local suite to run tests.
@SuiteClasses(ClientTest.class)
public class LocalTestSuite {
}

DistributedTestSuite class: is used to configure the distributed test we want to run. In our case is composed of two tests that will run in parallel and distributed. You will have to add the following annotation @RunWith(GridJunit4Suite.class) if you want GridGain to run the test.

This class is the one you have to run in your eclipse project and before running it you have to set up the JVM with the parameter I mentioned before.

import org.gridgain.grid.test.junit4.GridJunit4Suite;
import org.junit.runner.RunWith;
import org.junit.runners.Suite.SuiteClasses;

@RunWith(GridJunit4Suite.class)
@SuiteClasses({
    RemoteTestSuite.class,
    LocalTestSuite.class, // Local suite that will execute its test locally.
})
public class DistributedTestSuite {
}

Conclusions
GridGain is based on JGroups so be sure that the agents are on the same network If they do not see one each other you will not be able to send your tests to the remote node. It is pretty easy to set up and make it run. Even getting your Junit tests being executed distributed, it is very easy.
This product fills the gap for testing distributed applications with JUnit.

Database storage in TIBCO EMS 5.0

Haritza Zubillaga — Fri, 10 Oct 2008 17:31:59 +0000

Earlier this year TIBCO released a new version of their particular implementation of the JMS standard. TIBCO Enterprise Message Service 5.0 which, among others, includes some features which I personally consider very interesting.

One of them is the possibility to store persistent messages in a database. In previous versions, the only possibility was to use file based storage. In case you wanted to use fault tolerant groups of servers, this caused some difficulties as having both the messages and the shared state information in files required them to be in a shared storage device, either via hardware (SCSI and SAN, NAS or NAS with NFS) or software (Cluster Server or Clustered File System). These solutions are expensive and hard to maintain while using a database eases the configuration and leaves the hard work on the DBMS. You can even combine file and database based storage depending on the queue or topic.

Database storage is based in Hibernate, so any database server supported by Hibernate could be used to store the data. To use it, first we will need to enable it, setting the following parameters in the tibemsd.conf file:

dbstore_classpath: pointing to the hibernate and DB driver jar files.
dbstore_driver_name: specifies the jdbc driver.
dbstore_driver_dialect: specifies the hibernate driver dialect.
jre_library: associated JVM libraries.

Second, we will have to create the stores in the stores.conf file, for example:

[TSLstore] type=dbstore dbstore_driver_url=jdbc:mysql:thin:localhost:3306:TSLDB dbstore_driver_username=anonymous dbstore_driver_password=anonymous

Third, link the destinations with the appropriate store, either in the topics.conf and queues.conf files or using the command line administration tool with the setprop command, e.g.

setprop topic my.topic store=dbstore

Finally, we will need to export the EMS database tables using the EMS Schema export tool provided with EMS:

java -jar /bin/tibemsd_util.jar -tibemsdconf /tibemsd.conf -createall -export

As a postscript, let me recommend you not to install EMS as root, at least in a Solaris machine. With EMS 5.0 version it will not work unless you change the owner after the installation. This happens because once installed, if we try to run in as root, Solaris, due to security reasons, will execute the process with the user nobody4 but the folder which will contain the datastore files (if we choose file-based storage) will have write permissions set only for root user. As EMS will not be able to create the datastores, it will automatically shutdown. Moreover, even if we change the rights of that folder we will have the same problem with the configuration files, they will only have write permissions for root user which will return errors if we try to change the configuration using the command line administration tool.

Google Developer Day Madrid 2008

Diego Parrilla — Fri, 26 Sep 2008 10:18:23 +0000

Yesterday I went to the Google Developer Day in Madrid. I was lucky because some colleagues filled the request form but they were not accepted by Google. A pity because the event was very interesting.

The event took place in the Parque de Atracciones de Madrid, which is a popular amusement park. Some might think that this kind of place is not very appropriate for a technical event, but I think the main auditorium and the small conference rooms were good enough. I saw some people on the rides in the park but I don’t know if they were people attending to the event or not.

The event started at 10.00AM and began with an introduction by Javier Rodriguez Zapatero, the CEO of Google in Spain. He gave a short introduction about how proud he was to be working in Google (he was a former Yahoo Employee) , how he admires engineers and how hard his team has been working to set up the event. He left the stage to Chris DiBona, a editor of slashdot.org and open source evangelist and guru. Chris promotes several projects in code.google.com and he also manages the Google Summer of Code. Just like all the speakers he gave an excellent speech of why Google supports open source and will support open source more and more in the future. The argument he gave was: “Google has grown to what it is thanks to a vast amount of opensource code, so Google wants to give back to the community part of their success opening the code of projects and offering open platforms”. He also mentioned that the bigger the internet, the better for Google. He also introduced the people from Chrome, Android and AppEngine.

Note: I was surprised that more than 50% of the people did not need a translator from English to Spanish to understand the conferences. And this is really, really good for us Spaniards.

I decided to attend to the AppEngine Workshop in the morning, and ‘Startups mentoring’, ‘App Engine’, ‘Android’, and ‘Future of Webapps’ in the afternoon. The AppEngine Workshop was a three hour workshop called ‘The Hackaton’ where we try to develop something using the AppEngine. I have never developed with Python before, so this Hackaton was like a crash course for me in Python and AppEngine technology. The AppEngine is a development framework for python and a runtime environment that can scale ‘a-la-google’ because it uses what makes Google a scalability beast: Big Table and other technologies. If you are familiar with any MVC framework you will get how to develop the web applications with it (because you can only develop web applications: so forget about running your batch processes here!). The access to Big Table is wrapped with a direct mapping of Python database model classes. It’s possible to create 1:1, 1:N and N:M relationships, and all relationships are bi-directional by default. As Mano Marks told me, forget about ORM, there is no relational database underneath, just plain access to Big Table. As a Java Enterprise architect most of the time I’m tied to one or more relational databases in my projects, so it sounded to me like something risky (explosive growth of objects in ORM is quite normal) but he told me it was not a problem. Well, until I can test it in details this is will be a question of faith in the Google Engineers.

After the workshop came the lunch and then I realized how big the event was: hundreds of hungry developers fighting for french fries and meat like it was the first time they had eaten in days. Probably next year it would be a good idea to schedule several groups for lunch time. BTW, less than 40′ of lunch time in Spain? Imposible! And without an expresso afterwards? No way!

My first event in the afternoon was the ‘Startups Mentoring’ performed by Eduardo Manchón, co-founder of Panoramio. The room was incredibly crowded and I had to stand up at the back of the room. The conference talk was focused on how to make your web site or community to become a successful product. The goal is ‘let people use your site to create a community, don’t try to drive them, they will drive you’. And believe me that Eduardo is one of the most incredible Spaniard speakers I have met in years (the conference was in spanish and english). He said that there is room for ‘micro-companies’ of two or three people that can live thanks to adsense.

Later on I went back to the main auditorium to listen to the AppEngine speech by Mano Marks. The speech focused on the capabilities of the AppEngine and the future. Google will charge a small fee for more processing power, storage and hits therefor allowing successful projects to grow. As I mentioned, AppEngine currently only supports Python and people kept asking Mano which languages would be supported in the future – the Spanish members of the audience were especially interested in Java. He did not say which languages will be supported, but he said that there is a language that it will be not supported: COBOL

The next talk was performed by Mike Jennings and was about Google Android. The first part of the speech was about the architecture of Android. Android is a Linux based platform for smartphones that implements a Java Virtual Machine named Dalvik which allows the execution of vast set of applications in ‘User mode’ on any device. It comes to fix the problem of fragmentation of operating systems and JVM implementations of the mobile market. The platform is opensource and it is given for free to any device manufacturer. The second part of the speech he showed a demo of the SDK (1.0 was released this week). If you are familiar with Java and Eclipse developing for this device looks really easy, specially compared with the nightmare of Java ME development.

And finally in my opinion the jewel of the crown, the best presentation so far: The future of Webapps by Dion Almaer. Dion Almaer is one of the gurus of web development and founder of the site of reference Ajaxian. He said a lot of interesting things, but he emphasized on how interactivity and visual design come hand in hand, and you have to consider both to have a successful project. If you are a developer you should delegate the visual design and interactivity to experts and focus on the technicall stuff. He also talked about the evolution of the browsers and how their improvements will bring a new age to the web after ten years of darkness. He also gave an overview of some of the key JavaScript libraries.

There was a party later on but I could not attend: a pity because everything everybody was in a hurry during all day and looked like the perfect place for networking. Did you go the party?

Developing Custom Hudson Plugins: integrate with your own applications

Diego Parrilla — Wed, 24 Sep 2008 14:32:26 +0000

Hudson is a very good Continuous Integration (CI) tool. Though such tools are not new, it clearly sets a higher standard in terms of quality and extensibility compared to first generation CI tools like Cruise-Control. And it’s open-source. (If you are reading this and you don’t know what Continuous Integration is, read this paper written by Martin Fowler for more information).

One of best features of Hudson is how easy is to extend it. As result there are many plug-ins developed by third parties that can perform a lot of tasks related to the activity of a development team. You can find the list of plug-ins available here. It’s a long list, but it does not mean they will cover everyone’s needs. If there is no plugin that covers your requirements then this blog post for you!

The development of a custom Hudson plug-in is not a daunting task. There are some tutorials out there that can help you to quick-start the development. The best ones are this and this in my humble opinion. You need some background in Maven and Web development to start. Using Maven you will be able to create the basic infrastructure in minutes, and you will be able to start coding and testing the plug-in inside Jetty.

On a recent project, we had to integrate Hudson with a Requirements Management and Bug Fixing application which our customer had developed in-house. The application satisfied their needs and it was out of the scope to change to another like Bugzilla or JIRA, which integrate almost seamlessly with Hudson.

Our customer wanted to change the status of some requirements and bug fixes when a Nightly Build and all the set of automatic unit, integration and acceptance tests were executed successfully. On success, Hudson should execute a stored procedure in the database that the application used, thereby triggering actions like measuring metrics of performance, reporting to quality assurance teams and others.

We didn’t want to reinvent the wheel, so in writing our plugin,we took the approach taken by others tools – when the user commits code to the SCM, they must write comments in a certain format which contain information for the relevant requirement/bug information (bug or requirement ID etc). On a successful build, the Hudson plugin retrieves the relevant information from all code comments and passes it to the requirement/bug system via the stored procedure.

Maven can create for you the default structure of directories and files thanks to the Hudson plug-in (see this). And the plug-in structure created by Maven is:

+ src
    + main
        + java
             +  full.package.name
                    +- MyClassPublisher.java
                    +- PluginImpl.java
                +  full.package.name
                                +- config.jelly
                                +- global.jelly
                +- index.jelly
        + webapp
            +- help-globalConfig.html
            +- help-projectConfig.html
+ src
    + test
        + java
        + resources
        +  full.package.name

We can identify here several key files and classes:

PluginImpl.java

is a class generated automatically by Maven, and it’s the class that registers the action to perform by the plug-in. The default type of action is of the class Builder, but we are more interested in performing an action when the building process is successful: so we use the type Publisher. We need to change the code in the method start to look like this:

    public void start() throws Exception {
        // plugins normally extend Hudson by providing custom implementations
        // of ‘extension points’. In this example, we’ll add one builder.
//        BuildStep.BUILDERS.add(HelloWorldBuilder.DESCRIPTOR);
        Publisher.PUBLISHERS.add(TSLPublisher.DESCRIPTOR);
    }

Do not modify the class, Hudson detects your plug-in (via its @plugin javadoc annotation), creates an instance, and invokes methods.

TSLPublisher.java

is a class that extends the Publisher class and it’s main purpose is to perform an action once the build process has been completed successfully. An example of Publishers are report generation tools or email sending. This class should look like this:

 
public class TSLPublisher extends Publisher {
 
    private static final Logger logger = Logger.getLogger(TSLPublisher.class.getName());
 
    private Boolean enable;
 
    @DataBoundConstructor
    public TSLPublisher(Boolean enable) {
        this.enable = enable;
    }
 
    /**
     * We’ll use this from the config.jelly.
     */
    public Boolean getEnable() {
        return enable;
    }
 
    public boolean needsToRunAfterFinalized() {
        return true;
    }
 
    /**
     * This method should have the logic of the plugin. Access the configuration
     * and execute the the actions.
     */
    public boolean perform(Build build, Launcher launcher, BuildListener listener) {
        logger.info(”Performing update…”);
        // TODO: WRITE THE LOGIC OF YOUR PLUGIN HERE!!!!
        return true;
    }
 
     public Descriptor<publisher> getDescriptor() {
         return DESCRIPTOR;
     }
 
     public Action getProjectAction(AbstractProject< ?, ?> project) {
         return null;
     }
 
     /**
     * Descriptor should be singleton.
     */
    public static final DescriptorImpl DESCRIPTOR = new DescriptorImpl();
 
    /**
     * Descriptor for {@link TSLPublisher}. Used as a singleton.
     * The class is marked as public so that it can be accessed from views.
     *
     * 
     * See global.jelly
     * for the actual HTML fragment for the configuration screen.
     */
    public static final class DescriptorImpl extends Descriptor<publisher> {
        /**
         * To persist global configuration information,
         * simply store it in a field and call save().
         *
         * 

         * If you don’t want fields to be persisted, use transient.
         */
        private String field;
 
        protected DescriptorImpl() {
            super(TSLPublisher.class);
            load();
        }
 
        /**
         * This human readable name is used in the configuration screen.
         */
        public String getDisplayName() {
            return “This is the TSL Sample Plugin”;
        }
 
        /**
         * Get the fields from the configuration form and persist them.
         */
        public boolean configure(HttpServletRequest req) throws FormException {
            uri = req.getParameter(”tsl.field”);
            save();
            logger.fine(”Saved TSL configuration”);
            return super.configure(req);
        }
 
        /**
         * Creates a new instance of {@link TSLPublisher} from a submitted form.
         */
        public TSLPublisher newInstance(StaplerRequest req) throws FormException {
            logger.fine(”New instance for a job”);
            return new TSLPublisher(req.getParameter(”tsl.enable”)!=null);
        }
 
        public String getField() {
            return field;
        }
 
        public void setField(String field) {
            this.field = field;
        }
    }    
}
p>publisher>p>publisher>

All the information I have found about plug-ins explains how to write a Builder. Publisher is similar. You have to modify:

The perform method do the real thing. To get the configuration parameters, use the DESCRIPTOR singleton to access the POJOs.
The inner class DescriptorImpl extends Descritor
. It is instantiated once and accessed by a Singleton.
- The configure() method reads the parameters and persists them.
- The newInstance() should return an instance of the TSLPublisher to perform the action. I have implemented an enable check. When not enabled, there is no instance for this job.
- All the fields can persist by default. Use transient if you don’t want to persist.

global.jelly

is a file generated automatically by Maven, and it’s the Jelly Script file to produce the global configuration option. It’s automatically added to the configuration pages of Hudson after deployment. It uses Jelly as scripting language (I think this is a bizarre decision, but it’s not important), you can find information about Jelly here. In our example the file looks like this:

 :jelly xmlns:j="jelly:core" xmlns:st="jelly:stapler" xmlns:d="jelly:define" 
         xmlns:l="/lib/layout" xmlns:t="/lib/hudson" xmlns:f="/lib/form">
    :section title="TSL Integration">
      > :entry title="Field Test" help="${rootURL}/plugin/tsl/help-globalConfig.html" >
          :textbox name="tsl.field" value="${descriptor.field}" />
      >
 
>

The values in the form are stored in the ${descriptor.fieldname}, and the parameters can be referred with a unique name like ‘tsl.field’. It’s also possible to link help files as described in the example. Be sure that you are using the variable ‘descriptor’ to access the information.

config.jelly

is a file generated automatically by Maven, and it’s the Jelly Script file to produce the configuration option specific for the job. In our example the file looks like this:

 :jelly xmlns:j="jelly:core" xmlns:st="jelly:stapler" xmlns:d="jelly:define" 
         xmlns:l="/lib/layout" xmlns:t="/lib/hudson" xmlns:f="/lib/form">
	 :entry  description="Check to enable this publisher for the job">
		 :checkbox name="tsl.enable" checked="${instance.enable}" />
	>
>

The values in the form are stored in the ${instance.fieldname}, and the parameters can be referred with a unique name like ‘tsl.enabled’. It’s also possible to link help files as described in the example of global.jelly. Be sure that you are using the variable ‘instance’ to access the information.

And that’s all you need to develop a Publisher Hudson Plug-in. You can test it following the instructions in the Hudson wiki.

Automated integration testing with Selenium, Maven and Jetty

Kevin McCormack — Wed, 17 Sep 2008 08:22:18 +0000

Here at The Server Labs we place a high value on automated unit and integration tests and believe that they are fundamental whether you are using an agile methodology or not.

We use Maven on the vast majority of our projects and we often use Jetty as a web container in plain Java web projects (i.e. those that don’t require a full JEE container). Often the deployment environment is not Jetty (it might be Oracle AS or WebLogic for example) but Jetty is so well integrated with Maven that the costs of not developing on the deployment platform are outweighed by the ease-of-development benefits.

Selenium is a common choice for writing integration tests for web application - and one that we have used on various projects in the past. The idea is that you interact with your web application using Firefox and the Selenium IDE plugin records the test. You can then replay this test as part of the ‘integration-test’ Maven phase for your application, hence building up a suite of integration tests to run.

Putting all of this together, we’d like to share with you the Maven configurations and Java code that we use to accomplish automated one-step Selenium integration testing for a web application running in Jetty using Maven.

For the purposes of this post, we will refer to a Spring-MVC Java web application that keeps track of cars. It has the ability to add/delete/edit/list cars. To keep things simple, it does not use a database but keeps a list of cars in memory. The full code for the application can be downloaded from here.

Pre-requisites: Maven installed, some understanding of Selenium is helpful.

Run the web application

Download the source code (available here) and unzip it to a folder on your filesystem. Open a console and navigate to the folder with the code in it and execute the following:

mvn jetty:run

In your browser, go to the application homepage: http://localhost:9080/integration-testing-post and you should see the following:

Integration Testing Cars Application homepage

Once you’ve navigated around the application, stop it by pressing ctrl-C in the console.

Open the application in Eclipse

Navigate to the directory to which you downloaded the source code in the console. Run the following to Generate the Eclipse project descriptors:

mvn eclipse:eclipse

Then, open Eclipse and run File > Import and choose Existing Projects Into Workspace. Hit ‘next’ and then browse for the directory into which you downloaded the code. Click ok and then Eclipse should find your new project. Double-click on it to import it. You may have to add the M2_REPO classpath variable to your workspace if you’ve not already done so. See here for more info.

Create the Selenium Integration Test

The integration tests are in the /src/test/java/com/tsl/example/cars/integration/ folder of the project. SeleniumIntegrationTest is the base class for all Selenium tests. It starts up a Selenium client in the setup() method and stops it in the tearDown() method.

package com.tsl.example.cars.integration;
 
import junit.framework.TestCase;
 
import org.openqa.selenium.server.SeleniumServer;
 
import com.thoughtworks.selenium.DefaultSelenium;
import com.thoughtworks.selenium.Selenium;
 
public abstract class SeleniumTestCase extends TestCase {
 
	protected Selenium selenium;
 
	@Override
	protected void setUp() throws Exception {
		super.setUp();
        selenium = new DefaultSelenium(
        		"localhost", 
        		SeleniumServer.getDefaultPort(), 
        		"*iehta", 
        		"http://localhost:9080");
        selenium.start();
	}
 
    @Override
    protected void tearDown() throws Exception {
    	selenium.stop();
    	super.tearDown();
    }
}

For more information on the parameters passed in the constructor of DefaultSelenium, see the Selenium client documentation. The most important is that which specifies the browser that Selenium should use to run the tests. In this case, it is set to "*iehta" which means Internet Explorer. To change to Firefox, use "*firefox".

CarIntegrationTest is a Selenium Integration Test. It extends SeleniumTestCase. The source code is below:

package com.tsl.example.cars.integration;
 
public class CarIntegrationTest extends SeleniumTestCase {
 
	public void testAddCar() throws Exception {
		selenium.open("/integration-testing-post/cars/list.html");
		selenium.click("link=Add Car");
		selenium.waitForPageToLoad("30000");
		selenium.type("make", "Mercedes");
		selenium.type("model", "SLK");
		selenium.click("btnSave");
		selenium.waitForPageToLoad("30000");
		assertTrue(selenium.isTextPresent("Mercedes"));
		assertTrue(selenium.isTextPresent("SLK"));
	}	
}

The testAddCar() method tests that we can add a car (a Mercedes SLK) using the web application. It assumes that you start at the start page of the application, click on the ‘add car’ link, enter the make and model and click save. It waits up to 30secs for the application to save the car and tests that on the resulting page (which is the list of cars), the words ‘Mercedes’ and ‘SLK’ appear. This allows us to assume that the car was correctly added.

The content of this test method was generated using the Selenium IDE plugin for Firefox:

Selenium IDE plugin in Firefox

I’m not going to go into detail here on how to use the Selenium IDE but basically it acts like a Macro recorder - recording your steps as you manually perform the integration test in your browser and then allowing you to play it back. I prefer standard Java syntax for the test instead of the ‘Selenese’ default. You can export Java code from a new test case by choosing File > Export Test Case As > Java - Selenium RC. I tend to create a new class manually in Eclipse for the test and then copy over just the testXXX methods from the Java source code that I exported from Selenium IDE.

Running the integration tests in Jetty using Maven

Once we have created an integration test we want to run it using Maven. There are a few things we want to happen before the integration test runs though:

Start up the web application running in Jetty
Start up the Selenium Server

We accomplish this using the following section in the Maven POM file (in the root folder of the downloaded code):

   >
      >
         >
            >org.mortbay.jetty>
            >maven-jetty-plugin>
            >
               >5>
               >9966>
               >foo>
               >
                   implementation="org.mortbay.jetty.nio.SelectChannelConnector">
                     >9080>
                     >60000>
                  >
               >
            >
            >
               >
                  >start-jetty>
                  >pre-integration-test>
                  >
                     >run>
                  >
                  >
                     >true>
                  >
               >
               >
                  >stop-jetty>
                  >post-integration-test>
                  >
                     >stop>
                  >
               >
            >
         >
         >
            >org.apache.maven.plugins>
            >maven-compiler-plugin>
            >
               >1.5>
               >1.5>
               >UTF-8>
            >
         >
         >
            >org.codehaus.mojo>
            >selenium-maven-plugin>
            >1.0-beta-3>
            >
               >
                  >start>
                  >pre-integration-test>
                  >
                     >start-server>
                  >
                  >
                     >true>
                     >true>
                     >true>
                  >
               >
               >
                  >stop>
                  >post-integration-test>
                  >
                     >stop-server>
                  >
               >
            >
         >
         >
            >org.apache.maven.plugins>
            >maven-surefire-plugin>
            >
               >
                  >**/integration/*Test.java
                  >
               >
            >
            >
               >
                  >integration-tests>
                  >integration-test>
                  >
                     >test>
                  >
                  >
                     >false>
                     >
                        >none>
                     >
                     >
                        >**/integration/*Test.java
                        >
                     >
                  >
               >
            >
         >
      >
   >

I’m among the first to acknowledge the benefits of Maven, but at times the XML syntax required to configure it can be a bit scary! Here’s the basic explanation of all this:

The Jetty plugin is configured to run Jetty on port 9080 - I prefer to avoid potential conflicts with other applications running on 8080 which is quite commonly used.
In the pre-integration-test Maven phase (executed before the integration tests are run), the run goal of the Maven Jetty plugin is executed. The configuration element allows us to specify that that this is a daemon process
In the post-integration-test phase, we run the stop goal of the Maven Jetty plugin to shut down Jetty.
In the pre-integration-test phase we run the start-server goal of the Maven Selenium Plugin
In the post-integration-test phase, we run the stop-server goal of the Maven Selenium plugin to shut down the Selenium server
The Maven Surefire plugin is configured to not execute the integration tests as part of the normal test phase but instead in the integration-test phase.

Executing the Integration tests

Although the Maven configuration looks verbose and complicated, it gives great results. Just executing the single command below in the console causes the integration tests to run without interference:

mvn integration-test

What about Cargo?

When I was developing this code, I noticed that many people seemed to use the Maven Cargo plugin to start up the relevant application server. I had very mixed results using this with different application servers and it didn’t seem to work at all with Jetty - lots of Classpath problems if I remember rightly. In the end, the plain old Maven Jetty plugin did the job just fine.