This chapter will show you how to overwrite the default providers in eXo JAX-RS implementation.
There is set of providers embedded in eXo JAX-RS implementation.
Implementations of MessageBodyReader and MessageBodyWriters are taking care about serialization/deserialization of message body (HTTP request/response's body).
The next set of media and Java types processed automatically, thanks to embedded Readers (Writers).
| Media Type | Java Type |
|---|---|
| */* | byte[] |
| */* | javax.activation.DataSource |
| */* | java.io.File |
| */* | java.io.InputStream |
| */* | java.io.Reader |
| */* | java.lang.String |
| */* | javax.ws.rs.core.StreamingOutput (Writer ONLY) |
| application/json | 1. Object with simple constructor + get/set methods; 2. Java Collection (java.uitl.List<T>, java.uitl.Set<T>, java.util.Map<String, T>, etc) where T as described in 1. |
| application/x-www-form-urlencoded | javax.ws.rs.core.MultivaluedMap<String, String> |
| multipart/* | java.util.Iterator<org.apache.commons.fileupload.FileItem> |
| application/xml, application/xhtml+xml, text/xml | javax.xml.bind.JAXBElement |
| application/xml, application/xhtml+xml, text/xml | Object with JAXB annotations |
| application/xml, application/xhtml+xml, text/xml | javax.xml.transform.stream.StreamSource |
| application/xml, application/xhtml+xml, text/xml | javax.xml.transform.sax.SAXSource |
| application/xml, application/xhtml+xml, text/xml | javax.xml.transform.dom.DOMSource |
In some case it may be required to use alternative provider for the same media and java type but such changes must not impact to any other services.
To be able overwrite default JAX-RS provider(s) developer need:
Deploy own RESTful service(s) by using subclass of javax.ws.rs.core.Application (hereinafter Application).
Service(s) NOT NEED to implement marker interface ResourceContainer and MUST NOT be configured as component(s) of eXo Container. Instead of it Application must be configured as component of eXo Container.
If RESTful services or providers require some dependencies from eXo Container then Application should inject it by own constructor and then delegate to services or providers. As alternative method getClasses() may be used for deliver services/providers classes instead of instances. In this case services/providers will work in per-request mode and RESTful framework will take care about resolving dependencies.
In example below see how to use Jackson JSON provider instead of embedded in eXo RESTful framework.
Create subclass of javax.ws.rs.core.Application with code as bellow and add it to the eXo Container configuration.
package org.exoplatform.test.jackson;
import org.codehaus.jackson.jaxrs.JacksonJaxbJsonProvider;
import java.util.HashSet;
import java.util.Set;
import javax.ws.rs.core.Application;
public class Application1 extends Application
{
@Override
public Set<Class<?>> getClasses()
{
Set<Class<?>> cls = new HashSet<Class<?>>(1);
cls.add(Resource1.class);
return cls;
}
@Override
public Set<Object> getSingletons()
{
Set<Object> objs = new HashSet<Object>(1);
objs.add(new JacksonJaxbJsonProvider());
return objs;
}
}
In this example we assumes Resource1 is Java class which carries JAX-RS annotations and it uses JSON. In this case RESTful framework will use JacksonJaxbJsonProvider for serializing/deserializing of all messages to/from Resource1. But it will not impact to other services in any kind.