danbev

Route CDI Interceptors and Decorators

After a discussion with qmx and Bruno there was a suggestion to have some sort for filter pattern for AeroGear-Controller. This gist describes a suggestion in hope to "buy" some time to implement this.

Suggestion

CDI has the concept of decorators and interceptors which might be a nice fit for our use case. The idea would be to enable us to specify either/both interceptors/decorators to implement things like Security, Error handling, CORS support etc.

As an example, we have done some prototyping and the following section describes how decorators could be used. There are two cases that we have identified so far:

1. The decorator only needs to inspect/interact with HttpServletRequest and HttpServletResponse
2. The decorator need access to the Route to perform an action before or after invoking the target Route

danbev

CDI vs web.xml configuration

To help decide which approach is best for our users this gist will show how configuring CORS in AeroGear Controller would be like using CDI and via web.xml

CDI

For a CDI version and the specific case of CORS users will probably need to provide their own configuration settings. The proposed solution for this is for a user to provide a CDI Producer, for example:

public class CorsConfigProducer {
    public @Produces CorsConfiguration getConfiguration() {
        return CorsConfig.create()
 .enableCorsSupport(true)

danbev

public class CustomTextFrameHandler extends ChannelInboundMessageHandlerAdapter<TextWebSocketFrame> {
    
    @Override
    public void messageReceived(ChannelHandlerContext ctx, TextWebSocketFrame frame) throws Exception {
        String request = frame.getText();
        ctx.channel().write(new TextWebSocketFrame(request.toUpperCase()));
    }
    
}

danbev

public static void main(String[] args) throws Exception {
    final ServerBootstrap sb = new ServerBootstrap();
    try {
        sb.group(new NioEventLoopGroup(), new NioEventLoopGroup())
         .channel(NioServerSocketChannel.class)
         .localAddress(new InetSocketAddress(port))
         .childHandler(new ChannelInitializer<SocketChannel>() {
            @Override
            public void initChannel(final SocketChannel ch) throws Exception {
                ch.pipeline().addLast(

danbev

public class CustomTextFrameHandler extends SimpleChannelHandler {

    @Override
    public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) throws Exception {
        if (e.getMessage() instanceof TextWebSocketFrame) {
            TextWebSocketFrame frame = (TextWebSocketFrame) e.getMessage();
            ctx.getChannel().write(new TextWebSocketFrame(frame.getText().toUpperCase()));
        }
    }

danbev

CORS Error Response Handling

According to the CORS specification, to indicate an invalid CORS request one simply does not add any CORS specific headers to the response.

There are two situations with regards to CORS Preflight request where this might cause confusion:

1. The request is using a HTTP Method that is not supported by the server
2. The request contains headers that are not supported by the server

In both of these cases the response status would be 200, but there will be no CORS-specific response headers. Since there are no CORS-specific headers in the response, the browser assumes the request is invalid, and doesn’t make the actual request. For both of these situations the client would see the same error:

XMLHttpRequest cannot load http://corscontroller-danbev.rhcloud.com/aerogear-controller-demo/delorean. Origin http://corsclient-danbev.rhcloud.com is not allowed by Access-Control-Allow-Origin.

danbev

public java.lang.String toString();
    Code:
       0: new           #175                // class java/lang/StringBuilder
       3: dup           
       4: ldc           #177                // String DefaultRoute[
       6: invokespecial #179                // Method java/lang/StringBuilder."<init>":(Ljava/lang/String;)V
       9: ldc           #182                // String path=
      11: invokevirtual #184                // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
      14: aload_0       
      15: getfield      #60                 // Field path:Ljava/lang/String;

danbev

public java.lang.String toString();
    Code:
       0: new           #175                // class java/lang/StringBuilder
       3: dup           
       4: ldc           #177                // String DefaultRoute[path=
       6: invokespecial #179                // Method java/lang/StringBuilder."<init>":(Ljava/lang/String;)V
       9: aload_0       
      10: getfield      #60                 // Field path:Ljava/lang/String;
      13: invokevirtual #182                // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
      16: ldc           #186                // String , 

danbev

Paging/Querying in AeroGear Controller

This document is intended to discuss a solution for AEROGEAR-645 "Add Query/Paging support on RESTful endpoints".
This dev-aerogear mail list thread was used as a starting point to gather requirements and ideas.

Background

Lets just clarify the two concepts that we are dealing with here, Paging and Query.

Paging

Paging deals with limiting the number of results returned from a single request. One "page" can contain a certain number of items as the result of invoking a request, sometimes referred to the size of a page. Let say you want to limit you the number of result returned to 10 items, this could look something like this:

danbev

RESTFul Endpoints in AeroGear Controller

The plan for AeroGear Controller is to utilize RestEasy which is a JAX-RS implementation. There is really nothing in the JAX-RS specification that we require, but more some of the functionality that the exists in RestEasy. This document will try to list what this functionality is and if we should really use a JAX-RS implementation of write/"borrow" what we need.

AeroGear controller current has routing support for POJO endpoints, but current routing will forward the result of such an endpoint to a view. For a RESTful POJO endpoint we would return the data in the content type that the caller asks for (using the Http Accept header).

Working Branch

Features Required

The following features have been identified as required by AeroGear Controller.