[00:28:26] *** ChanServ sets mode: +o temporal_

[10:39:02] <aesteve> hi temporal_ , cescoffier . Are you planning a conf / workshop for Paris Web ?

[10:39:16] <temporal_> no I don't

[10:39:20] <cescoffier> aesteve : Hi, no. Nothing planned.

[10:41:55] <cescoffier> Paris Web is very web no ?

[10:42:24] <aesteve> I had never heard about it before this morning actually, that's why I was wondering

[10:44:12] <aesteve> I'm currently looking at previous years' confs

[10:45:55] <aesteve> yes it looks very front-end oriented

[10:46:05] <cescoffier> I already sent people there a couple of years ago (in a previous life). From what I remember it's about usability, css, frontend technologies…

[10:46:50] <cescoffier> maybe with this universal app trend, there will be a bit more backend stuff this year, but even with this, vert.x is not providing anything for universal app (you have to build it yourself)

[10:47:58] <aesteve> https://github.com/aschrijver/vertx-react-example

[10:48:22] <aesteve> I didn't have the time to give it a look yet, but why not !

[10:49:31] <cescoffier> that's more about how to use react with vert.x

[10:49:38] <aesteve> that : https://github.com/aschrijver/vertx-react-example/blob/master/src/main/java/org/example/MainVerticle.java#L63 sounds blocking ?

[10:50:31] <temporal_> guys any feedback on vertx-unit ?

[10:50:41] <aesteve> yes but that's a first step. Once you can render react components within a template handler, you just have to play with html placeholders to re-execute the same code on client-side

[10:52:05] <aesteve> the real issue with universal rendering is ajax, some people actually use the exact same code they's use within the client's browser to render the pages (meaning XMLHttpRequest to a distant server)

[10:52:28] <aesteve> that'll never be possible with Nashorn, and that's (imo) a poor design

[10:53:36] <cescoffier> temporal_ : didn't have the time yet

[10:53:42] <cescoffier> temporal_ probably not next week

[10:53:53] <aesteve> temporal_: I haven't played with it, I just read the docs yesterday

[10:53:59] <temporal_> ok

[10:54:17] <temporal_> so the tcnative boringssl uber jar has not yet been released

[10:54:24] <temporal_> on wonder why it never worked

[10:54:26] <temporal_> no wonder

[10:54:45] <temporal_> it seems that the classifier detection with the maven build extension works in Intellij IDE

[10:55:20] <aesteve> actually temporal_ is there another way to read the docs than : https://github.com/vert-x3/vertx-unit/pull/33/files

[10:55:38] <temporal_> and if you have Asciidoctor.js in Chrome plugin

[10:55:43] <temporal_> you can read the file natively

[10:57:04] <temporal_> I'm surprised it works in intellij

[10:57:21] <temporal_> cescoffier do you think that intellij runs the maven build extension to figure out the classifier value ?

[10:57:26] <aesteve> this one ? https://chrome.google.com/webstore/detail/asciidoctorjs-live-previe

[10:57:59] <temporal_> aesteve yes

[10:58:10] <temporal_> when I do “show effective pom” in intellij it showws indeed

[10:58:10] <temporal_> <tcnative.classifier>osx-x86_64</tcnative.classifier>

[10:58:13] <cescoffier> temporal_ : probably not, maven support is getting worse… I don't thing they would do that

[10:58:14] <aesteve> ok thanks

[10:58:22] <temporal_> but it works

[10:58:24] <temporal_> so…

[10:58:44] <cescoffier> try on eclipse, and see….

[10:58:48] <temporal_> yes…

[10:58:55] <temporal_> which plugin should I used on eclipse ?

[10:58:59] <cescoffier> m2e

[10:59:02] <cescoffier> always the same

[10:59:04] <temporal_> ok

[10:59:17] <temporal_> I will give a try

[10:59:31] <temporal_> I hope they will release tcnative boring ssl uber jar soon

