This section 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 are 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 cases, 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 overwrite default JAX-RS provider(s):
Deploy your own RESTful service(s) by using the subclass of javax.ws.rs.core.Application (hereinafter Application).
Your service does NOT NEED to implement the marker interface ResourceContainer and MUST NOT be configured as component of eXo Container. Instead, Application must be configured as component of eXo Container.
If RESTful services or providers require some dependencies from eXo Container, Application should inject it by own constructor and then delegate to services or providers. As an alternative method, getClasses() may be used for delivering services/providers classes instead of instances. In this case, services/providers will work in the per-request mode and RESTful framework will take care about resolving dependencies.
The following example shows how to use the Jackson JSON provider instead of embedding in the eXo RESTful framework.
Create the 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, it is assumed that Resource1 is Java class that carries JAX-RS annotations and uses JSON. In this case, the RESTful framework will use JacksonJaxbJsonProvider for serializing/deserializing all messages to/from Resource1. But it will not impact other services.