WebSphere Configuration

  1. Feature Pack for Web 2.0 installed into WebSphere. This simply copies a bunch of files, including the JAX-RS jar files, into $WAS_HOME/web2fep. The IBM JAX-RS implementation is based on Apache Wink, version 1.0 as of this writing.
  2. Created Shared Library in WAS. Applications can reference this rather than having to deploy the jars each time.

Web Application Configuration

  1. Add WebSphere REST Servlet to application’s web.xml
        <servlet-name>JAX-RS Servlet</servlet-name>  
        <servlet-name>JAX-RS Servlet</servlet-name>  

    Note that the <init-param> text is only required, including creating a custom class which extends Application, if we don’t use the following Spring Wink support.

  2. Integrate Wink with Spring using a Spring-aware Wink Application subclass called Registrar. This class is not part of the WebSphere Feature Pack but works fine with it. This allows you to inject your “Resource” definitions rather than hardcode them in an Application subclass.

    Perhaps more importantly, it also allows you to more easily utilize the injected interface/implementation pattern for the rest of your supporting beans.


    This class and its supporting classes are part of an “extensions” jar (wink-spring-support-1.0-incubating.jar) provided in the Wink distribution file available from the Wink site.

    Where META-INF/server/wink-core-context.xml is provided by the Wink Spring library and applicationContext.xml is your application’s bean definitions.

  3. Configure your Resource classes in your application Spring configuration file.
    <bean class="org.apache.wink.spring.Registrar">  
        <property name="instances">  
                <ref bean="calendarResource" />  
    <bean id="calendarResource"  
        <property .../>  

Resource Implementation

This is the basic annotation-based JAX-RS coding. See the below “Getting Started” article, Part 1 of the “RESTful Web services” article, and the Developing JAX-RS Web applications section of the WebSphere Feature Pack documentation.

It’s a straightforward, portable way to define the URI Paths of your Resources, the HTTP Methods supported by them, the Parameters passed to them, the Content Types supplied by them, and more.