This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[11:13:34] <purplefox_> cescoffier: temporalfox pmlopes morning guys

[11:13:45] <cescoffier> good morning purplefox_

[11:13:58] <purplefox_> did you have a good weekend?

[11:14:23] <cescoffier> was attending a marriage, so yes pretty good

[11:14:37] <purplefox_> excellent

[11:15:19] <dpes> cescoffier: bride din't run away? ;) … my wife was trying to…

[11:15:29] <cescoffier> :-) nope

[11:15:42] <pmlopes> good morning

[11:15:50] <purplefox_> morning paulo

[11:16:00] <purplefox_> how is amsterdam today?

[11:16:33] <pmlopes> that is a coincidence i also had attended a marriage and today it is sunny in amsterdam, we are having a hit wave the end of the week so the temperature will rise to almost 35C

[11:17:17] <cescoffier> pmlopes: yes, the heat start here too

[11:17:23] <cescoffier> 35 today, 41 friday

[11:17:33] <purplefox_> that's hot, i think it is also going to be quite hot here this week, maybe 27 degrees (which is pretty hot for around here)

[11:17:56] <purplefox_> west of england is usually a bit cooler than london area. i think london is going to go 30+

[11:18:07] <purplefox_> 41 ouch

[11:18:29] <cescoffier> yes, 41 is going to be a nightmare

[11:18:50] <purplefox_> 41 dry is bearable its when its humid its unbearable

[11:19:10] <cescoffier> BTW, pushing the blog (non public, just to show you)

[11:19:35] <cescoffier> so prepare your posts ;-)

[11:19:39] <purplefox_> cool

[11:19:49] <aesteve> hello everyone !

[11:19:56] <purplefox_> aesteve: hello arnaud

[11:19:58] <aesteve> oh the blog is coming !!! cool :)

[11:20:40] <purplefox_> aesteve: btw i agree with your post about running/debugging vert.x - i think the current docs could be improved in this area. in particular we have duplciate sections on running vert.x from command line which is confusing

[11:20:47] <purplefox_> i think things need moving around a bit

[11:21:04] <cescoffier> purplefox_ : here it is - it's abviously an example ;-)

[11:21:09] <aesteve> I think I might have some ideas for bogs posts actually, the question on vertx-dev on JSPromises etc. inspired me

[11:21:50] <cescoffier> purplefox_: just need to tweak the CSS

[11:21:59] <purplefox_> cescoffier: cool, are blog posts written in markdown?

[11:22:19] <pmlopes> cescoffier, purplefox_ i was thinking we could start a blog in the style of: small posts showing how one can do stuff with vert.x

[11:22:25] <aesteve> I started to identify some patterns I'm writing quite often in Vert.x apps :

[11:22:51] <cescoffier> but you can already start writting posts:

[11:23:31] <cescoffier> purplefox_: we have an ATOM feed (

[11:23:55] <cescoffier> (with some bug actually ;-))

[11:24:18] <purplefox_> aesteve: great, I would like to encourage community to blog there. I think if we all do blog posts by submitting PRs then that works well

[11:24:51] <purplefox_> pmlopes: +1

[11:24:55] <aesteve> pmlopes: this blog is very good indeed, wehn googling for a Groovy question, it comes up very often

[11:25:32] <aesteve> purplefox_: another idea would be answering random questions

[11:25:39] <purplefox_> cescoffier: i wonder if we can add a github hook to trigger a mvn site-deploy if a blog PR is accepted? (or something like that)

[11:25:45] <purplefox_> just a thought

[11:25:53] <purplefox_> it would save a manual rebuild

[11:25:54] <aesteve> like “What happens when you 'bind' a worker verticle to the event bus ?”

[11:26:17] <cescoffier> purplefox_yes it's possible, we just need a token to publish the web site

[11:27:03] <purplefox_> aesteve: +1

[11:28:09] <cescoffier> Gonna write one to show how to create a init.d scripts (as it seems to be requested)

[11:28:30] <cescoffier> once we have the first post, I will add the link in the header (actually, uncomment it)

[11:28:41] <cescoffier> and remove the current post (just here as an example)

[11:29:33] <aesteve> btw I created a first app using my annotation framework on top of Vert.x this weekend.

[11:29:51] <aesteve> looks like this :

[11:30:42] <purplefox_> aesteve: cool, make sure you add a link to your framework to the vertx-awesome list :)

