JAX-RS implementations in WebSphere Application Server

Jersey is the open source JAX-RS (JSR 311) Reference Implementation for building RESTful Web services. Jersey provides an API so that developers may extend Jersey to suit their needs. See blog post on how to integrate Jersey with WebSphere Application Server 6.1. If the first suggestion does not work look at this post.

Gotcha To get Jersey working with WAS v7 you will need to set the webcontainer custom property.
Name: com.ibm.ws.webcontainer.invokeFiltersCompatibility
Value: true
This workaround is NOT needed in WAS v8. See APAR PK56247   for details on why you need to do this in WAS v7.

If your application that leverages Jersey  throws the following error during deployment

The URI scheme wsjar of the URI wsjar:file:/C:/rad802/workspace/myCompany/TestJerseyProvider/WebContent/WEB-INF/lib/Providers.jar!/com/mycompany/commons/web/rest/providers is not supported. Package scanning deployment is not supported for such URIs.

This occurs because your classes in web-inf/lib are not being recognized, because the Jersey URI Scheme scanner which scans WEB-INF/lib only works, when the protocol has 3 digits (like jar:) but WebSphere uses wsjar: as protocol.

We ran into a similar issue when using Open Web Beans see https://issues.apache.org/jira/browse/OWB-577
You can also look at the svn change history to see how we fixed it in Open Web Beans.

This is fixable in Jersey by adding your own com.sun.jersey.core.spi.scanning.uri.UriSchemeScanner  which is the interface for scanning URI-based resources and reporting those resources to a scanning listener. Jersey's code add's additional UriSchemeScanner's using the com.sun.jersey.spi.service.ServiceFinder. Looking at existing scanners like the the com.sun.jersey.core.spi.scanning.uri.JarZipSchemeScanner & com.sun.jersey.core.spi.scanning.uri.FileSchemeScanner you will be able to write a scanner that is able to scan the jars in the WEB-INF/lib directory of your WAS application.

Another option is to do what the warning says  Try using a different deployment mechanism such as explicitly declaring root resource and provider classes using an extension of javax.ws.rs.core.Application.

Please note that WAS ships with its own JAX-RS implementation based off the Apache Wink Project. This is available by default in WAS version 8 and with the Web 2.0 feature pack in WAS v7.