Approvals: 0/1
[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