Hi Romain!
Thank you for the extensive answer. I will first make an example for
how I understood the API, and I'd say we proceed from there. I will
check back on you once that's done.
Best 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
>>
>>
