The Promise of CompletableFuture? JAX-RS2 example!

CompletableFuture API introduced in Java 8 is different from previous Future in the way it is composable and usable as a promise. Let’s see how to integrate it with JAX-RS 2.

JAX-RS 2: ensure your server providers are not used on client side!

Since JAX-RS 1 and moreover with JAX-RS 2 developpers create JAX-RS providers.

The most common ones are to (de)serialize the request/response payloads but you can do much more now like switching the input stream, updating the output stream, filtering the request/response etc…

Going further in this API you’ll realize you can filter input/output on server side and client side (for instance you can write a ClientRequestFilter and a ContainerRequestFilter). Generally client and server API are close but adapted to the “side” where the provider is working.

However can we ensure we didn’t mess things configuring a client provider on a server?

TomEE and JAXRS provider configuration depending on environment

TomEE supports “environment integration” through several solutions (altdd support, external configuration using conf/system.properties etc….). But how to configure a JAXRS provider depending the environment?

First why should I need it? Suppose you configured a JSON provider, quite common for a JAX-RS application no? You want your application to be efficient in production so you use “flat” JSON but in dev you surely prefer to get formatted (“pretty”) JSON to keep it readable.

How to do it with TomEE?

TomEE, CDI and JAX-RS @Providers

TomEE trunk is now using CXF 3 as JAX-RS provider.

Providers were generally configured using openejb-jar.xml or just auto discovery (when using good defaults) but now in TomEE 2.x CDI and JAX-RS providers are linked.

It means you can @Inject inside your provider if the provider type is a CDI bean with @Default qualifier.

Build a MVC solution based on JAXRS is quite trivial!

Few days ago a user went on #deltaspike IRC channel (on freenode) and asked if there was a replacement for seam rest. There is no one ATM (a bit too early) but this post will show you how simple it is to build a MVC framework based on any template engine you want (velocity for me) and JAXRS.

JAXRS 1 and unmarshalling of response.getEntity()

JAXRS 2 provides a simple way to unmarshal using JAXRS providers a Response entity (got from response#getEntity() method): readEntity(…).

However if you still have to stick to JAXRS 1 you’ll often get an InputStream as entity…not that fun.

The worse is when you use an interface with the JAXRS metadatas to generate a client. To avoid to need to play with stream there is a simple solution.

Camel and JavaEE REST/SOAP server services

Camel is a great library and a common use case can be to expose as a REST (or SOAP) web service an integration route.

The main advantages are:

• it is easy to write a client, whatever the technology you use
• camel can be used as a backend without needing any special environment stuff (compared to JMS, file polling…)

In embedded or spring case it is quite easy to do so:

• import camel-cxf
• define the server (either in spring then link it to camel or directly through camel)
• define you route using cxfrs endpoint

See Camel CxfRs for more details.

The main drawback are:

• you need to setup the rest endpoint where it is done by the container in a JavaEE container like TomEE for instance
• you need to use cxf (you can use Jersey or whatever)

Another drawback we can see is you can’t always stick to last versions of camel because it always uses the last version of cxf which can’t be included in JavaEE 6 servers because of the JAXRS (n+1) API changes – JAXRS 2.0 ATM – (otherwise the container is not certificated which makes it pretty useless).

Last point: it is trivial to bridge any part of an application (like a webservice) to camel.

This last statement is true thanks to camel proxy features.

Let’s work with a sample! It will be a CDI application with a rest service as input forwarding the input pojo to a camel route.

Note: of course it will use camel-cdi to be able to get injected CamelContext, endpoints…

To make it even more easy we will create an interface mapping our route contract. In our sample the input (of the rest service) is of type Input and the output of the route (which can be different from the rest service) is an int. So basically here is the interface we need:

public interface CamelDelegate {
    int foo(Input request);
}

Suppose now we have the following route:

from("direct:input")
    .routeId("cdi-route")
    .convertBodyTo(Input.class)
    .choice()
        .when(simple("${body.criteria} == 'A'"))
            .setBody(constant(1))
        .when(simple("${body.criteria} == 'B'"))
            .setBody(constant(10))
        .otherwise()
            .setBody(constant(-1));

We simply need to create a proxy on “direct:input” endpoint. It is done in one line thanks to camel API:

final CamelDelegate camelDelegate = new ProxyBuilder(getCamelContext()).endpoint("direct:input").build(CamelDelegate.class);

So finally the idea is to do it in the REST service. Since we are in CDI we can get injected the CamelContext so we have all is needed:

@Path("rest")
@Singleton @Startup @Lock(LockType.READ)
public class CamelRestService {
    @Inject
    @ContextName("my-ctx")
    private CamelContext context;

    private CamelDelegate camelDelegate;

    @PostConstruct
    void initDelegate() throws Exception {
        camelDelegate = new ProxyBuilder(context).endpoint("direct:input").build(CamelDelegate.class);
    }

    @POST
    @Path("route")
    public Output foo(final Input request) {
        return new Output(camelDelegate.foo(request));
    }

    private static interface CamelDelegate {
        int foo(Input request);
    }
}

So here we are, when you POST on /rest/foo an Input the response is computed by the camel route.

If you love annotations (and if it matches your programming model) you can even remove the route from the RouteBuilder and decorate CDI beans to use Camel Pojo consuming/producing API:

public class PojoBean {
    @Consume(uri = "direct:input-pojo", context = "my-ctx")
    public int process(final Input request) {
        switch (request.getCriteria()) {
            case "A":
                return 1;

            case "B":
                return 10;

            default:
                return -1;
        }
    }
}

In some cases Java beans are more efficient and easier to write and using Camel mapping is pretty easy, you can even use CDI events in your Camel-CDI beans so why not trying it :).

TomEE/OpenEJB JAXRS refactoring

Until TomEE 1.5.1 JAXRS deployment policy was to map a servlet by endpoint.

This had two drawbacks:

• you had to put @Path at class level for all JAXRS classes
• The entry point for a request was the servlet router (Tomcat) and not the JAXRS one so the routing wasn’t as fine as possible with JAXRS

The advantage was each endpoint were configurable separately.

OpenEJB Application Composer, new features: JAXRS, JAXWS, @Classes…

Go further in standalone webapp testing

It always has been possible to use OpenEJB to test small part of webapps in embedded mode but it needed to perfectly know all internals…mainly means nobody was doing it excepting for some particular advanced tests in OpenEJB itself.

But these days REST, JAXWS etc testing in standalone can be very interesting when working on an issue or simply to get very fast test executions.

JAX-RS/JAX-WS configuration for TomEE 1.5.0

JAX-RS endpoint configuration was not possible (or not easy at all) in last TomEE release. The brand new one makes it possible.

It is important to be able to add custom providers, custom (cxf) interceptors or features…