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
>
>
