Skip navigation

Now that the WS Tester is getting more stable and feature complete, I wanted to try it against a RESTeasy web service (JAX-RS) deployed against one of our own runtimes. I simply used the steps we'd defined earlier for using the RESTeasy project example on this wiki page.


To do this yourself, follow these steps:

  1. Grab a recent build of JBoss Tools 3.2 (go [ and use the latest trunk build). Install it into an Eclipse 3.6 (Helios) instance.

  2. Make sure you have an EAP 5 or SOA-P 5 runtime ready with RESTeasy installed.

  3. Fire up your Eclipse workbench and follow the steps here to get your RESTful web service project into your workbench (steps 1 through 10).

  4. Get a bit familiar with the WS Tester by checking out this post and this post.

  5. Open the WS Tester view by selecting Window->Show View->Other... Drill down until you find "JBoss Tools Web Services" and select the Web Service Tester.

  6. To post a new customer to the service database:

    • Select JAX-RS as your Web Service Type.

    • Switch the HTTP Method to "POST".

    • Type in your Service URL: http://localhost:8080/simple/rest-services/customers.

    • Put in your sample XML in the Request Body tab:

      <street>256 Red Hat Lane</street>
    • On the Request Header tab, add "content-type=application/xml" as the lone header.

    • Click the Invoke button.

    • You won't see anything in the Response Body tab to the right, but if you go to the Response Header, you should see "[HTTP/1.1 201 Created]" as the top line in the list. You should also see the Location (http://localhost:8080/simple/rest-services/customers/# where # is the record number for the entry).

  7. To retrieve a record from the service:     

    • Change the HTTP Method to "GET".

    • Change the Service URL to the Location value you saw in step 6 (http://localhost:8080/simple/rest-services/customers/1)

    • Click the Invoke button.

    • This time you should see the XML record in the Response Body tab and [HTTP/1.1 200 OK] as the first Response Header.

  8. To update a record from the service:

    • Change the HTTP Method to "PUT".

    • Leave the URL the same (for the record you want to update).

    • Provide the updated XML for the record:

      <street>123 Red Hat Court</street>
    • Click the Invoke button.

    • Like when you POSTed before, you won't see anything in the Response Body, but you should see [HTTP/1.1 204 No Content] as the first item in the Response Header list.

    • To verify that the data went through correctly, we can do another GET - simply switch the HTTP Method to "GET" and click Invoke again.

    • Now we should see the updated data appear in the Response Body and [HTTP/1.1 200 OK] as the first item in the Response Header list.

And that's it! Pretty easy. Didn't even have to leave Eclipse to test!

[Note: This blog has been replaced by a more up to date How to Build JBoss Tools 3.2 with Maven 3.]


Current trunk version of JBoss Tools can be built with maven 3 and make it faster and easier for everyone.


  1. Java 1.6 SDK
  2. Maven 3.beta1
  3. About 6 GB of free disk space if you want to run all integration tests for (JBoss AS, Seam and Web Services Tools)
  4. subversion client 1.6.X (should work with lower version as well)

Environment Setup

Maven and Java

Make sure your maven 3 is available by default and Java 1.6 is used.


mvn -version


should print out something like


Apache Maven 3.0-alpha-7 (r921173; 2010-03-09 14:31:07-0800)
Java version: 1.6.0_18
Java home: /usr/lib/jvm/java-6-openjdk/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux" version: "2.6.32-22-generic-pae" arch: "i386" Family: "unix"


Checkout sources from anonymous SVN like


svn co jbosstools-src


This will take some time dependent on your bandwidth

Build Strategies

All commands below is assuming that commands are executed in jbosstools-src folder after sources checked out as it suggested above.

There are several strategies to chose from building everything to build particular component or part of it like all plug-ins, all tests, all features, particular plugin/feature.


Target platform should be built first like


$mvn -f build/target-platform/pom.xml


If you want to just compile the modules, tests can be skipped by adding system property -Dmaven.test.skip=true and you should be able to faster verify compile issues.

Build/Test Everything

Current version cannot be build without local changes because of problem with with drools component, so to go with this scenario you need to remove drools references from pom.xml and site/site.xml. After that to build/test everything use:


$mvn clean install

Build/Test Particular Component with Dependencies

For convenience there are aggregator projects defined for each component. It provides a simple way to build/test components with dependencies.


$mvn clean install -f build/component/${}.xml


where ${} is component you want to build/test. Currently build/component folder contains aggregator projects for:

  1. tests,
  2. jmx,
  3. archives,
  4. as,
  5. common,
  6. seam


more is coming soon.

Build/Test Single Component

Be aware that to get this work all dependencies for this component must be installed in maven repo. It can be done by build everything first or by build component and its dependencies using aggregated project as it explained above. You can skip tests for this build and then enable them back when you run single component build.

To build single component use pom.xml in component's folder like it is shown below.


$mvn clean install -f ${}/pom.xml


where ${} is component's root folder name. For instance to build jmx component use command below


$mvn clean install -f jmx/pom.xml

JBoss Tools 3.1.1 with about 100  fixes is now available from the update site and downloads.

Beyond the fixes in JBoss Tools it is also recommended to install the latest patches to Eclipse WTP from their update site. This fixes issues with Classpath libraries that affected those who are using Maven.


Hi again...


I've been working on the JBoss Tools Web Service Tester and have just recently added the ability to select a WSDL file to populate the endpoint/action URLs and generate a Sample SOAP message when testing JAX-WS services. I'm still working on figuring out how to connect to a UDDI v3 registry to browse and select an operation from a published service in that context, but in the meantime you have a way to test your WSDL-based web services a bit easier...


Before I provide an example, I want to bring up a great resource for publicly-accessible web services from around the world - If you haven't checked it out, it provides some great services that you can use to test tools like the WS Tester. A few that I found that are very useful for testing are:


So let's start with the Google Search Results one, which has a WSDL at


If we look at the WS Tester, it has a new button - "Get from WSDL..."...


So I click on the "Get from WSDL..." button and see the "Select WSDL" dialog:


In the "WSDL URI:" field, I paste my WSDL URL in and it populates the three fields - Service, Port, and Operation. If there is more than one SOAP port available (such as SOAP and SOAP12), you can select it in the list and the operation list will change accordingly. In this case, there's just one operation available, but you have a vertical scroll bar on the right of the list to pick and choose.


When I hit OK, it does a number of things with the WSDL. It searches through the WSDL for the endpoint and action URLs, but more importantly it will try and generate a valid sample of the SOAP Request message. Even if the WSDL has multiple imports and/or imports schemas, it should (knock on wood) generate even complex messages fairly well. (If it doesn't, please let me know by putting in a JIRA.)


So in this case, it comes back populating the WS Tester with these values:


If I change the values a bit...

  • searchPage becomes an empty value (delete the "?")
  • gQuery becomes "JBoss Web Services"
  • numOfResults becomes an empty value (delete the "?")


And hit Invoke...


If I copy the response into an XML file and clean it up a bit, it looks pretty good:


So if you look at a web service with multiple operations like the CDYNE Weather service (WSDL at, you have more options in the operation list:


And I was able to get the forecast for my city:


So if you have a WSDL file or a URL to a WSDL file, you should be able to use the WS Tester to test it now.


Next step is to get some sort of facility into the mix so you can browse a UDDI repository for the service.


This is checked into the JBoss Tools trunk now, so you should be able to play with it. Let me know what you think!