Differences

This shows you the differences between two versions of the page.

Link to this comparison view

irc:1485385200 [2017/05/27 13:44] (current)
Line 1: Line 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