[08:36:33] <xkr47> temporalfox, but if somebody else set them then you don't know at all..

[08:37:07] <temporalfox> D-Spair there are no plans per se, however someone might want to contribute these

[08:38:05] <xkr47> temporalfox, I'm trying to use vert-x and RoutingContext and it's not clear how to allow multiple actors handle resources together..

[08:38:40] <xkr47> temporalfox, should one perhaps replace the request and response instances with wrappers and handle the chaining oneself?

[08:38:46] <temporalfox> xkr47 you don't router is only within the same context

[08:38:57] <temporalfox> or you use event bus to communicate

[08:39:07] <temporalfox> but all routes are handled within the same verticle

[08:40:42] <xkr47> temporalfox, yeeah same context sure

[08:41:35] <xkr47> temporalfox, have time for some quick discussion around this subject?

[08:42:01] <temporalfox> a bit

[08:44:35] <xkr47> temporalfox, I am visualizing the routing context a bit like the servlet filter chain, if you are familiar with those?

[08:44:47] <temporalfox> I used to be

[08:44:52] <xkr47> :)

[08:46:08] <xkr47> temporalfox, so for example I wanted to implement a handler that would collect stats on request handling and write a log entry when the requesrt & response is finished

[08:46:45] <xkr47> temporalfox, so I would like to install various handlers in the request and response to capture the interesting bits of data I want to log

[08:47:17] <xkr47> temporalfox, then the log handler would just call next() and let the other handlers do the actual serving of the request

[08:47:59] <xkr47> temporalfox, now RoutingContext does contain helpers for _some_ of the handlers in form of addBodyEndHandler() etc

[08:48:40] <xkr47> temporalfox, which nicely allows one to add more than one handler to be called by installing helper handlers in the actual request/response handler properties

[08:49:25] <xkr47> temporalfox, but for handlers that do not have such a helper there is only one setter available and no way to e.g. manually chain handlers

[08:50:15] <xkr47> temporalfox, so I don't know, should I just file a PR to add helper addXxxxxHandler() functions to RoutingContext to cover all the handlers? or…

[08:51:15] <temporalfox> it seems that the addBodyEndHandler

[08:51:28] <temporalfox> are just Handler<Void>

[08:51:34] <xkr47> temporalfox, one other idea was to just replace the request/response object with wrappers (like one used to do in servlet filters) and handle the thing in the wrapper

[08:51:41] <temporalfox> I mean it does not seem to be so much an helper

[08:51:56] <temporalfox> I think these are already wrappers as far as I remember

[08:53:04] <xkr47> sorry if I chose my terms confusingly

[08:56:50] <xkr47> so addBodyEndHandler() calls getBodyEndHandlers() which at first invocation installs a handler to response().bodyEndHandler() which calls the added handlers in the order they were added

[08:59:00] <xkr47> so it allows multiple handlers to be installed for this particular event

[08:59:19] <xkr47> but not for for example request.endHandler

[08:59:20] <temporalfox> yes

[08:59:24] <xkr47> and many others

[08:59:26] <temporalfox> that being said it is not a special class

[08:59:41] <temporalfox> and it is directly in RoutingContextImpl

[08:59:48] <xkr47> yes

[08:59:53] <temporalfox> that's maybe the reason ?

[09:01:21] <xkr47> I don't follow?

[09:01:57] <xkr47> how can I add multiple handlers for request.endHandler?

[09:02:49] <xkr47> at least that's what I'd like to do

[09:03:15] <temporalfox> it is for context

[09:03:20] <temporalfox> you can add end handlers

[09:05:11] <xkr47> how? there is no matching addXxHandler() in RoutingContext.

[09:06:49] <temporalfox> what would do request end handler ?

[09:06:56] <temporalfox> isn't it similar to body end handler ?

[09:07:48] <temporalfox> bodyEndHandler is called after body is received

[09:07:53] <temporalfox> even if there is no body

[09:37:42] <xkr47> temporalfox, the addBodyEndHandler() is for the response body

[09:37:50] <temporalfox> ah you want the request

[09:37:51] <temporalfox> sorry

[09:38:02] <xkr47> well the request end handler was just an example

[09:38:21] <xkr47> I don't remember the exact handler I needed, but it wasn't there and I wondered what to do :)

[09:38:31] <temporalfox> I think the best is that you send an email on vertx-dev and ask if it makes sense to add them

[09:38:41] <temporalfox> and if it does, that you volunteer for contributing it

[09:38:46] <xkr47> ok

[09:39:26] <xkr47> thanks

[12:56:57] <AlexLehm> xkr47: about your handler problem, I think handlers in vertx are usually not used like that, but you could implement a chain handler to sneak your log handler in

[12:57:21] <AlexLehm> xkr47: which is essentially a wrapper i guess

[15:15:42] <D-Spair> temporalfox: I'll have a look what it would take to add Logging to JavaScript as a more “accessible” API… Then I will try to move on to Ruby/etc…

[15:15:56] <temporalfox> D-Spair ok cool

[15:16:33] <D-Spair> Now I just have to learn all about the CodeGen tools… :P

[15:16:45] <D-Spair> Any suggested starting points?

[15:45:43] <D-Spair> Also, what copyright header should I be using? Eclipse Foundation, Red Hat, ???

[15:46:45] <D-Spair> There seems to be a lot of differences…

[15:56:29] <D-Spair> And there's nothing in the Contributing doc about that…

[16:08:39] <D-Spair> Hmmmm…. Makes me wonder why Logger is a class instead of an interface…

[16:10:07] <D-Spair> I mean, there's the LogDelegate interface, but it seems superfluous… Why not just have Logger as an interface with a default `getLogger()` method similar to how Router works?

[16:10:55] <D-Spair> Probably too late to change it now though… I'll see if I can work around it.

[16:23:19] <D-Spair> Yuck… Not as simple as I had hoped it was going to be… Either I have to add all sorts of special sauce to each language support module or I have to make breaking changes to the API…. Gnarly.

[19:03:15] *** ChanServ sets mode: +o purplefox