[11:30:55] <purplefox_> cescoffier: also you should add wisdom (in V2) if it's not already there

[11:31:06] <aesteve> I'll try to, I'd like to give QBit a try, since I think both are somehow similar

[11:31:32] <cescoffier> purplefox_: definitely, will do that today

[11:31:33] <purplefox_> yeah, qbit looks interesting but i think it's v2 only right now, but rick plans to port it to v3

[11:32:54] <aesteve> I wanted to ask for a long time : does any of you guys have plan to write a “Vert.x in Action” book ? (i mentionned it in the Google Group)

[11:33:04] <aesteve> the Manning collection is really awesome

[11:33:09] <purplefox_> yep, julien plans to do this (maybe)

[11:33:20] <dpes> I have one simple question… want to start with actor prog model… simple scenario: http router which passes to redis verticle and then returns httpresponse

[11:33:27] <purplefox_> maybe i will write the forward or something, but writing a book is a big effort

[11:33:34] <dpes> is there some similar examples?

[11:34:02] <purplefox_> dpes: for v3?

[11:34:11] <dpes> yes

[11:34:23] <dpes> purplefox_: v3 js

[11:34:35] <dpes> but java also will do

[11:34:55] <purplefox_> for a v3 webapp that uses redis, i'd usually recommend just accessing the client directly from your web verticle

[11:35:53] <purplefox_> if you're not sharing your redis outside the vert.x instance putting the redis part in its own verticle doesn't necessarily buy you anything

[11:36:55] <dpes> those modules would be quite big… and want to try divide them in some way and use event bus

[11:37:17] <aesteve> dpes: if you're following what purplefox_ says, take a look here : that's how I dealt with Redis

[11:37:51] <dpes> cool

[11:37:56] <dpes> that's what i need

[11:37:57] <aesteve> (note purplefox_ this is exactly the question I mentionned on the Google Group : how to design your app : verticle or not ?)

[11:38:12] <purplefox_> dpes: sure, i wouldn't expect you to put everything in one file

[11:38:25] <purplefox_> but you could still have (say) multiple commonJS modules

[11:38:32] <purplefox_> put only one verticle

[11:39:05] <aesteve> when you're designing a webapp the first question will be that : “Is the Verticle the unit I need to separate my logic ?”

[11:39:06] <dpes> oh, ok

[11:39:18] <purplefox_> the verticle is the _deployment unit_, you can still structure your code in modular ways

[11:39:37] <aesteve> in fact no, it's not, it's just like Canada Dry, it looks like it is, but it's not

[11:39:44] <purplefox_> aesteve: good question. i would say the verticle is a deployment unit, not a unit for modularising your code

[11:39:57] <purplefox_> they're two different things, and people often confuse them

[11:40:10] <aesteve> yes I figured that out when you switched the Redis/JDBC/Mongo as clients

[11:40:29] <purplefox_> yeah verticles are all about deployment and scaling

[11:40:36] <dpes> thanks guys for clarifying

[11:41:03] <aesteve> the good question (I think) to ask to answer this is “Does my service exist (means) on its own ?”

[11:41:09] <aesteve> if yes : it should probably be a Verticle

[11:41:19] <dpes> and thanks for framework… it sth i was waiting for years…

[11:41:32] <aesteve> if no : it should be a good old dependency in your Verticle

[11:41:36] <purplefox_> dpes: cool, glad you are enjoying it :)

[11:41:57] <purplefox_> aesteve: you should consider submitting your feeds app to the examples repo, or if not, at least adding it to the vertx-awesome list

[11:42:06] <aesteve> done ;)

[11:42:26] <aesteve> but for the examples repo I'm afraid it's not codetrans/codegen friendly

[11:42:44] <aesteve> (and I have to integrate the MongoAuthService, still)

[11:47:01] <aesteve> purplefox_: before I submit SSE to vertx-web, could you tell me : do I need to rewrite my tests using plain vertx-web or is it OK to have vertx-unit as a vertx-web test-dependency ?

[11:49:30] <purplefox_> aesteve: i think for consistency right now vertx-web tests should all work similarly, but maybe we port them to vertx-unit in the future

[11:50:20] <aesteve> OK I'll rewrite them, that was worth the try :p

[12:08:50] <cescoffier> purplefox_ temporalfox pmlopes : so blog engine ready (fixed the Atom feed link issue) - let's write posts !

[12:09:08] <temporalfox> cescoffier cool

