Hi Alex,
I don't think you need the HttpHandler annotation to be a qualifier (will
typically end up on a method not producing any bean at some point I think
as in the example at the end of this answer).
I guess Request/Response models are not yet done? Side note before you work
on them: maybe don't copy servlet API, content-type, content-length etc are
just headers, no need to make them specific, also prefer to set the payload
(as an inputstream or reactive stream) rather than encapsulating read/write
methods, it enables a better composition and decoration in general and
bypasses to go through a provider/factory to create requests/responses.
Last thing is you probably want to create a package for that work and not
use the default one ;).
Typically it is a good start IMHO and once this works I'd do another small
iteration to end up on:
public class HelloWorldHandlerFuture
{
@HttpHandler(method = {HttpMethod.GET, HttpMethod.POST}, url = "/hello",
matching = Matching.EXACT)
public CompletionStage<Response> apply(Request request)
{
return CompletableFuture.supplyAsync(() ->
{
Response response = new Response();
response.setStatus(200);
response.write("Hello World from " + getClass().getName());
return response;
});
}
}
Small side note (fully related to CompletionStage more than your current
work: if you want a synchronous impl of a CompletionStage you can use
CompletionFuture.completedFuture(response) - avoid the sypplyAsync - and if
you want to be async (sypplyAsync) ensure you pass an executor as second
parameter otherwise you end up being in default ForkJoinPool which has a
lot of side effects and limitations.
Anyway, very good first iteration, it is pretty close to what I was
envisioning and it looks as smooth as I was thinking.
Small tip for the impl phase (don't know if it is the next one or not): for
the handler registration, ensure to enable to do it programmatically:
register(Function<Request, CompletionStage<Response>>). It will enable to
use other models than the annotated one which is just a simplified API of
the actual one the server uses internally.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mar. 16 juin 2020 à 13:08, Alexander Fischer <fische...@mailbox.org> a
écrit :
> Hi Romain,
>
> I have made a first draft for the API and example showcase:
> https://github.com/a-rekkusu/owb-centric-microserver
>
> Please take a look and let me know what you think.
> CompletionStage is supported, but right now for all requests on a
> handler. If you would want a CompletableFuture only for POST for
> example, and not on GET, how do you think we should handle that?
> We could do it with a second HttpHandler on the same url but with the
> respective HttpMethod (e. g. HelloWorldHandlerGet / HelloWorldHandlerPost).
>
> Kind regards,
> Alex
>
> On 06.06.2020 15:44, Romain Manni-Bucau wrote:
> > Hi Alex,
> >
> > Nothing is written in the stone but here is how I would approach that:
> >
> > 1. Write a HTTP server able to call a handler to answer a request - you
> can
> > start by giving a hardcoded handler but in terms of design, ensure you
> get
> > something taking a Request abstracting as input and a Response
> abstraction
> > as output.
> > Netty has these abstraction but we don't want to depend on netty so you
> > should duplicate it making it even more user friendly (netty stays low
> > level).
> > 2. Make this server CDI friendly, basically a CDI bean and nice to have,
> > configurable (port, ssl, ...) with MP-Config (or equivalent - if you
> take a
> > Map<String, String> as input you won here),
> > 3. Now you have to abstract the handler and make the default handler a
> > facade for user handlers. User handlers are CDI beans. I would start by
> > making them with something between servlet and jaxrs:
> >
> > @HttpHandler(method = {GET, POST}, url = "/foo", mathing =
> Matching.EXACT)
> >
> > method being the http method handled, url the urlpattern matched thanks
> the
> > matching algo (i used an enum but it can be anything equivalent). EXACT
> > means request path == url, we can envision wildcard matching (as in
> > servlet), regex matching etc...
> >
> > The signature can start to be the exact expected one
> > (CompletionStage<Response> onRequest(Request)) while validated in the cdi
> > extension grabbing the handlers, then you can relax the CompletionStage
> > requirement (Response onReq(Request)) and finally you can go closer to
> > jaxrs adding @PathParam/@QueryParam/... like annotations but if Request
> API
> > is nice enough it is not required in this layer - it can be a layer on
> top
> > as jaxrs is on top of servlet. What's important here is to be reactive
> > friendly by design - I'll let you play with the threading strategies to
> > have an useful CompletionStage and how to link it - or not ;) - to netty
> > executors.
> >
> > Once handlers well done, it is easy to add filters on top of it, same
> kind
> > of API but it takes another optional parameter:
> >
> > CompletionStage<Response> onRequest(Request request,
> > Supplier<CompletionStage<Response>> proceed);
> >
> > with proceed the call to filter N+1 and finally the handler (check out
> OWB
> > interceptor impl, it is exactly the same.
> >
> > Last important point: ensure to handle @Priority (or add priority = int
> > in @HttpHandler) cause when you will implement the matching chain you
> will
> > need an order normally.
> >
> > Bonus: you can make the matching strategies pluggable if you want and
> just
> > provide some defaults OOTB.
> >
> > Hope it makes sense.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le jeu. 4 juin 2020 à 15:35, Alexander Fischer <fische...@mailbox.org> a
> > écrit :
> >
> >> Hello everyone,
> >>
> >> in the last month I have spent most of my time getting to know coding
> >> basics of Maven, Netty, CDI/OWB and Servlets/Tomcat. I got to know CDI
> >> extensions which will be the technological foundation for the server.
> >>
> >> Next up will be defining and implementing the HTTP API, which will bring
> >> CDI and Netty together. Feel free to contribute your thoughts on the
> >> matter here on the mailing list or in the respective Jira issue:
> >> https://issues.apache.org/jira/projects/OWB/issues/OWB-1319
> >>
> >> @Romain: can you share some ideas, annotations, interfaces for how you
> >> see the API roughly? Any kind of formal requirement-proposal would be
> >> helpful to start with.
> >>
> >> Thanks and best regards,
> >> Alexander
> >>
> >>
>
