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.
“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 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:
In embedded or spring case it is quite easy to do so:
See Camel CxfRs for more details.
The main drawback are:
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 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.
Defining a DataSource in TomEE is quite easy, the most common way to do so is to define a Resource block in tomee.xml:
<Resource id="jdbc/ds" type="DataSource"> JdbcUrl = jdbc:mysql://datasourcehost:3306/tomee ... </Resource>
When you have multiple hosts you often use datasourcehost (in the previous sample) as a service host (or IP) to delegate then to real hosts. But sometimes it is not possible or too complicated. For such needs TomEE now provides a basic failover feature.
The idea is to reuse dynamic datasource feature of tomee to handle it.
In my previous post I spoke about jars.txt and how to add a jar in a WAR virtually and from several sources (mvn, http, file…).
Now to use it in a more enterprise environment you can use the dedicated maven plugin.
TomEE already supports to enrich an application with dependencies through ClassLoaderConfigurer configuration or using VirtualWebAppClassLoader of Tomcat. The first one has the drawback to be configured in the container and the second to not be very configurable/extensible.
That’s why we now have jars.txt!
Few versions ago TomEE was integrated to Intellij Idea. Here are some screenshots showing you how it looks like.
Cucumber is a nice framework coming from ruby world to do Behavior Driven Development (BDD). It got some nice extensions for others language in cucumber-jvm project.
However it was not integrated with Arquillian so you still had to do all the integration logic yourself.
Akka is a very interesting solution for highly scalable systems but it misses some few things to be usable for big and enterprise applications. One of them is the IoC. For some more advanced applications it can be transactions…
We sometimes see some spring integration but now that JavaEE proposes a real IoC container it worth looking at how it can work.
