[undertow-dev] How do I handle HTTP Methods in Undertow?

[Stuart Douglas]

Oops, this should read 1.1.0.CR2 and 1.1.0.Final

Stuart

Stuart Douglas wrote:
> 1.1.CR2
>
> 1.1.Final should be out soon.
>
> Stuart
>
> Luke Ambrogio wrote:
>> Thanks Stuart,
>>
>> I think that's exactly what I need, since annotation as you say might
>> not be necessary.
>>
>> Can you specify which version I would need to include in the pom please?
>> Since the one I am using (1.0.14.Final) doesn't seem to include it and
>> maven doesn't seem to know about 1.2.0.Beta1-SNAPSHOT.
>>
>> Cheers
>>
>> On Thu, Sep 25, 2014 at 2:00 AM, Stuart Douglas<sdouglas at redhat.com
>> <mailto:sdouglas at redhat.com>>  wrote:
>>
>>      Undertow is intended to be a lightweight web server rather than a
>>      container, so it does not really have any annotation processing
>>      facilities built in, however it should be fairly easy to implement
>>      something similar on top of Undertow.
>>
>>      Undertow has a handler called io.undertow.server.__RoutingHandler,
>>      that routes requests based on method and path. If you use this
>>      handler it should be possible to build a handler chain based on
>>      annotations on the handler classes.
>>
>>      Note that you don't want to be using reflection in the handleRequest
>>      method, as reflection is relatively slow. Instead the best approach
>>      is to read the annotations and boot time and build up the routing
>>      map while the server is starting.
>>
>>      Stuart
>>
>>      Luke Ambrogio wrote:
>>
>>          So I've decided to start using Undertow, both as an experiment
>>          and due
>>          to the great results it achieved in benchmark tests. And while I
>>          think
>>          it's fantastic there's a feature which is either missing or I
>>          can't find.
>>
>>          I want to develop a RESTful web service so it's important for me to
>>          identify which HTTP method is being called. Now I can get this from
>>          RequestMethod in the HttpServerExchange parameter but if had to
>>          that for
>>          every handler that would become tedious.
>>
>>          My solution, which works but feels wrong, is this:
>>
>>          Created an annotation interface called HTTPMethod:
>>
>>          |@Retention(RetentionPolicy.__RUNTIME)
>>          @Target(ElementType.METHOD)
>>          public  @interface  HTTPMethod  {
>>
>>          public  enum  Method  {
>>
>>                OTHER,  GET,  PUT,  POST,  DELETE
>>          }
>>
>>          Method  method()  default  Method.OTHER;|
>>
>>          an "abstract" class (which is not abstract):
>>
>>          |public  abstract  class  RESTfulHandler  implements  HttpHandler  {
>>
>>          @Override
>>          public  void  handleRequest(__HttpServerExchange  hse)  throws
>>          Exception  {
>>
>>                for  (Method  method:
>>          this.getClass().__getDeclaredMethods())  {
>>
>>                    // if method is annotated with @Test
>>                    if  (method.isAnnotationPresent(__HTTPMethod.class))  {
>>
>>                        Annotation  annotation=
>>          method.getAnnotation(__HTTPMethod.class);
>>                        HTTPMethod  test=  (HTTPMethod)  annotation;
>>
>>
>>                        switch  (test.method())  {
>>                            case  PUT:
>>                                if
>>          (hse.getRequestMethod().__toString().equals("PUT"))  {
>>                                    method.invoke(this);
>>                                }
>>                                break;
>>
>>                            case  POST:
>>                                if
>>          (hse.getRequestMethod().__toString().equals("POST"))  {
>>                                    method.invoke(this);
>>                                }
>>                                break;
>>
>>                            case  GET:
>>                                if
>>          (hse.getRequestMethod().__toString().equals("GET"))  {
>>                                    method.invoke(this);
>>                                }
>>                                break;
>>
>>                            case  DELETE:
>>                                if
>>          (hse.getRequestMethod().__toString().equals("DELETE"))  {
>>                                    method.invoke(this);
>>                                }
>>                                break;
>>                            case  OTHER:
>>                                if
>>          (hse.getRequestMethod().__toString().equals("OTHER"))  {
>>                                    method.invoke(this);
>>                                }
>>                                break;
>>                        }
>>                        if  (test.method()  ==  HTTPMethod.Method.PUT)  {
>>                            method.invoke(this);
>>                        }
>>                    }
>>                }
>>          }|
>>
>>          }
>>
>>          and an implementation of both the above:
>>
>>          |public  class  ItemHandler  extends  RESTfulHandler{
>>
>>          @HTTPMethod(method=GET)
>>          public  void  getAllItems()
>>          {
>>                System.out.println("GET");
>>          }
>>
>>          @HTTPMethod(method=POST)
>>          public  void  addItem()
>>          {
>>                System.out.println("POST");
>>          }
>>
>>          @HTTPMethod
>>          public  void  doNothing()
>>          {
>>                System.out.println("OTHERS");
>>          }|
>>
>>          }
>>
>>          Now as I said, it works, but I'm sure that the abstract class
>>          and it's
>>          implementation have something missing so that they glue
>>          correctly. So my
>>          question is two fold:
>>
>>          1) Is there a better / proper way to filter HTTP requests in
>>          Undertow?
>>          2) What is the correct way of using annotations correctly
>>          correctly in
>>          the above case?
>>
>>          Thanks
>>
>>
>>          _________________________________________________
>>          undertow-dev mailing list
>>          undertow-dev at lists.jboss.org<mailto:undertow-dev at lists.jboss.org>
>>          https://lists.jboss.org/__mailman/listinfo/undertow-dev
>>          <https://lists.jboss.org/mailman/listinfo/undertow-dev>
>>
>>
>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev