Differences

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

Link to this comparison view

irc:1435528800 [2017/05/27 13:44] (current)
Line 1: Line 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 http://​vertx.io/​blog/​blog.html - 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: http://​mrhaki.blogspot.nl/​search/​label/​Groovy%3AGoodness 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 : https://​github.com/​aesteve/​vertx-nubes/​blob/​master/​src/​main/​java/​com/​github/​aesteve/​vertx/​nubes/​utils/​async/​AsyncUtils.java
 +
 +[11:22:51] <​cescoffier>​ but you can already start writting posts: https://​github.com/​vert-x3/​vertx-web-site/​tree/​web-site-3.0.0#​the-blog
 +
 +[11:23:31] <​cescoffier>​ purplefox_: we have an ATOM feed (http://​vertx.io/​feed.xml)
 +
 +[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 : https://​github.com/​aesteve/​scorepong/​blob/​master/​src/​main/​java/​com/​github/​aesteve/​scorepong/​controllers/​MatchApi.java ​ https://​github.com/​aesteve/​scorepong/​blob/​master/​src/​main/​java/​com/​github/​aesteve/​scorepong/​controllers/​Socket.java
 +
 +[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 : https://​github.com/​aesteve/​vertx-feeds ​  ​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>​ http://​vertx.io/​feed.xml
 +
 +[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 jboss.org and eclipse.org
 +
 +[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>​ http://​vertx.io/​docs/​vertx-core/​js/​
 +
 +[13:07:10] <​temporalfox>​ links to "​http://​vertx.io/​docs/​vertx-core/​cheatsheet/​VertxOptions.html"​
 +
 +[13:07:18] <​temporalfox>​ there http://​vertx.io/​docs/​vertx-core/​js/#​_specifying_options_when_creating_a_vertx_object
 +
 +[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 https://​groups.google.com/​forum/#​!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_>​ http://​vertx.io/​docs/​vertx-web/​java/#​_handling_event_bus_bridge_events
 +
 +[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 http://​vertx.io/​docs/​apidocs/​io/​vertx/​core/​net/​PemTrustOptions.html
 +
 +[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?