[12:09:20] <cescoffier> (remember that they need to be in the web-site-3.0.0 branch and merged into master)

[12:09:22] <temporalfox> I'll blog about vertx-shell maybe today :-)

[12:09:29] <cescoffier> Yes, great idea !

[12:09:44] <cescoffier> let me know if you want additional stuff

[12:10:20] <cescoffier> temporalfox - I tried to integrate gist, but the metalsmith gist integration is not great…. so may re-implement something myself

[12:10:27] <temporalfox> ok

[12:13:04] <cescoffier> (you need to list the gist in the post metadata and then use them, and even with that, code highlighting does not work well)

[12:13:40] <temporalfox> couldn't we just display gists using some iframe or something like that and let github display the colored gist?

[12:13:45] <temporalfox> I mean

[12:13:50] <temporalfox> couldn't metalsmith :-)

[12:21:36] <purplefox_> cescoffier: does the blog provide an RSS feed?

[12:23:12] <cescoffier> yes

[12:23:24] <cescoffier>

[12:23:45] <cescoffier> so, aggregator can read the blog

[12:27:14] <purplefox_> cescoffier: blog looks great :) Are we going to link it from the main menu bar on the front page?

[12:27:39] <cescoffier> purplefox_ yes - just waiting the first real post

[12:27:46] <purplefox_> cool

[12:27:59] <purplefox_> well feel free to post a helloworld post if you wish :)

[12:28:05] <cescoffier> Links are already created just as comment right now

[12:28:16] <purplefox_> then we can get it aggregated on and

[12:28:23] <cescoffier> yep

[12:28:29] <cescoffier> will write something this afternoon

[12:28:51] <cescoffier> so for sure tonight, we will have an official blog

[12:31:29] <purplefox_> brb

[12:43:23] <dpes> one maybe silly thing… but when 2→3 You dropped python support… (which I understand fully) but are You guys planning mark some languages “won't disapear for sure” ?

[12:43:49] <dpes> like java, js maybe?

[13:04:27] <purplefox_> temporalfox: are the options cheatsheets linked from the docs anywhere? I tried to find it from the Java manual page, but couldn't find any link

[13:04:35] <purplefox_> (HttpClientOptions)

[13:04:51] <temporalfox> we don't have a “directory” per se

[13:05:11] <temporalfox> something that list them all

[13:05:27] <temporalfox> they are linked from other languages

[13:05:32] <temporalfox> because in java, the class exist

[13:05:38] <temporalfox> but not in Groovy / Ruby or JS

[13:06:14] <purplefox_> where are they linked from in JS? I couldn't find them there either

[13:06:21] <temporalfox> from the doc itself

[13:06:36] <temporalfox> from an {@link}

[13:06:52] <purplefox_> i searched for httpclientoptions in the js doc and couldn't find anything

[13:06:57] <temporalfox> for instance

[13:06:58] <temporalfox>

[13:07:10] <temporalfox> links to “

[13:07:18] <temporalfox> there

[13:07:54] <purplefox_> ok i guess HttpClientOptions is just missing

[13:09:02] <temporalfox> it would be good to generate some kind of “listing”

[13:09:08] <temporalfox> perahps the JS website can do that

[13:09:29] <temporalfox> find all directoty named “cheatsheet” in docs directory

[13:09:37] <temporalfox> and then link each cheatsheet

[13:10:18] <purplefox_> yeah

[13:17:39] <purplefox_> pmlopes: cescoffier temporalfox: not very exciting i'm afraid but one thing we need to do soon is a maintenance release for Vert.x 2.x to fix some outstanding issues

[13:17:50] <temporalfox> purplefox_ ok

[13:18:00] <temporalfox> what do we have on the plate :-) ?

[13:18:06] <purplefox_> I'm going to take a look today to see what 2.x issues there are

[13:18:20] <purplefox_> hazelcast upgrade and clustering fixes is the main one

[13:18:31] <purplefox_> but there are probably other issues too

[13:18:48] <purplefox_> so this will be bugfix only, no new features in 2.x

[13:20:30] <temporalfox> I think it's the good timing to do that

[13:24:17] <pmlopes> ok

[14:23:13] <yanndegat> hi

[14:23:25] <yanndegat> is anyone has any info of a clojure support for vertx3.

[14:23:27] <yanndegat> ?

[14:37:15] <tcrawley> yanndegat: there currently isn't any clojure support for v3 - see!searchin/clojure/vert.x/clojure/mq_DHkHSDpw/RVF9MLmeGB0J

