Cuke in Space!, close of a release

Cuke in Space!,  this project aiming to bring cucumber BDD framework to Arquillian. The goal is simple: keep the strength of the Behavior Driven Development adding to it the strength of  Arquillian (portable test writing between containers, deployment control, multi-containers tests…).

Since it is close to a release this post shows important new features you’ll get with it.

What i think about “Arquillian testing guide”

“Arquillian Testing Guide” is a book you can buy on packt publishing website here: Arquillian Testing Guide. I just read it and you’ll find in this article what i liked and what i missed in it.

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 :).

Arquillian OpenEJB embedded adaptor supports @ArquillianResource URL

Arquillian provides some specific injections. The most known of them is probably:

@ArquillianResource
private URL url;

It globally provides you the context url of your web application.

For embedded adapters it doesn’t make a lot of sense to support it (and all your tests are executed “in” the container).

OpenEJB embedded adapter is a bit particular because it doesn’t support a full servlet container features but some part of them only. Its main supported features are (very) basic servlets/listeners, ejbd (remote ejb protocol), JAX-WS and of course JAX-RS.