Approvals: 0/1
[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