[14:37:30] <yanndegat> tcrawley: thanks

[14:37:47] <tcrawley> my pleasure!

[14:40:06] <purplefox_> yanndegat: but we're looking for volunteers if you would like to implement it :)

[14:40:42] <yanndegat> purplefox_: ;) alright, maybe i'd could give it a try someday

[14:40:44] <purplefox_> +1 to tobys post

[14:41:12] <yanndegat> purplefox_: but cannot give any kind of commitment

[14:41:17] <yanndegat> purplefox_: yet

[14:41:24] <purplefox_> ok, np

[14:41:32] <yanndegat> purplefox_: i'm having a new job starting next week

[14:41:50] <yanndegat> purplefox_: where we are defining the stack

[14:42:25] <yanndegat> purplefox_: was wondering if vertx 3 could be a great place to start, even if a little immature though

[14:42:53] <yanndegat> purplefox_: in fact i would have loved to build something on mongrel2

[14:43:08] <yanndegat> purplefox_: but it's far too dead to be reasonnable

[14:43:19] <yanndegat> purplefox_: vertx seems to be a good compromise

[14:43:23] <purplefox_> well vert.x 3 is the most mature Vert.x ever :)

[14:43:42] <purplefox_> why do you think vert.x is “immature”? I am curious ;)

[14:44:04] <yanndegat> purplefox_: i mean vertx3, as it's a brand new refactoring

[14:44:10] <yanndegat> opposed to vertx2

[14:44:18] <yanndegat> am i wrong ?

[14:44:24] <purplefox_> no it's not completely new

[14:44:34] <purplefox_> much of the code is the same

[14:44:48] <yanndegat> ok, so, good to know

[14:45:02] <purplefox_> i'd say v3 is more mature and less buggy than v2, although of course there maybe new bugs in the new code, but we have very good test coverage

[14:45:10] <yanndegat> alright

[14:45:12] <purplefox_> and there are certainly completely new bits such as vertx-web

[14:45:20] <yanndegat> i've seen this

[14:46:18] <yanndegat> yet i would have liked to built something based on the lib0mq

[14:47:13] <yanndegat> how deep can we interact with the vertx event bus through zeromq ?

[14:47:44] <aesteve> purplefox_: I was wondering : why isn't it possible to register many SocketHandlers on a socket or many MessageHandlers ? There must be a reason but can't find why

[14:48:33] <purplefox_> yanndegat: sorry, I've never used zeromq

[14:48:38] <yanndegat> ok

[14:49:20] <purplefox_> aesteve: what kind of sockets are you referring to?

[14:49:27] <aesteve> sockjs for example

[14:49:46] <purplefox_> so you're talking about the handler() on a SockJSSOcket?

[14:49:55] <aesteve> absolutely, yes

[14:50:45] <purplefox_> why would it be useful to have more than one handler?

[14:51:00] <purplefox_> i mean.. a socket reads a buffer, and then you pass that to the handler…

[14:51:09] <purplefox_> more than one handler doesn't make sense to me

[14:51:18] <aesteve> 1. I guess it could be possible to separate logic this way (even though I'm not convinced, but “maybe”)

[14:51:24] <aesteve> 2. the event bus bridge

[14:51:48] <aesteve> you bridge it but kinda “loose control” on the connectHandler, endHandler

[14:51:54] <tcrawley> b

[14:51:57] <purplefox_> not sure i follow…

[14:51:59] <tcrawley> err, wrong window :)

[14:52:40] <aesteve> you bridge a socket on the eventbus bridge, and want to keep track of the connected sockets (idk, maybe count them, or do whatever you want)

[14:52:47] <aesteve> how would you achieve that ?

[14:53:23] <purplefox_> you can use event bus bridge events

[14:54:33] <aesteve> you actually thought to everything didn't you ? :p nice feature

[14:54:47] <purplefox_>

[14:54:51] <purplefox_> lol

[14:55:25] <aesteve> yes I never scrolled down under the security stuff

[14:55:44] <aesteve> that's really cool, that covers my use case

[14:57:05] <aesteve> for point 1. I've never faced this, but I thought maybe it could be interesting to kinda share/describe socket message handlers abit like mixins

[14:57:20] <aesteve> but let's wait until someone actually has a real-life issue with this

