Hey Romain,
thanks for the feedback! I have implemented the API feedback now, please
take another look:
https://github.com/a-rekkusu/owb-centric-microserver
Are there functionalities that you miss?
Else, the Netty implementation ist next.
Best regards,
Alex
On 16.06.2020 14:04, Romain Manni-Bucau wrote:
> 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
>>>>
>>>>