[11:32:28] <aesteve> temporal_: doc seems pretty clear to understand

[11:32:47] <aesteve> I'll try to use it in Nubes this afternoon so that it's a real-life usage

[11:33:40] <aesteve> I'm even wondering if : vertx.exceptionHandler(testContext.exceptionHandler());

[11:33:40] <aesteve> shouldn't be set as default

[11:43:42] <temporal_> we can't do that as default

[11:43:47] <temporal_> as we don't control vertx

[11:43:55] <temporal_> and I think it's quite simple to do

[11:44:04] <temporal_> and gives control / responsiblity to user

[11:44:04] <temporal_> (i.e no magic thing)

[11:44:19] <temporal_> you may have a vertx instance that don't need this default in your test

[11:46:31] <aesteve> if we can' we can't :( but my point was : this is probably the bahaviour most users will except : “if an exception occurs during my test execution : that's not expected unless I explicitely mentionned it”, see what I mean ?

[11:49:20] <AlexLehm> temporal_: i have commited the unit test for the proxy code, should I do a new pr for that?

[11:49:22] <AlexLehm> https://github.com/alexlehm/vert.x/tree/issues/%231361-add_unit_test

[11:49:54] <temporal_> yes please do a pr

[11:52:21] <AlexLehm> https://github.com/eclipse/vert.x/pull/1413

[11:53:35] <temporal_> thanks!

[12:07:18] <AlexLehm> what is estimated date for the 3.3.0 milestone? github currently has 1 may 2017

[13:07:10] <aesteve> https://github.com/vert-x3/wiki/wiki/3.3.0-Breaking-Changes you should add JwtAuthHandler.create no longer works with a simple AuthHandler, it's expecting a JWTAuthHandler

[13:07:12] <temporal_> AlexLehm we are aiming at 3.3.0 in June - it highly depends on Eclipse CQ and Netty 4.1.0.Final release date

[13:07:18] <aesteve> this is a major change for me

[13:07:25] <temporal_> aesteve can you make an issue or PR for this ?

[13:07:45] <aesteve> I think I can't update the wiki, or I didn't find how to

[13:34:26] <aesteve> temporal_: after upgrading to 3.3.0-SNAPSHOT I've a few weird errors happening on my CI server and not locally

[13:34:46] <temporal_> aesteve what are thse ?

[13:34:54] <aesteve> java.lang.IllegalStateException: Uh oh! Event loop context executing with wrong thread! Expected null got Thread[Test worker,5,main]

[13:34:54] <aesteve> at io.vertx.core.impl.ContextImpl.lambda$wrapTask$3(ContextImpl.java:343)

[13:34:54] <aesteve> at io.vertx.core.impl.ContextImpl.executeFromIO(ContextImpl.java:240)

[13:34:54] <aesteve> at io.vertx.core.http.impl.ConnectionManager$ConnQueue.http1xConnected(ConnectionManager.java:422)

[13:35:43] <temporal_> do you have a reproducer ?

[13:36:04] <aesteve> here for instance : https://github.com/aesteve/nubes/blob/master/src/test/java/integration/params/QueryParametersTest.java#L17

[13:36:19] <temporal_> do you have full stack trace ?

[13:36:26] <aesteve> yeah sure

[13:37:16] <aesteve> https://gist.github.com/aesteve/73811921c0f302c53df21ac4720a1d11

[13:38:04] <temporal_> looking at it

[13:38:13] <aesteve> weird, it doesn't happen at all locally

[13:39:02] <aesteve> (but actually I think I shouldn't create a new httpclient for each test and close the httpclient after each test)

[13:39:28] <aesteve> but if my bad practices can help debugging…

[13:39:55] <temporal_> so this does not happen locally ?

[13:39:57] <temporal_> or does it ?

[13:40:48] <aesteve> it doesnt, at all

[13:41:02] <aesteve> same stuff, “./gradlew test”

[13:41:20] <aesteve> the difference is here : mybook air, CI : AWS t2.micro

[13:41:49] <aesteve> (neither “gradlew test” nor in IntelliJ on my machine)

[13:42:12] <temporal_> the problem seems to be related to Async dns resolution

[13:42:37] <temporal_> I can push something in a branch

[13:42:41] <temporal_> and you can test it from that server ?

[13:43:45] <temporal_> I understand why it happens

[13:43:48] <temporal_> now

[13:44:25] <temporal_> and effectively CI is slower

[13:44:40] <temporal_> and it's not suprising that this happens

[13:45:46] <aesteve> cool

[13:46:05] <aesteve> let me know what I can do to help

[13:46:13] <temporal_> you can test something when I have a fix

[13:46:15] <temporal_> hopefully soon

[13:46:24] <aesteve> no problem, just tell me

[13:46:57] <aesteve> I'll install maven + checkout your branch locally on CI server & install it

[13:49:22] <temporal_> thanks

[13:49:27] <temporal_> what is your CI ?

[13:49:29] <temporal_> jenkns ?

[13:49:31] <aesteve> yep

[13:49:40] <temporal_> you run it yhourself ?

[13:50:14] <aesteve> yes

[13:50:30] <aesteve> I wanted to give “raw” AWS a try

[13:51:29] <temporal_> ok

[14:17:51] <temporal_> almost got something

[14:19:53] <temporal_> I will push a change in a branch

[14:19:57] <temporal_> so you can try

[14:20:05] <temporal_> and after I'll try to make a reproducer case

[14:20:13] <temporal_> so it can be tested

[14:26:09] <temporal_> aesteve can you try this ? https://github.com/eclipse/vert.x/tree/bind-connect-helper-listener-fix

[14:27:20] <temporal_> I need to go out for a little while, let me know how it goes, I think it should solve it

[14:29:24] <aesteve> ok I'll give it a try :)

[16:00:32] <temporal_> aesteve is there an improvement ?

[16:01:01] <aesteve> no I'm struggling because the user jenkins has no access to the maven repo (I guess)

[16:06:11] <aesteve> ok now it finds vert.x-core in mavenLocal()

[16:06:30] <aesteve> I think I can add back SNAPSHOTS for other artifacts resolution

[16:07:08] <aesteve> sorry I'm playing with Elm in the meantime :P

[16:12:59] <aesteve> it's working temporal_ yeah !

[16:13:08] <temporal_> cool

[16:13:15] <temporal_> I'm going to add some test and merge this in master

[16:13:37] <aesteve> but I still think I should refactor to use a single httpClient forEach test, it's a poor design I'm using

[16:15:49] <temporal_> the main problem I think is rather that the client could reuse a stale connection between tests

[16:15:54] <temporal_> stale pooled

[16:17:25] <aesteve> I'll let things as is, time for you to create the test, merge the branch and push it as a snapshot

[16:17:42] <aesteve> then I'll retry without mavenLocal() so you can be sure everything's working fine

[16:17:49] <aesteve> then I'll change my implementation :)

[16:23:13] <temporal_> ok

[16:23:16] <temporal_> should not be long

[16:25:05] <temporal_> I merged the change with the test

[16:26:14] <aesteve> ok I'll remove m2 repo

[16:30:28] <temporal_> thanks for the feedback

[16:30:58] <temporal_> that's cool you can find such issues and we fix them before 3.3

[16:31:26] <aesteve> say thanks to Amazon !

[16:32:17] <aesteve> Actually I'm planning Nubes 2.0 release to match Vert.x 3.3.0 so I have to prepare the field

[16:33:15] <aesteve> I've so many things to do, I'd like to re-work authentication completely, maybe include the “typesafe” config stuff I did last week too

[16:33:53] <aesteve> and the Spring Boot conf inspired me alot, too. There's a lot of opinionated stuff that helps alot