Differences

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

Link to this comparison view

irc:1431295200 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +
 +
 +[03:36:27] <​saltuk>​ hi there  .. i didnt know about    vertx.getOrCreateContext() before see it on jdbc-client ​  ​so ​ this logic on  http://​codepaste.net/​si872f will work or do i need to something different ? ...
 +
 +[09:41:13] <​purplefox>​ hi AlexLehm
 +
 +[10:12:48] <​purplefox>​ temporalfox:​ hi julien
 +
 +[10:12:54] <​temporalfox>​ hi purplefox
 +
 +[10:12:58] <​purplefox>​ temporalfox:​ good weekend?
 +
 +[10:13:25] <​temporalfox>​ purplefox good, resting a little was good for me :-)
 +
 +[10:13:47] <​purplefox>​ it's important ​ :)
 +
 +[10:14:04] <​temporalfox>​ purplefox ready for the last milestone ?
 +
 +[10:14:36] <​purplefox>​ getting prepared for it. let's have a little meeting in a while to discuss what remains to be done
 +
 +[10:14:54] <​temporalfox>​ ok
 +
 +[10:15:00] <​purplefox>​ how about 11am (my time) - i.e. in 1 hr 45
 +
 +[10:15:28] <​temporalfox>​ can we have it a bit earlier ?
 +
 +[10:21:10] <​purplefox>​ ok, how about at 9:45?
 +
 +[10:21:14] <​purplefox>​ (25 mins)
 +
 +[10:22:53] <​temporalfox>​ ok good
 +
 +[10:24:13] <​purplefox>​ temporalfox:​ btw, if you can think of any good names to rename Apex to, that's something to think about
 +
 +[10:24:26] <​temporalfox>​ purplefox I'm really bad at finding names :-)
 +
 +[10:24:38] <​purplefox>​ it's difficult
 +
 +[10:24:58] <​temporalfox>​ it's a job for some :-)
 +
 +[10:25:10] <​purplefox>​ i'm thinking of variations around the theme of "​vert.x",​ "​web",​ "​microservice"​ and "​boot"​
 +
 +[10:25:25] <​temporalfox>​ vertx woot :-) ?
 +
 +[10:25:35] <​purplefox>​ lol.
 +
 +[10:25:45] <​purplefox>​ or microvertxwebboot?​
 +
 +[10:26:01] <​purplefox>​ actually woot is not too bad...
 +
 +[10:28:47] <​purplefox>​ temporalfox:​ what about "​microbe"​ ?
 +
 +[10:29:01] <​purplefox>​ it's small. it's got micro in it ,and a b for boot?
 +
 +[10:29:40] <​temporalfox>​ microbe in french is not really sexy
 +
 +[10:30:07] <​purplefox>​ i guess it's a bit like "​bacteria"​ ? ;)
 +
 +[10:30:12] <​temporalfox>​ exactly
 +
 +[10:30:51] <​purplefox>​ micrex?
 +
 +[10:31:09] <​purplefox>​ voot?
 +
 +[10:32:13] <​temporalfox>​ not really
 +
 +[10:32:31] <​purplefox>​ vapex?
 +
 +[10:33:04] <​temporalfox>​ webex ?
 +
 +[10:33:09] <​purplefox>​ lol. nooooo!
 +
 +[10:33:33] <​purplefox>​ vicro?
 +
 +[10:34:04] <​temporalfox>​ vertx factor
 +
 +[10:34:37] <​pmlopes>​ what about load? it is kind of a synonym to boot
 +
 +[10:35:08] <​purplefox>​ load can also mean to make something heavy
 +
 +[10:35:16] <​purplefox>​ i.e. not lightweight
 +
 +[10:35:50] <​purplefox>​ what about xepa? (apex backwards)
 +
 +[10:36:04] <​temporalfox>​ not good
 +
 +[10:36:47] <​pmlopes>​ xerpa
 +
 +[10:38:03] <​temporalfox>​ vertx spine ?
 +
 +[10:38:16] <​purplefox>​ carob
 +
 +[10:38:42] <​purplefox>​ ok keep em coming
 +
 +[10:39:15] <​purplefox>​ pmlopes: julien and i are going to discuss remaining ​ tasks for V3 in a little while.. feel free to join in if you like :)
 +
 +[10:40:24] <​millrossjez>​ vertx-sherpa :)
 +
 +[10:40:43] <​purplefox>​ vertx - sherpa - it helps you climb mountains ;)
 +
 +[10:40:51] <​purplefox>​ yeah not bad
 +
 +[10:40:57] <​temporalfox>​ vertx face :-)
 +
 +[10:41:12] <​pmlopes>​ or: brink
 +
 +[10:46:06] <​temporalfox>​ vertx flow
 +
 +[10:46:08] <​temporalfox>​ vertx path
 +
 +[10:50:10] <​purplefox>​ how about - in node.js there is express project, and espresso is a small coffee, so how about doppio? (double espresso?)
 +
 +[10:50:21] <​purplefox>​ and coffee is java of course
 +
 +[10:51:15] <​temporalfox>​ it's also a JVM in coffeescript
 +
 +[10:51:17] <​temporalfox>​ Doppio: A JVM in Coffeescript
 +
 +[10:51:22] <​temporalfox>​ besides that I like it
 +
 +[10:51:42] <​temporalfox>​ and there is potential for a good logo
 +
 +[10:52:04] <​temporalfox>​ (with the coffee cream, etc...)
 +
 +[10:52:05] <​purplefox>​ yeah. a jvm in coffeescript may be far enough removed not to be an issue
 +
 +[10:52:52] <​purplefox>​ hmmm seems fairly popular actually :(
 +
 +[10:52:55] <​purplefox>​ 706 stars
 +
 +[10:53:03] <​purplefox>​ https://​github.com/​plasma-umass/​doppio
 +
 +[10:53:59] <​purplefox>​ ok... anyway let's keep thinking
 +
 +[10:54:07] <​purplefox>​ but let's get on with the meeting now
 +
 +[10:54:21] <​purplefox>​ how about we just go through each project one by one, and see what is outstanding?​
 +
 +[10:54:52] <​temporalfox>​ I'​mready for meeting
 +
 +[10:55:00] <​temporalfox>​ good idea
 +
 +[10:55:13] <​purplefox>​ ok let's start with core
 +
 +[10:55:58] <​temporalfox>​ I would like to have simple metrics tests that check context / thread and then clarify the behavior in the spi doc
 +
 +[10:56:19] <​purplefox>​ ok, makes sense
 +
 +[10:56:21] <​temporalfox>​ because callbacks will have different thread depending on the metric part
 +
 +[10:56:31] <​temporalfox>​ and that should be clear for the spi implementor what to expect
 +
 +[10:56:50] <​purplefox>​ agreed
 +
 +[10:57:12] <​purplefox>​ also there are a few gaps in the docs in general, but other than that I don't think there is any significant work to do
 +
 +[10:57:17] <​temporalfox>​ other thing
 +
 +[10:57:29] <​temporalfox>​ I would like to have a WriteStream.end()
 +
 +[10:57:39] <​temporalfox>​ corresponding to onComplete()
 +
 +[10:57:44] <​temporalfox>​ that say no more event will come
 +
 +[10:58:04] <​purplefox>​ is this what we discussed before?
 +
 +[10:58:06] <​temporalfox>​ makes implementation for rx / reactive-streams better
 +
 +[10:58:11] <​temporalfox>​ yes but it was less clear :-)
 +
 +[10:58:18] <​temporalfox>​ now I know it should mean "no more event"
 +
 +[10:58:30] <​temporalfox>​ and we do have this in ReadStream#​endHandler
 +
 +[10:58:42] <​temporalfox>​ and actually I think node.js does have it in WriteStream
 +
 +[10:58:56] <​purplefox>​ sec, brb 3 mins
 +
 +[11:01:07] <​purplefox>​ ok back, door
 +
 +[11:01:27] <​purplefox>​ ok that makes sense to add that method
 +
 +[11:01:49] <​temporalfox>​ ^^
 +
 +[11:02:15] <​purplefox>​ anything else on core?
 +
 +[11:03:10] <​temporalfox>​ I don't see anything outstanding right now
 +
 +[11:03:27] <​purplefox>​ Alright.. let's do web-site next
 +
 +[11:03:41] <​temporalfox>​ really :-) ?
 +
 +[11:03:55] <​temporalfox>​ I find the actual website very good
 +
 +[11:03:57] <​purplefox>​ why not?
 +
 +[11:04:20] <​temporalfox>​ I believe a blog would be good
 +
 +[11:04:28] <​temporalfox>​ I mean I want to write things about vertx
 +
 +[11:04:35] <​temporalfox>​ and I don't want to do it on my own blog
 +
 +[11:04:44] <​purplefox>​ Agreed, but I'm not sure it is a priority for 3.0
 +
 +[11:04:48] <​temporalfox>​ ok
 +
 +[11:04:52] <​purplefox>​ i'll add it to the list anyway
 +
 +[11:05:06] <​purplefox>​ The content on the front page needs some tweaks
 +
 +[11:05:28] <​purplefox>​ The community page needs completing with contributors
 +
 +[11:06:03] <​temporalfox>​ yes but I think that there is some wip about that
 +
 +[11:06:06] <​purplefox>​ Who's using vert.x stuff needds to be completed
 +
 +[11:06:12] <​temporalfox>​ using a json structure to generate contributor page
 +
 +[11:06:38] <​purplefox>​ yeah, but it still needs completing :)
 +
 +[11:06:48] <​purplefox>​ basically anything that needs to be done goes on the list
 +
 +[11:07:21] <​purplefox>​ I want to get an overall picture of everthing that needs to be done before 3.0
 +
 +[11:07:26] <​temporalfox>​ ok
 +
 +[11:07:55] <​purplefox>​ but agreed, the website is great :) thanks to michel
 +
 +[11:08:48] <​purplefox>​ i think the docs page could be tweaked a bit but is more or less there
 +
 +[11:10:14] <​purplefox>​ only 4 contributors have actually submitted their details so far so maybe we will have to be more proactive
 +
 +[11:10:25] <​temporalfox>​ ok
 +
 +[11:10:34] <​purplefox>​ pmlopes: millrossjez what about you guys?
 +
 +[11:10:43] <​temporalfox>​ I think michel is doing some kind of json -> html generator for contributors
 +
 +[11:11:16] <​purplefox>​ yeah
 +
 +[11:11:53] <​purplefox>​ i think what we should also do is write a little script that uses the github rest api to get a list of all contributors for all projects and their github ids then we can create some html for that
 +
 +[11:12:28] <​purplefox>​ otherwise it looks like we only have 4 contribs, when the truth is we probably have over a hundred (i would guess)
 +
 +[11:12:34] <​temporalfox>​ I remember back in the days we put randomly a contributor on the front page on jboss.org site
 +
 +[11:12:54] <​purplefox>​ ah yes i remember that :)
 +
 +[11:13:59] <​pmlopes>​ @purplefox yes you can add me to the list
 +
 +[11:14:23] <​pmlopes>​ i also asked at work for being listed but did not get any feedback on that
 +
 +[11:16:30] <​purplefox>​ pmlopes: ok, np. can you submit a pr as per https://​groups.google.com/​forum/?​fromgroups#​!topic/​vertx/​_rlRE6FViNA ?
 +
 +[11:19:50] <​purplefox>​ ok, anything else on website?
 +
 +[11:20:55] <​temporalfox>​ I don't see anything outstanding now
 +
 +[11:21:36] <​purplefox>​ ok, let's do apex next
 +
 +[11:21:53] <​temporalfox>​ ok
 +
 +[11:21:59] <​purplefox>​ the main thing here is the WIP refactoring to the auth/​session stuff
 +
 +[11:22:08] <​temporalfox>​ I followed that on the list indeed
 +
 +[11:22:16] <​purplefox>​ which stephane is looking at. pmlopes are you looking at this too?
 +
 +[11:23:14] <​purplefox>​ so basically that's an important thing that needs completing, because we don't want to change major interfaces after 3.0 is out
 +
 +[11:23:34] <​purplefox>​ i will chase that up with stephane today
 +
 +[11:23:47] <​temporalfox>​ I agree
 +
 +[11:24:51] <​pmlopes>​ Stephane was supposed to deliver his WIP but i haven'​t heard from him yet, i mailed him during the weekend but again no success...
 +
 +[11:25:23] <​purplefox>​ paulo, it would be great if you could review it, as I want to be sure it fulfills your requirements too, and looks correct :)
 +
 +[11:28:13] <​purplefox>​ ah shit, my back button has just failed on my keyboard :(
 +
 +[11:30:53] <​purplefox>​ there are a few other smaller bugs/issues in apex, but nothing else major
 +
 +[11:32:13] <​purplefox>​ ok.. codegen next
 +
 +[11:32:22] <​purplefox>​ temporalfox:​ can you think of anything major outstanding?​
 +
 +[11:33:09] <​temporalfox>​ codegen there is this PR for List<​DataObject>​
 +
 +[11:33:17] <​temporalfox>​ contribution
 +
 +[11:33:28] <​temporalfox>​ and I'm driving the guy to finish it
 +
 +[11:33:35] <​temporalfox>​ (lack of TCK / lang tests)
 +
 +[11:33:50] <​temporalfox>​ let me look at the open issues
 +
 +[11:33:51] <​purplefox>​ is that needed for 3.0?
 +
 +[11:34:27] <​temporalfox>​ that would allow I htink better interfaces
 +
 +[11:34:38] <​temporalfox>​ I mean better apis
 +
 +[11:34:41] <​temporalfox>​ and that is contributed
 +
 +[11:34:56] <​purplefox>​ is there a use case for this?
 +
 +[11:35:37] <​temporalfox>​ not of my own
 +
 +[11:35:51] <​temporalfox>​ https://​github.com/​vert-x3/​vertx-codegen/​pull/​30
 +
 +[11:36:41] <​purplefox>​ ok, with something like this-- I think it is good, but I don't think we should spend a lot of time on it ourselves because there is other more important stuff. but if the contibutor is doing all the work that's fine :)
 +
 +[11:37:33] <​purplefox>​ pmlopes: stephane has just posted on the google group about the session/​auth stuff
 +
 +[11:38:18] <​temporalfox>​ personally the only feature I would honor is that one : https://​github.com/​vert-x3/​vertx-codegen/​issues/​29
 +
 +[11:38:21] <​temporalfox>​ Expose a structured ParamInfo.description
 +
 +[11:38:27] <​temporalfox>​ to generate better documentation
 +
 +[11:38:31] <​temporalfox>​ at the moment if we have
 +
 +[11:38:58] <​temporalfox>​ @param foo the foo {@link io.vertx.core.streams.ReadStream}
 +
 +[11:39:04] <​temporalfox>​ that will be opaque and not rewritten
 +
 +[11:39:17] <​temporalfox>​ it was raised on the forum by the latest scala contributor
 +
 +[11:39:35] <​temporalfox>​ it's not big deal
 +
 +[11:39:38] <​temporalfox>​ minor
 +
 +[11:40:24] <​purplefox>​ ok
 +
 +[11:41:33] <​purplefox>​ alright, next: docgen
 +
 +[11:41:38] <​purplefox>​ anything to do there?
 +
 +[11:41:45] <​temporalfox>​ I don't see any issue in docgen
 +
 +[11:43:00] <​purplefox>​ great
 +
 +[11:43:05] <​purplefox>​ ok next: vertx-stack
 +
 +[11:43:16] <​purplefox>​ for me the big thing here is I think we should have multiple distros
 +
 +[11:43:21] <​temporalfox>​ yes
 +
 +[11:43:35] <​temporalfox>​ and also integrate docker here somehow
 +
 +[11:43:36] <​purplefox>​ and we also need to analyse the dependencies to make sure we are not pulling in unnecessary thibngs
 +
 +[11:43:49] <​purplefox>​ yes
 +
 +[11:44:01] <​temporalfox>​ purplefox we should actually have a blacklist approach for dependencies
 +
 +[11:44:05] <​temporalfox>​ and allow only some
 +
 +[11:44:18] <​temporalfox>​ instead of being permitive
 +
 +[11:44:46] <​purplefox>​ do you mean a blacklist or whitelist?
 +
 +[11:44:52] <​temporalfox>​ a whitellist
 +
 +[11:44:55] <​purplefox>​ i agree
 +
 +[11:45:00] <​temporalfox>​ exclude non io.vertx jars
 +
 +[11:45:10] <​temporalfox>​ and include explicitly the ones we need
 +
 +[11:45:13] <​temporalfox>​ per distrib
 +
 +[11:45:27] <​purplefox>​ yes, and if the build attempts to pull in one that is not on the list the build should fail
 +
 +[11:45:53] <​temporalfox>​ purplefox I don't know if that's trivial to do
 +
 +[11:47:02] <​purplefox>​ in maven it's probably tricky - but maybe we could write a script to do it, and just call that from the build?
 +
 +[11:47:32] <​temporalfox>​ purplefox yes somehow like
 +
 +[11:47:33] <​temporalfox>​ this
 +
 +[11:47:38] <​temporalfox>​ need to see
 +
 +[11:48:04] <​purplefox>​ so let's discuss for a bit which distros we would like
 +
 +[11:48:16] <​purplefox>​ i am thinking:
 +
 +[11:48:32] <​temporalfox>​ I think we should also define per distro the corresponding depchain
 +
 +[11:48:41] <​purplefox>​ ok
 +
 +[11:48:47] <​temporalfox>​ so people can use corresponding depchain to bring in everything they need but with a scope
 +
 +[11:49:03] <​purplefox>​ yes
 +
 +[11:49:21] <​purplefox>​ so what dists do we want?
 +
 +[11:49:29] <​purplefox>​ 1. "​all"​ - containing everything
 +
 +[11:49:30] <​temporalfox>​ we should ask maybe on the list :-)
 +
 +[11:49:38] <​temporalfox>​ all / minimal are the obvious ones
 +
 +[11:49:43] <​purplefox>​ yes, lets post about it there too
 +
 +[11:49:47] <​purplefox>​ agreed
 +
 +[11:49:49] <​temporalfox>​ then at least one without messaging / jcr / etc...
 +
 +[11:49:51] <​temporalfox>​ jca
 +
 +[11:50:05] <​temporalfox>​ i.e like data + web
 +
 +[11:50:09] <​purplefox>​ i think jca should never be in the dist as its something you install in the app server
 +
 +[11:50:14] <​temporalfox>​ ah yes indeed
 +
 +[11:50:16] <​temporalfox>​ good point :-)
 +
 +[11:51:11] <​purplefox>​ and i think one per language
 +
 +[11:51:24] <​temporalfox>​ yes
 +
 +[11:52:49] <​purplefox>​ ok, would you like to post a suggestion on the google group about this and see what people suggest?
 +
 +[11:53:17] <​temporalfox>​ ok I will
 +
 +[11:53:18] <​purplefox>​ we don't want _too many_ distros, so it's kind of tricky
 +
 +[11:53:37] <​purplefox>​ maybe somethings should never be included and users have to explicitly add them...
 +
 +[11:56:58] <​purplefox>​ ok next is service-proxy
 +
 +[11:57:06] <​purplefox>​ i think there is nothing outstanding there
 +
 +[11:57:13] <​temporalfox>​ there is a corresponding PR for List<​DataObject>​
 +
 +[11:57:19] <​temporalfox>​ contribution
 +
 +[11:57:25] <​temporalfox>​ needs to be reviewed
 +
 +[11:57:27] <​purplefox>​ yes
 +
 +[11:57:42] <​temporalfox>​ beside that I don't see anything to do
 +
 +[11:58:36] <​purplefox>​ ok
 +
 +[11:58:41] <​purplefox>​ next vertx-hazelcast
 +
 +[11:58:55] <​purplefox>​ there is currently a major ouststanding hazelcast bug
 +
 +[11:59:14] <​temporalfox>​ I believe you :-)
 +
 +[12:03:09] <​purplefox>​ https://​github.com/​hazelcast/​hazelcast/​issues/​5220
 +
 +[12:03:19] <​temporalfox>​ ok
 +
 +[12:03:47] <​purplefox>​ if they don't fix it before 3.0 then we are going to have to do some major work in the way clustering is done to workaround it
 +
 +[12:04:02] <​purplefox>​ which would probably take several days
 +
 +[12:04:07] <​purplefox>​ so that is a risk
 +
 +[12:04:22] <​temporalfox>​ I see...
 +
 +[12:04:26] <​temporalfox>​ no control
 +
 +[12:06:03] <​purplefox>​ ok next, http-service-factory
 +
 +[12:06:41] <​temporalfox>​ port the 2.x client features : redirection + bintray tutorial
 +
 +[12:06:57] <​purplefox>​ i am sure it all works perfectly ;) but as a user if i come to this site https://​github.com/​vert-x3/​vertx-http-service-factory it doesn'​t really tell me what it is for or how to use it
 +
 +[12:07:10] <​purplefox>​ so this is a mystery to me
 +
 +[12:07:19] <​temporalfox>​ there is doc in the project itself
 +
 +[12:07:29] <​purplefox>​ there is a broken link on the readme
 +
 +[12:07:36] <​temporalfox>​ http://​vert-x3.github.io/​docs/​vertx-http-service-factory/​
 +
 +[12:07:42] <​temporalfox>​ ok
 +
 +[12:08:04] <​purplefox>​ I get a 404 on the docs link on the front page
 +
 +[12:08:33] <​temporalfox>​ ok
 +
 +[12:09:13] <​purplefox>​ ok i can see the actual docs now, and they look good
 +
 +[12:09:54] <​temporalfox>​ fixed :-)
 +
 +[12:12:13] <​purplefox>​ ok. maven-service-factory
 +
 +[12:12:18] <​purplefox> ​ i think we are all good there?
 +
 +[12:12:26] <​temporalfox>​ yes
 +
 +[12:12:42] <​temporalfox>​ overally I think in the next iteration 3.1 there can be improvments
 +
 +[12:12:49] <​temporalfox>​ but for 3.0 it's fit the needs
 +
 +[12:13:18] <​purplefox>​ vertx-reactive-streams
 +
 +[12:13:26] <​purplefox>​ i think we are good there too?
 +
 +[12:14:19] <​temporalfox>​ we need to see if there is something to do with WriteStream#​end
 +
 +[12:14:30] <​purplefox>​ ok
 +
 +[12:14:32] <​temporalfox>​ and probably there is
 +
 +[12:18:31] <​millrossjez>​ purplefox: I will be submitting my contrib info, pitiful though my contribs are so far, was waiting for that json generator. I'm probably the smallest contributor so far :)
 +
 +[12:20:36] <​purplefox>​ it all counts :)
 +
 +[12:21:59] <​temporalfox>​ millrossjez size does not matter
 +
 +[12:23:40] <​purplefox>​ lol
 +
 +[12:23:55] <​aesteve>​ hello everyone :)
 +
 +[12:23:58] <​purplefox>​ hi
 +
 +[12:24:05] <​aesteve>​ so for apex release : only session/​auth ?
 +
 +[12:24:19] <​purplefox>​ aesteve: that's the major thing, yes
 +
 +[12:24:55] <​aesteve>​ ok nice to have a view on the release plan
 +
 +[12:25:31] <​purplefox>​ ok. vertx-rx
 +
 +[12:25:38] <​purplefox>​ temporalfox:​ anytihng to do there?
 +
 +[12:25:41] <​temporalfox>​ yes
 +
 +[12:25:49] <​temporalfox>​ finish the reactive-streams rebase in progress
 +
 +[12:26:15] <​temporalfox>​ possibly provide an Observer for WriteStream
 +
 +[12:26:23] <​temporalfox>​ I started some work actually on this a while ago
 +
 +[12:26:55] <​temporalfox>​ and I do have the code locally
 +
 +[12:27:05] <​temporalfox>​ need to see how it fits with reactive streams
 +
 +[12:27:14] <​temporalfox>​ overally
 +
 +[12:27:21] <​temporalfox>​ with vertx core / vertx-rx and reactive streams
 +
 +[12:27:24] <​temporalfox>​ it's related work
 +
 +[12:27:25] <​purplefox>​ this is for back pressure?
 +
 +[12:27:30] <​temporalfox>​ and I would like to have a proper closure
 +
 +[12:27:37] <​temporalfox>​ on these
 +
 +[12:27:51] <​temporalfox>​ so primarly the feature was not back pressure
 +
 +[12:28:03] <​temporalfox>​ but how to turn a WriteStream -> rx Observer
 +
 +[12:28:14] <​temporalfox>​ like we do have for ReadStream -> Observable
 +
 +[12:28:31] <​temporalfox>​ now if we rely on reative streams
 +
 +[12:28:34] <​temporalfox>​ to do the bridge
 +
 +[12:28:38] <​temporalfox>​ we have back pressure
 +
 +[12:29:04] <​temporalfox>​ so at the end someone
 +
 +[12:29:09] <​purplefox>​ i guess i still don't understand why writestream needs to be an observer
 +
 +[12:29:24] <​temporalfox>​ because you can subscrive it to an Observable
 +
 +[12:29:57] <​temporalfox>​ you can take a file and subscribe it to an HttpServerRequest
 +
 +[12:30:29] <​temporalfox>​ request.toObserable().subscribe(file.toObserver())
 +
 +[12:30:48] <​purplefox>​ and that is supposed to do back pressure too?
 +
 +[12:30:52] <​temporalfox>​ yes
 +
 +[12:31:10] <​temporalfox>​ since Observer will get the Subscription
 +
 +[12:31:18] <​temporalfox>​ and Subscription has a request(n) method
 +
 +[12:31:48] <​temporalfox>​ we can delay that to 3.1 if you feel more comfortable
 +
 +[12:31:51] <​temporalfox>​ Observer par
 +
 +[12:31:53] <​temporalfox>​ part
 +
 +[12:32:10] <​temporalfox>​ I agree that we would not have feedback on it like we had for Observable
 +
 +[12:35:08] <​purplefox>​ this confuses me as it seems to be back to front
 +
 +[12:35:22] <​temporalfox>​ ok let's skip it :-)
 +
 +[12:35:34] <​temporalfox>​ and focus on getting proper Observable / back pressure support
 +
 +[12:35:48] <​purplefox>​ for example here is vertx-reactive-streams
 +
 +[12:35:49] <​purplefox>​ https://​github.com/​vert-x3/​vertx-reactive-streams/​blob/​master/​src/​main/​java/​examples/​ReactiveStreamsExamples.java#​L48
 +
 +[12:36:07] <​purplefox>​ and this is about pumping a server request to a file, just like your example
 +
 +[12:36:32] <​temporalfox>​ ok
 +
 +[12:36:37] <​purplefox>​ in this case the file subscribes to the request
 +
 +[12:36:40] <​purplefox>​ which makes sense
 +
 +[12:36:46] <​purplefox>​ as the file receives data from the request
 +
 +[12:37:04] <​purplefox>​ but in your example, it's the other way around, which i don't understand
 +
 +[12:37:07] <​temporalfox>​ I think that if we do use reative-streams for implementing RxJava
 +
 +[12:37:17] <​temporalfox>​ we do have double pumping
 +
 +[12:37:35] <​temporalfox>​ credits -> request -> credits
 +
 +[12:38:19] <​purplefox>​ i'm talking about flow of data here
 +
 +[12:38:20] <​purplefox>​ not credits
 +
 +[12:38:52] <​purplefox>​ i don't see why a request would subscribe to a file if the data is flowing in the other direction
 +
 +[12:39:18] <​temporalfox>​ ok
 +
 +[12:39:27] <​purplefox>​ anyway, yeah lets leave this to 3.1 because I am confused ;)
 +
 +[12:39:48] <​temporalfox>​ it's terminolgy
 +
 +[12:39:56] <​temporalfox>​ in RxJava Observable.subscribe(observer)
 +
 +[12:40:05] <​temporalfox>​ means I subscribe an Observer to an Observable
 +
 +[12:40:14] <​temporalfox> ​    ​public final Subscription subscribe(Subscriber<?​ super T> subscriber) {
 +
 +[12:40:18] <​temporalfox>​ on Observable
 +
 +[12:40:35] <​temporalfox>​ agreed we should skip
 +
 +[12:40:47] <​purplefox>​ i think it means the same (more or less) in reactive streams
 +
 +[12:41:05] <​purplefox>​ but subscribers *receive data*
 +
 +[12:41:05] <​temporalfox>​ let's go on :-)
 +
 +[12:41:10] <​temporalfox>​ yes
 +
 +[12:41:23] <​temporalfox>​ HttpServerRequest is an Observable<​Buffer>​
 +
 +[12:41:35] <​temporalfox>​ File can be an Observer<​Buffer>​ (for writing)
 +
 +[12:42:12] <​purplefox>​ hmmm not sure about that
 +
 +[12:42:48] <​temporalfox>​ I need to go to lunch soon :-)
 +
 +[12:42:50] <​purplefox>​ ok let's skip this
 +
 +[12:44:38] <​purplefox>​ when do you need to go to lunch?
 +
 +[12:44:54] <​temporalfox>​ 15mn max
 +
 +[12:45:15] <​purplefox>​ ok let's see if we can be quick:
 +
 +[12:45:19] <​purplefox>​ mail-client:​
 +
 +[12:45:32] <​purplefox>​ basically waiting for alex to make some changes and docs to be done
 +
 +[12:45:33] <​temporalfox>​ you know better than me
 +
 +[12:45:37] <​temporalfox>​ ok
 +
 +[12:46:00] <​purplefox>​ jdbc-client:​
 +
 +[12:46:09] <​purplefox>​ all good i think
 +
 +[12:46:13] <​temporalfox>​ yes
 +
 +[12:46:21] <​purplefox>​ mysql-postgres:​
 +
 +[12:46:22] <​purplefox>​ all good
 +
 +[12:46:41] <​purplefox>​ vertx-mongo
 +
 +[12:46:44] <​purplefox>​ all good
 +
 +[12:46:51] <​temporalfox>​ data services look good
 +
 +[12:46:55] <​temporalfox>​ I mean
 +
 +[12:46:58] <​temporalfox>​ data clients :-)
 +
 +[12:47:04] <​purplefox>​ vertx-redis:​
 +
 +[12:47:07] <​purplefox>​ needs docs
 +
 +[12:47:23] <​temporalfox>​ yes
 +
 +[12:47:37] <​purplefox>​ vertx-rabbitmq -- need to look at this
 +
 +[12:47:42] <​purplefox>​ not sure what is there yet
 +
 +[12:47:53] <​temporalfox>​ ok
 +
 +[12:48:05] <​purplefox>​ and same with vertx-amqp
 +
 +[12:48:13] <​temporalfox>​ ok
 +
 +[12:48:38] <​purplefox>​ where are we with vertx-lang-ruby?​
 +
 +[12:48:50] <​temporalfox>​ missing specific documentation
 +
 +[12:49:01] <​temporalfox>​ specific ruby documentation
 +
 +[12:49:10] <​temporalfox>​ besides I think it's good looking
 +
 +[12:49:20] <​purplefox>​ does codetrans work with it?
 +
 +[12:49:22] <​temporalfox>​ I hope we get feedback with milestone5
 +
 +[12:49:28] <​temporalfox>​ purplefox yes but it is not perfect
 +
 +[12:49:38] <​temporalfox>​ I tested with core examples and theyr owrk
 +
 +[12:49:43] <​temporalfox>​ they allowed me to fix bugs
 +
 +[12:49:53] <​temporalfox>​ I need to try apex examples
 +
 +[12:49:59] <​temporalfox>​ and see if they pass
 +
 +[12:50:06] <​temporalfox>​ there is one issue I tink at least in codetrans
 +
 +[12:50:13] <​temporalfox>​ the "​x++"​
 +
 +[12:50:21] <​temporalfox>​ that does not have equivalent in ruby
 +
 +[12:50:29] <​temporalfox>​ so I'm considering banning it
 +
 +[12:50:32] <​temporalfox>​ and use instead ++x
 +
 +[12:50:51] <​temporalfox>​ x++ is fine as long as the value is not used
 +
 +[12:50:57] <​temporalfox>​ like a for loop
 +
 +[12:51:03] <​temporalfox>​ so I need to figure this out
 +
 +[12:51:07] <​temporalfox>​ and do more testing for codetrans
 +
 +[12:51:14] <​purplefox>​ ok
 +
 +[12:51:55] <​purplefox>​ vertx-examples:​
 +
 +[12:51:59] <​purplefox>​ we need more examples
 +
 +[12:52:05] <​temporalfox>​ yes
 +
 +[12:52:11] <​purplefox>​ more examples of the clients
 +
 +[12:52:14] <​purplefox>​ and various other things
 +
 +[12:52:15] <​temporalfox>​ simple data
 +
 +[12:52:18] <​purplefox>​ and end to end stuff
 +
 +[12:52:33] <​temporalfox>​ I think arnaud is porting vtoons
 +
 +[12:52:45] <​purplefox>​ aesteve: ^
 +
 +[12:52:46] <​aesteve>​ actually not porting vtoons
 +
 +[12:52:49] <​aesteve>​ https://​github.com/​aesteve/​vertx-feeds
 +
 +[12:53:07] <​aesteve>​ it's more complicated,​ it involves redis / mongo and worker verticles
 +
 +[12:53:20] <​temporalfox>​ it's end-to-end-to-end
 +
 +[12:54:03] <​aesteve>​ i had trouble to find an example that's actually interesting and useful and doesn'​t involve alot of stuff
 +
 +[12:54:18] <​aesteve>​ maybe it's not a good approach to have so many things into one single example
 +
 +[12:54:21] <​aesteve>​ idk :\
 +
 +[12:55:14] <​temporalfox>​ purplefox the build needs some work
 +
 +[12:55:16] <​aesteve>​ this one is good 'cause you have an actual example of what you can use worker verticles for : reading RSS feeds periodically
 +
 +[12:55:58] <​purplefox>​ aesteve: what does feedbroker do?
 +
 +[12:56:23] <​aesteve>​ reads RSS feeds (or maybe other stuff if you have a good idea) periodically
 +
 +[12:56:40] <​purplefox>​ why does it need to be a worker?
 +
 +[12:56:56] <​aesteve>​ I wanted to use a blocking API (Rome) at first
 +
 +[12:57:28] <​aesteve>​ but then I realized I didn't provide a vertx.createClient example
 +
 +[12:57:41] <​aesteve>​ if I use Rome => it's a worker
 +
 +[12:58:03] <​aesteve>​ if I want to provide an example of createClient and asynchronous stuff => it's no longer a worker
 +
 +[12:58:23] <​aesteve>​ it's a matter of choice of what is the most important to showcase
 +
 +[12:59:13] <​purplefox>​ i see you're also creating a non shared mongo client and passing it into the verticles...
 +
 +[12:59:19] <​purplefox>​ that doesn'​t seem right to me
 +
 +[12:59:46] <​purplefox>​ the point of the shared client stuff is so you don't have to do this
 +
 +[13:01:34] <​purplefox>​ but generally looks good :)
 +
 +[13:01:54] <​purplefox>​ i would still like to see a simple web example with, say, an angularjs front end though
 +
 +[13:02:03] <​purplefox>​ like the vtoons
 +
 +[13:02:28] <​purplefox>​ temporalfox:​ ok julien, i think we're done
 +
 +[13:02:44] <​temporalfox>​ purplefox ok cool ^^
 +
 +[13:02:45] <​purplefox>​ next thing is to split up who is doing what
 +
 +[13:02:51] <​purplefox>​ we can do this after lunch
 +
 +[13:02:57] <​temporalfox>​ ok perfect
 +
 +[13:03:03] <​temporalfox>​ I'm starving :-)
 +
 +[13:05:16] <​purplefox>​ AlexLehm: hi alex, do you have a few minutes to chat?
 +
 +[13:05:30] <​aesteve>​ ok purplefox that's the first time I'm working with Mongo, I'm not expecting to do it right in the first shot :)
 +
 +[13:05:43] <​AlexLehm>​ yes sure
 +
 +[13:05:46] <​aesteve>​ I'll open an issue so that I don't forget about your advice
 +
 +[13:05:50] <​purplefox>​ aesteve: so basically you don't need to pass in the mongo client instance
 +
 +[13:05:58] <​purplefox>​ aesteve: just do createShared from wherever you need it
 +
 +[13:06:21] <​purplefox>​ AlexLehm: great... so we were just discussing what remains to be done for V3
 +
 +[13:06:36] <​purplefox>​ AlexLehm: one of the main outstanding areas is the mail client
 +
 +[13:07:07] <​purplefox>​ did you have a chance to work on the fixes we discussed last week?
 +
 +[13:07:19] <​AlexLehm>​ I started on the todo list on the weekend
 +
 +[13:07:55] <​AlexLehm>​ i fixed the pool tests to actually assert something
 +
 +[13:08:09] <​AlexLehm>​ i started the connection pool tests
 +
 +[13:08:23] <​AlexLehm>​ sunday evening, i didn't get around to commiting that
 +
 +[13:08:27] <​purplefox>​ cool, which branch are you working in?
 +
 +[13:08:51] <​AlexLehm>​ i created a new wip branch, but I didn't push the changes last evening
 +
 +[13:09:05] <​purplefox>​ ok np. can you just push it now?
 +
 +[13:09:06] <​AlexLehm>​ i can do it this evening
 +
 +[13:09:20] <​AlexLehm>​ ah, I'm at the office so I don't have access to my machine
 +
 +[13:09:33] <​purplefox>​ alright, no problem
 +
 +[13:09:46] <​AlexLehm>​ I could ask my gf to push the changes though (I know shes at home since shes using the computer)
 +
 +[13:10:04] <​purplefox>​ we can wait until this evening. no problem
 +
 +[13:10:07] <​AlexLehm>​ ok
 +
 +[13:12:23] <​AlexLehm>​ i meant to ask you about the merge operation I did on Saturday, I'm not sure if I that wrong, but I think I merged the changes from the PR into a new branch and then checked that and merged it into master
 +
 +[13:12:50] <​AlexLehm>​ or did you want the change to be merged into a new wip branch?
 +
 +[13:13:32] <​purplefox>​ i was a bit confused about what was happening there
 +
 +[13:13:44] <​purplefox>​ i expected that branch to be merged directly into master
 +
 +[13:13:48] <​purplefox>​ but you created a new one, not sure why
 +
 +[13:13:51] <​AlexLehm>​ ah ok
 +
 +[13:14:20] <​purplefox>​ to be honest I don't really understand what you did, but the end result was it got into master
 +
 +[13:14:41] <​AlexLehm>​ basically I did the following
 +
 +[13:14:59] <​AlexLehm>​ close the pr with a comment to merge it with a new branch
 +
 +[13:15:20] <​AlexLehm>​ create a branch wip based on the current master, merge the changes from the refactorings branch
 +
 +[13:15:29] <​AlexLehm>​ revise that a small bit and merge it into master
 +
 +[13:15:47] <​purplefox>​ why not just merge the refactorings straight into the wip?
 +
 +[13:15:57] <​purplefox>​ then you wouldn'​t need a new branch
 +
 +[13:16:09] <​purplefox>​ after all the PR was based against the wip branch anyway
 +
 +[13:16:26] <​AlexLehm>​ the wip was the old one that was merged into master before by you, I don't think you can merge that agin
 +
 +[13:16:27] <​AlexLehm>​ again
 +
 +[13:16:38] <​AlexLehm>​ I may be wrong with that though
 +
 +[13:16:52] <​purplefox>​ i thought you were working on WIP?
 +
 +[13:17:07] <​purplefox>​ wip hadn't been merged into master
 +
 +[13:17:14] <​AlexLehm>​ the old one yes
 +
 +[13:17:22] <​purplefox>​ you have more than one branch called wip?
 +
 +[13:17:44] <​AlexLehm>​ no, i have deleted the old wip branch after the merge and created a new one based on master
 +
 +[13:17:53] <​AlexLehm>​ and then i merged that and delete the branch
 +
 +[13:17:55] <​purplefox>​ right, so you were working on that branch
 +
 +[13:18:08] <​purplefox>​ which is why i based the pr "​refactorings"​ on wip
 +
 +[13:18:13] <​purplefox>​ and not on master
 +
 +[13:18:21] <​AlexLehm>​ but you merged it before I think
 +
 +[13:18:34] <​purplefox>​ it doesn'​t matter
 +
 +[13:19:11] <​AlexLehm>​ the changes you made in the refactorings branch are now in master, I hope that is ok
 +
 +[13:19:48] <​purplefox>​ we got there in the end... but next time, after a review the best thing to do is is to add a note "​finished review"​ or whatever
 +
 +[13:19:58] <​purplefox>​ not just merge directly
 +
 +[13:20:09] <​purplefox>​ this is what julien and i do all the time
 +
 +[13:21:16] <​AlexLehm>​ ok, sorry that i got that wrong
 +
 +[13:21:32] <​purplefox>​ yes so workflow is basically this:
 +
 +[13:21:45] <​purplefox>​ 1. someone does some work and submits a PR
 +
 +[13:21:51] <​purplefox>​ 2. other people get asked to review it
 +
 +[13:22:01] <​purplefox>​ 3. when review is complete, the changes can be merged.
 +
 +[13:22:21] <​purplefox>​ so in this case i asked you and julien to review it
 +
 +[13:22:57] <​purplefox>​ so if you're happy just say "looks good to me" or something
 +
 +[13:24:20] <​AlexLehm>​ ok
 +
 +[13:26:23] <​purplefox>​ then once you said "​ok"​
 +
 +[13:26:33] <​purplefox>​ i would then see if julien thinks its ok too.
 +
 +[13:26:50] <​purplefox>​ then if he is ok, i would merge the refactorings branch into the wip branch
 +
 +[13:27:05] <​purplefox>​ (by clicking the merge button on github)
 +
 +[13:27:15] <​purplefox>​ then we just have your branch to merge
 +
 +[13:27:28] <​purplefox>​ so then next thing, you'd submit a PR of your changes (wip) against master
 +
 +[13:27:42] <​purplefox>​ and then you'd say "hey guys can you please review this?"
 +
 +[13:27:58] <​purplefox>​ and then we'd review any further changes you'd done in your WIP branch
 +
 +[13:28:04] <​purplefox>​ and if ok, you'd then merge that into master
 +
 +[13:28:12] <​purplefox>​ that's basically how it's supposed to work ;)(
 +
 +[13:28:42] <​AlexLehm>​ ok, i will do that in the future
 +
 +[13:34:15] <​AlexLehm>​ ok, i will go online again in the evening
 +
 +[13:35:04] <​purplefox>​ thanks alex
 +
 +[13:36:34] <​aesteve>​ since I had some time during lunch : https://​github.com/​aesteve/​vertx-feeds/​commit/​9a1a7d0b1568192ec87dc88e51f3c8b64ac4cb57
 +
 +[13:36:43] <​aesteve>​ I guess that's what you had in mind purplefox ?
 +
 +[13:37:15] <​AlexLehm>​ you discussed project names for apex before, if you consider Sherpa (which is kind of good I think), you could call it either Tenzing or Norgay, that was the Sherpa of Edmund Hillary on his first ascent of Mt. Everest
 +
 +[13:37:57] <​AlexLehm>​ who was usually called Sherpa Tenzing
 +
 +[13:38:46] <​aesteve>​ I quite like sherpa actually, but not sure it's good as a project name (collision with a common name ?) idk
 +
 +[13:39:08] <​aesteve>​ but the idea behind the name it is cool
 +
 +[14:44:37] <​saltuk>​ hi  can some1  help me  logic of something like  http://​codepaste.net/​si872f
 +
 +[15:09:32] <​D-Spair>​ saltuk: ​ Wrong Vertex... This channel is about the Vert.x tool-kit.
 +
 +[15:10:06] <​D-Spair>​ saltuk: ​ NVM, I see what's happening there.
 +
 +[15:10:49] <​purplefox>​ temporal_: hi julien, one thing we forgot to discuss is metrics
 +
 +[15:10:54] <​D-Spair>​ saltuk: ​ First off, you want your class to extend "​AbstractVerticle"​ so that all of the Vert.x setup  is done for you..
 +
 +[15:10:58] <​temporal_>​ purplefox indeed
 +
 +[15:11:56] <​purplefox>​ one sec, my irc client is screwing up. going to reboot it....
 +
 +[15:14:44] <​purplefox>​ temporal_: ok back now
 +
 +[15:14:52] <​purplefox>​ temporal_: we didn't discuss metrics
 +
 +[15:15:33] <​purplefox>​ temporal_: is there anything outstanding on that?
 +
 +[15:15:40] <​temporal_>​ purplefox not for the moment
 +
 +[15:15:59] <​temporal_>​ purplefox I believe it would need a proper reimplementation for an spi consumer
 +
 +[15:16:10] <​temporal_>​ purplefox and more thought
 +
 +[15:16:23] <​temporal_>​ and I think we said that we will provide something more appropriate later
 +
 +[15:16:45] <​temporal_>​ concerning the SPI, I think it's quite ok now beside the thread checks
 +
 +[15:16:57] <​purplefox>​ can you elaborate on that a bit? "​proper reimplementation for an spi consumer"​
 +
 +[15:17:15] <​temporal_>​ codahale is for local in VM implementation
 +
 +[15:17:30] <​temporal_>​ Thomas Segismont is contributing an hawkular implementation
 +
 +[15:17:55] <​temporal_>​ with codahale
 +
 +[15:18:01] <​temporal_>​ metrics are not persisted
 +
 +[15:18:10] <​temporal_>​ and on a cluster you cannot get a global view of the system
 +
 +[15:18:34] <​temporal_>​ I started to work a bit on an HdrHistogram implementation
 +
 +[15:18:51] <​temporal_>​ that would scale better than codahale
 +
 +[15:18:59] <​purplefox>​ ok but this is just a different implementation,​ no>
 +
 +[15:19:01] <​temporal_>​ yes
 +
 +[15:19:10] <​temporal_>​ so with the curent implementation I think we are good
 +
 +[15:19:26] <​temporal_>​ and we need to revisit / improve that after 3.0
 +
 +[15:19:31] <​purplefox>​ ok
 +
 +[15:19:51] <​temporal_>​ concerning the SPI itself, I think it can be improved in some part
 +
 +[15:19:57] <​temporal_>​ mainly the deployment callback
 +
 +[15:20:04] <​temporal_>​ lifecycle of deployed verticles
 +
 +[15:20:12] <​temporal_>​ to provide more info about what is deployed
 +
 +[15:20:26] <​temporal_>​ and perhaps the verticle deployment hierarchy
 +
 +[15:20:32] <​D-Spair>​ saltuk: ​ Why do you want to create a new context to run on?
 +
 +[15:20:53] <​temporal_>​ so bottom line beside what I mentionned for the threads, I think we are good for now
 +
 +[15:20:56] <​D-Spair>​ saltuk: ​ Is there some operation requirement for that? You need a separate context to make something work?
 +
 +[15:21:11] <​temporal_>​ purplefox one area we need to spend time is the build
 +
 +[15:21:41] <​temporal_>​ purplefox have doc generation play better with multimodule project
 +
 +[15:22:24] <​temporal_>​ purplefox some modules cannot execute tests if the module is not the cwd
 +
 +[15:27:11] <​D-Spair>​ saltuk: ​ Have a look at: http://​codepaste.net/​innfms
 +
 +[15:39:20] <​D-Spair>​ purplefox: temporal_: I Assume that something like a DatabaseManager object for OrientDB would be "​difficult"​ to add to the clustered context, right?
 +
 +[15:39:50] <​D-Spair>​ Since it is connection oriented, it would have to be instantiated separately on each node of a cluster, right?
 +
 +[15:56:39] <​saltuk>​ D-Spair, thanx for the info . ;)
 +
 +[20:08:57] <​jtruelove>​ apex question, where do I supply a no route found error handler globally? I don't see that interface on the Router object itself. The docs seem to indicate that it's possible. I don't see it on the HttpServer object either. I want to emulate the old '​noMatch'​ functionality. I see you can supply one on one off Route objects but that seems like it would only
 +
 +[20:08:57] <​jtruelove>​ apply to that Route vs anything coming in that didn't anything at all.
 +
 +[20:18:33] <​jtruelove>​ purplefox: ^
 +
 +[20:20:39] <​purplefox>​ jtruelove: you should just be able to supply a failureHandler that matches all routes:
 +
 +[20:20:46] <​purplefox>​ router.route().failureHandler(myHandler);​
 +
 +[20:20:55] <​jtruelove>​ heh yeah just found that
 +
 +[20:21:47] <​jtruelove>​ thanks, what happens if you call route() multiple times? I'm guessing nothing
 +
 +[20:22:33] <​purplefox>​ you can create as many routes as you want, any matching ones will be called in the order you created them
 +
 +[20:23:14] <​jtruelove>​ right but if you call route() multiple times on the same Router it would all map to the same thing right?
 +
 +[20:23:25] <​jtruelove>​ unless you modified after you created it of coruse
 +
 +[20:23:32] <​purplefox>​ not sure what you mean
 +
 +[20:23:49] <​purplefox>​ when a request comes in
 +
 +[20:23:57] <​jtruelove>​ you call router.route() multiple times on the same Router object
 +
 +[20:24:27] <​purplefox>​ yes, you can call router.route() multiple times, most apps will do this
 +
 +[20:24:28] <​jtruelove>​ you'd end up with multiple routes at that point all matching everything
 +
 +[20:24:37] <​purplefox>​ yes, that's fine
 +
 +[20:25:27] <​purplefox>​ when a request comes in, apex finds the first matching route out of all the routes
 +
 +[20:25:36] <​purplefox>​ then it calls the handler for that
 +
 +[20:25:54] <​purplefox>​ and then, if you call context.next() in your handler, then it calls the next matching route (if any)
 +
 +[20:25:56] <​purplefox>​ etc
 +
 +[20:26:05] <​jtruelove>​ right
 +
 +[20:26:09] <​purplefox>​ so you can have as many matching routes as you want. and it's pretty common to have many
 +
 +[20:26:41] <​jtruelove>​ yeah i can see that, was just thinking about the match '​all'​ route
 +
 +[20:28:25] <​purplefox>​ another way of doing it, is to do a router.route() and set a normal handler, not a failureHandler
 +
 +[20:28:43] <​purplefox>​ but you'll need to add this as the *last* route, or it will be called for every request
 +
 +[20:29:35] <​purplefox>​ jtruelove: ok sorry jeremy i have to shoot off now. but any more issues I'll be around tomorrow :)
 +
 +[20:29:36] <​purplefox>​ cheers
 +
 +[21:16:53] <​jtruelove>​ np, I got what I need :D
 +
 +[21:47:26] <​jtruelove>​ is there a standard way that fatjars are done in gradle with vertx3?
 +
 +[23:11:30] <​AlexLehm>​ temporal_, can async object only be completed once? I had two complete calls on the same object due to a cut'​n'​paste mistake. maybe it would be good to give a warning about that
 +
 +[23:11:50] <​temporal_>​ I believe they can be completed once but I need to check
 +
 +[23:12:14] <​temporal_>​ I agree a warn would allow to detect bad practice
 +
 +[23:26:03] <​AlexLehm>​ i can write an issue if you like
 +
 +[23:59:27] <​Ephemeral>​ stahp making copy pasta :(