WS tools 1.2.2 Beta1 What's New

< Main Index JST Tools >


JAX-RS Tooling


Support for @ApplicationPath and web.xml override

Support for javax.ws.rs.core.Application subclass annotated with @ApplicationPath is now available, along with support for standard JEE6 override in the web app deployment descriptor. The JAX-RS Tooling will include the @ApplicationPath annotation value in your endpoints' URI Path Template if you provide a JAX-RS Application class as below:

      @ApplicationPath("/mypath")
      public class MyApplication extends Application {
        ...
      }
      

Or if you define the application's root path for the JAX-RS endpoint in the web application's web.xml in the one of the following manners:

      <servlet-mapping>
        <servlet-name>com.acme.MyApplication</servlet-name>
        <url-pattern>/hello/*</url-pattern>
      </servlet-mapping>
      

or

      <servlet-mapping>
        <servlet-name>javax.ws.rs.core.Application</servlet-name>
        <url-pattern>/hello/*</url-pattern>
      </servlet-mapping>
      

As defined in the JAX-RS 1.1 specification, the web.xml approach takes precedence over the annotation-based configuration.

Related Jira


Web Service Tester


Better Tooling Integration - JAX-RS

We recently had an opportunity to add some better shortcuts to get to the Web Service Tester from common access points in the UI.

Most importantly to go with our AS7 support, we now have right-click integration with the JAX-RS tooling for RESTful services. Now you can right-click on one of the exposed REST methods implemented by the service and select Run As...->Run on Server.

This does a few things:

  1. If the server is not running it will get started.
  2. If the application is not deployed to the server it will be deployed
  3. If the Web Service Tester isn't open, it will open it in the current perspective.
  4. And it automatically sets the URL for the RESTful operation as well as the method drop-down to match. For instance, if you are testing a GET method, it will set the drop-down to GET. A PUT to a PUT, etc. So all you have to do is click the Invoke button on the toolbar (the little green play button) to execute the operation.

A couple of caveats:

  • If you need to specify a request header (for instance, setting the request to use an XML content type - "content-type=application/xml"), it doesn't know to do this automatically.
  • The JAX-RS tooling doesn't know how to interpret some configuration options, such as Servlet Mapping Prefixes, but this support is coming soon.

Related Jira


Partial WSDL file integration

In addition, you can now right-click on a WSDL and select Web Services -> Test in JBoss Web Service Tester. This action does two things:

  1. If the Web Service Tester isn't open, it will open the view in the current perspective.
  2. And it automatically sets the URL for the WSDL file as well as the method drop-down to "JAX-WS". So all you have to do is click the Invoke button on the toolbar (the little green play button) to specify which port/operation combination you want to test with.

Unfortunately you can't quite run it in this state yet. It's a work in progress. I suspect we will implement a solution similar to the JAX-RS tooling integration where you specify the server on which to run the service and we'll figure out the URL dynamically.

You'll still need to look at your deployed services in the web console to determine the url to the service you want to test, then add "?WSDL" to the end so the tester can find the WSDL file in the running service. But it works the same as the WTP-provided Web Services Explorer.

Related Jira


Better Test History Tracking

Whereas before we would only remember the URLs for the services tested in the current session, we now remember much more for each successful test:

  • The Method (JAX-WS or JAX-RS method name)
  • Any Request Headers
  • The Request Body
  • Plus the Response Headers and Response Body for the most recent test run.

So now you can step back and forth through recent tests much easier. If you change something from a previous test run, that change is persisted so the next time you come back to that URL, you see your most recent settings.

Related Jira