Request Parameter Support in AeroGear Controller

gistfile1.md

#Request Parameter Support in AeroGear Controller# This gist discusses the implementation for AEROGEAR-671 which is about adding support for Query, Header, Cookie, and form request parameter support to AeroGear Route endpoints.

Route configuration

This is what a route might look like that uses two Query parameter:

route()
       .from("/cars")
       .on(RequestMethod.GET)
       .produces(MediaType.JSON.toString())
       .to(Home.class).get(queryParam("color"), queryParam("brand"));

The specifies that the get method in the Home class takes two parameters and that these arguments should be extracted from the HttpServletRequest:

public Car get(String color, String brand) {
        return new Car(color, brand);
}

Optionally, one can specify that a default value for a parameter which will be used the parameter is missing from the request:

route()
       .from("/cars")
       .on(RequestMethod.GET)
       .produces(MediaType.JSON.toString())
       .to(Home.class).get(queryParam("color", "red"), queryParam("brand", "Ferrari"));

In a similar manner one can specify formParam, headerParam, and_cookieParam_. Form parameters has an additional support for specifying a class which will be instantiated using form parameters. For example, if you specified:

route()
       .from("/cars")
       .on(RequestMethod.POST)
       .to(Home.class).save(formParam(Car.class));

In the above example the form parameters, car.color and car.brand, would be used to instantiate a new Car instance which would be passed as the argument to the save method.
At the moment, this type of support is only implemented for form parameters. But perhaps this would also make sense for query parameters?

Implementation

The main issue for this task was to find a way to gather the information when building/configuring routes. The way it is implemented at the moment is that for every parameter, added using one of the xxxParam methods, a new instance of Parameter is added to the underlying RouteDescriptor.

The issue is that RouteDescriptor is not exposed to a RouteBuilder implementation which makes sense as this is not something that we'd want to expose to end users. So what I've done right now, is to introduce a RouteDescriptorAccessor which RouteBuilderImpl implements.
With this in place, AbstractRoutingModule can get access to the current RouteDescriptor and add the parameters.