[14:58:35] <aesteve> sockJS1.handler(logMsgHandler).handler(checkSomethingHandler); sockjs2.handler(checkSomethingHandler)

[14:58:53] <aesteve> but maybe it just doesn't make sense

[15:02:48] <purplefox_> aesteve: btw i haven't forgetten that email you sent me, i will reply at some point :)

[15:03:22] <purplefox_> but what I would say… I am not too worried because our target audience is not really node.js developers

[15:06:29] <aesteve> I think so, too

[15:07:15] <aesteve> I'm still looking for a way to connect both worlds in a very straightforward way

[15:08:44] <aesteve> node handles some very nice features like Typescript / ES6 transpilers and stuff like that, that would be really interesting to have in Vert.x for example

[15:09:39] <aesteve> maybe a NodeWorkerVerticle could be a solution, you would proxy it over the eventbus and just invoke node stuff the easy way

[19:58:11] <temporalfox> there is no closeHandler in SockJSSocket, is that expected or did we forget it ?

[20:08:55] <cristianmiranda> Hi guys, just wanted to know if you see something strange with this query. Not working on vertx 3.0

[20:08:57] <cristianmiranda> query.put(“orderCloseTime”, new JsonObject().put(“$gte”, dateTime.toDateTimeISO().toString()));

[20:09:35] <cristianmiranda> I'm using io.vertx.core.json.JsonObject to query in my mongoDB

[21:11:00] <aesteve> temporalfox: hello :) it's “endHandler”, not closeHandler I think

[21:11:14] <temporalfox> yes I saw that but wasn't sure

[21:11:22] <temporalfox> it is documented ?

[21:11:33] <aesteve> idk, but I'm pretty sure it's working

[21:11:40] <temporalfox> ok

[21:11:46] <AlexLehm> Can I use assert in the vertx modules? I would like to improve the tests a bit if possible

[21:12:10] <temporalfox> what do you mean ?

[21:16:39] <AlexLehm> I would like to add some statements like assert(vertx.getCurrentContext == context) on the methods that use the context and then run the unit tests with enable asserts

[21:17:09] <temporalfox> that would work if vertx unit can “catch” this assertion

[21:17:33] <temporalfox> perhaps that you can make a JUnit rule for that ?

[21:18:11] <AlexLehm> I think i have to put the asserts into the main code, not the test code

[21:18:14] <temporalfox> also keep in mind that running assert means having the JVM to have specific option

[21:18:18] <temporalfox> yes I understand now

[21:18:41] <temporalfox> the question is there a plugable way to be aware of these failures

[21:18:47] <temporalfox> it's a JVM thing

[21:19:01] <AlexLehm> at least it should show up as unhandled exception in the log

[21:19:08] <temporalfox> one possiblity would be to instrument bytecode :-)

[21:19:23] <temporalfox> AlexLehm yes then it's not realted to vertx unit

[21:19:57] <aesteve> In JUnit4 the exception (actually Error) thrown by a JUnit assert is the same as the error thrown by the java assert keyword (AssertionError), so it is exactly the same as assertTrue and other than the stack trace you couldn't tell the difference.

[21:20:00] <aesteve> I found this

[21:20:23] <aesteve> so Junit should deal with it perfectly ?

[21:21:10] <AlexLehm> junit handles assert failures correctly I think

[21:21:25] <AlexLehm> maybe i should just try it out

[21:21:27] <aesteve> so the only question is “are you allowed to do it” ?

[21:21:53] <aesteve> yes a simple test should show you how the failure is handled by JUnit

[21:22:19] <jtruelove> if i want a server to be able to client authenticate would I set the client cert via

[21:22:37] <jtruelove> the client cert is in PEM format etc..

[21:24:16] <jtruelove> also do i set the client cert via the PemKeyCertOptions on the HttpClient?

[21:26:20] <AlexLehm> temporalfox, can i merge small doc changes myself? without review

[21:27:34] <temporalfox> in what ?

[21:27:47] <temporalfox> ah I see the ocmmit

[21:27:49] <AlexLehm> in mail-client

[21:27:52] <temporalfox> I think yes

[21:27:55] <AlexLehm> (the only repo I am writer)

[21:28:01] <temporalfox> sounds reasonable

[21:28:07] <AlexLehm> ok thanks

[21:29:16] <AlexLehm> ok, forgot to generate the docs before commiting

[22:17:12] <rajith> purplefox_: still there ?

[22:18:58] <jtruelove> anyone can confirm the above?