Page History

...

public BookExceptionMapper implements ExceptionMapper<BookException> {
    public Response toResponse(BookException ex) {
        // convert to Response
    }
}

This allows to throw exceptions a checked or runtime exception from an application code and deal with the proper mapping map it to an HTTP response in a registered provider.

...

    public Response updateCustomer(@DefaultValue("123") @QueryParam("id") Long id, @PathParam("name") String name) {
        ...
    }
}

Currently this annotation is only noticed if it targets a parameter, and at the moment it can not be applied to method parameters annotated with @PathParam.

There's also a CXF extension which makes it possible to inject a sequence of Path or Query parameters into a bean. For ex :

...

Note that there's a single @PathParam with an empty value - this is an extension bit. The value for a template variable 'id' is
injected into Customer.setId(Long id), while the value for 'name' is injected into Customer.setName(String s). The setter methods should have a single parameter, the conversion from the actual value to the parameter instance follows the same procedure as outlined above.

Starting from JAX-RS 0.8, it's also possible to inject all types of parameters into fields or through dedicated setters. For ex, the frist first code fragment in this section can be rewritten like this :

...

Similarly, annotations can be inherited from super-classes.
The resource class can also inherit the class-level annotations from either one of its implemented interfaces or its superclass.

...

@Path("/customerservice/")
public class CustomerService {

    @Path("/orders/{orderId}/")
    public Order getOrder(@PathParam("orderId") String orderId) {
       ......
    }
}

public interface Order {
    @GET
    @Path("products/{productId}/")
    Product getProduct(@PathParam("productId")int productId);
}

@XmlRootElement(name = "Order")
public class OrderImpl implements Order {
    
    @GET
    @Path("products/{productId}/")
    public Product getProduct(@PathParam("productId")int productId) {
       ......
    }
}

...

Alternatively to using @XmlRootElement and Collection wrappers, one can provide an Object factory which will tell JAXB how to
marshal a given type (in case of Collections - its template type). Another option is to return/accept a JAXBElement directly from/in
a given method.

Another option is to register one or more JAX-RS ContextResolver providers capable of creating JAXBContexts for a number of different types. The default JAXBElementProvider will check these resolvers first before attempting to create a JAXBContext on its own.

Finally, JAXBProvider provides an experimental support for marshalling response types of methods annotated with @XmlJavaTypeAdapter annotations.
It's likely that at some point of time JAX-RS runtime will be capable of automatically generating such adapters.

...

Complete the implementation of JAX-RS UriInfo (latest methods to do with the ancestor resources) and in particularly of UriBuilder
Complete the implementation of JAX-RS Request (If-Modified-Since, Vary) and ResponseBuilder(Vary)
Support Constructor-based injection
Support javax.activation.DataSource out of the box
ASM-generate XmlJavaTypeAdapters when needed
Provide AegisBindingProvider
Provide JAXP-Source provider capable of applying preconfigured XSLT templates or XPath expressions
Proper HTTP status handling in various cases as per the spec
Support of @Encoded on a method (class and parameter targets supported)
Support of encoded @Path values
Support for inheritance of @PathParam and @Context annotations from interface/superclass methods
Create some useful request filter implementations : JavaScript code generation, WADL or JavaDocs generation
Investigate the possibility of creating a client-side api using JAXRSClientFactory