Differences

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

Link to this comparison view

irc:1463695200 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[08:25:02] *** ChanServ sets mode: +o temporal_
 +
 +[14:59:35] <​kuwv>​ Hello, anyone can help me learn Handlers better?
 +
 +[15:01:23] <​kuwv>​ I'm trying to understand how to use AsyncResult.
 +
 +[15:15:59] <​cescoffier>​ Hi kuwv
 +
 +[15:16:33] <​cescoffier>​ to create an Async Result you use Future.successfulResult of Future.failedResult
 +
 +[15:16:52] <​cescoffier>​ I can't remember exactly the method name
 +
 +[15:17:00] <​kuwv>​ Hmmn...
 +
 +[15:17:23] <​kuwv>​ I've been looking at a lot of examples and they are all different.
 +
 +[15:18:27] <​kuwv>​ esultHandler.handle(Future.successfulResult
 +
 +[15:18:42] <​kuwv>​ Similar to this ^^^
 +
 +[15:19:01] <​kuwv>​ *Sorry for the sloppy copying.
 +
 +[16:01:09] <​cescoffier>​ yes, this is how to invoke a handler with a success result
 +
 +[16:01:59] <​kuwv>​ Ok, I saw an example where a lamba was used to catch the asyncresult.
 +
 +[16:02:47] <​kuwv>​ Is this the best way to work with asyncresult?​
 +
 +[16:20:36] <​kuwv>​ cescoffier: I'm trying to run the vertx-microservices-workshop and I'm getting this error: http://​pastebin.com/​vd3hT2tw
 +
 +[16:20:55] <​cescoffier>​ yes, the API has changed
 +
 +[16:21:01] <​cescoffier>​ I need to update the workshop
 +
 +[16:21:06] <​cescoffier>​ should be done soonish
 +
 +[16:21:19] <​cescoffier>​ (give me a couple of minutes)
 +
 +[16:32:57] <​kuwv>​ ok
 +
 +[16:40:03] <​kuwv>​ I'm using docker from epel. Should I try the upsteam first?
 +
 +[16:43:23] <​kuwv>​ Ok, same effect.
 +
 +[16:43:35] <​cescoffier>​ kuwv : done
 +
 +[16:43:41] <​kuwv>​ cool
 +
 +[16:43:52] <​cescoffier>​ so, if you update the code of the workshop
 +
 +[16:43:56] <​cescoffier>​ it should work again
 +
 +[16:44:13] <​kuwv>​ ok, I'll do that now.
 +
 +[16:45:30] <​kuwv>​ Success
 +
 +[16:45:37] <​kuwv>​ Thanks
 +
 +[16:55:03] <​kuwv>​ cescoffier: Will python be available in vert.x 3.x.x? What happened with it?
 +
 +[17:17:52] <​ChicagoJohn>​ How do you go about converting things like HttpClientOptions to json?
 +
 +[17:18:27] <​ChicagoJohn>​ i see that you have a HttpClientOptionsConverter,​ but that doesnt call any of the HttpClientOptions'​ super methods.
 +
 +[17:19:12] <​ChicagoJohn>​ following that, I can pass in a Jsonobject to create HttpClientOptions but i cant figure out how to convert from object to Json
 +
 +[17:19:40] <​ChicagoJohn>​ or is this like a google-group kind of question/​write up?
 +
 +[17:28:32] <​kuwv>​ ChicagoJohn:​ Vert.x uses Jackson. You can use the Jackson library or just "​import io.vertx.core.json.JsonObject;"​ and do a "​JsonObject jsonObj = new JsonObject(Json.encode(object));"​ i believe.
 +
 +[17:30:20] <​ChicagoJohn>​ bless you
 +
 +[17:30:29] <​kuwv>​ np
 +
 +[18:06:42] <​ChicagoJohn>​ where do we post issues or comments with the library? ​ google groups correct? ​ is that like the defacto place to post?
 +
 +[18:12:50] <​kuwv>​ The maintainers prefer Google groups.
 +
 +[18:13:02] <​ChicagoJohn>​ also, not all of the vertx code base has sources attached. ​ bummer
 +
 +[18:13:08] <​ChicagoJohn>​ cool.  i will post a write up
 +
 +[18:27:09] <​AlexLehm>​ ChicagoJohn:​ the options objects should have a .toJson() method
 +
 +[18:29:34] <​AlexLehm>​ ok, i take that back, some of the options objects have a toJson method
 +
 +[18:31:17] <​ChicagoJohn>​ ;)
 +
 +[18:36:17] <​AlexLehm>​ temporal_: I have implemented a SOCKS5 server for testing a few days ago, I am probably able to commit the socks code this evening or maybe tomorrow
 +
 +[18:43:41] <​AlexLehm>​ needs some more tests though
 +
 +[18:48:15] <​temporal_>​ AlexLehm ok, I will see if we can integrate it or not
 +
 +[18:48:19] <​temporal_>​ AlexLehm release is approaching
 +
 +[18:48:40] <​temporal_>​ how does it change config ?
 +
 +[18:49:33] <​AlexLehm>​ i have introduced a ProxyOptions class that can be set for HttpClient and NetClient
 +
 +[18:49:48] <​temporal_>​ ok
 +
 +[18:50:04] <​temporal_>​ I'm thinking it should have something like a proxy class or something
 +
 +[18:50:30] <​temporal_>​ does it reuse the ChannelProvider thing ?
 +
 +[18:50:42] <​temporal_>​ one thing could be ProxyOptions defines the ChannelProvider
 +
 +[18:51:15] <​temporal_>​ so one can reuse another ProxyOptions impl with somehting else than SOCKS or CONNECT
 +
 +[18:51:21] <​temporal_>​ I don't know if it makes sense or not
 +
 +[18:51:47] <​temporal_>​ and on TCPSSLOptions we do have something like
 +
 +[18:51:51] <​temporal_>​ for client
 +
 +[18:52:01] <​temporal_>​ setSocks5ProxyOptions
 +
 +[18:52:03] <​temporal_>​ and
 +
 +[18:52:08] <​temporal_>​ setHttpProxyOptions
 +
 +[18:52:15] <​temporal_>​ so it can be used in polyglot
 +
 +[18:52:21] <​temporal_>​ does it make sense to you ?
 +
 +[18:54:47] <​AlexLehm>​ it uses the ChannelProvider,​ I have changed it a bit to work without using the HttpOptions or NetClient Options
 +
 +[18:55:02] <​temporal_>​ yes sure
 +
 +[18:55:06] <​AlexLehm>​ the ProxyOptions include a ProxyType field, with an Enum
 +
 +[18:55:14] <​AlexLehm>​ this supports SOCKS4, SOCKS5 and HTTP
 +
 +[18:55:19] <​AlexLehm>​ with one option
 +
 +[18:55:22] <​temporal_>​ ok
 +
 +[18:55:36] <​AlexLehm>​ that should work with the other languages, haven'​t tried that yet
 +
 +[18:55:39] <​temporal_>​ have all these optiosn the same fields ?
 +
 +[18:55:42] <​temporal_>​ yes it should
 +
 +[18:55:52] <​temporal_>​ or do you have unused fields ?
 +
 +[18:56:01] <​temporal_>​ in some
 +
 +[18:56:11] <​temporal_>​ but it looks fine from here
 +
 +[18:56:14] <​AlexLehm>​ yes the options are the same
 +
 +[18:56:19] <​AlexLehm>​ host, port, username, password
 +
 +[18:56:30] <​temporal_>​ one proxy options is one which class ?
 +
 +[18:56:43] <​temporal_>​ ClientOptionsBase ?
 +
 +[18:56:58] <​AlexLehm>​ I have put that into HttpClientOptions and NetClientOptions
 +
 +[18:57:02] <​temporal_>​ why not ClientOptionsBase ?
 +
 +[18:57:16] <​AlexLehm>​ haven'​t considered that,I have to admit
 +
 +[18:57:22] <​AlexLehm>​ i can change that i think
 +
 +[18:57:51] <​temporal_>​ don't forget to override the self return type in HttpClientOptions / NetClientOptions
 +
 +[18:58:04] <​temporal_>​ btw
 +
 +[18:58:25] <​temporal_>​ do you mind reviewing this PR ? https://​github.com/​eclipse/​vert.x/​pull/​1424
 +
 +[18:59:40] <​AlexLehm>​ ok sure
 +
 +[19:01:23] <​temporal_>​ thanks
 +
 +[19:01:32] <​temporal_>​ looking forward to see your PR too
 +
 +[20:04:44] <​ChicagoJohn>​ this is unrelated to vertx but related to dev in general. ​ do you write integration tests or do you only stick to unit tests?
 +
 +[20:11:24] <​namrood>​ ChicagoJohn you do both, and yes this is not the right channel for those questions
 +
 +[20:12:35] <​ChicagoJohn>​ thanks. ​ i got some good input on another channel i am in.
 +
 +[21:18:03] <​AlexLehm>​ temporal_: https://​github.com/​alexlehm/​vert.x/​tree/​issues/​%23101-socks45-support
 +
 +[21:38:05] <​tcrawley>​ pmlopes: have you looked at merging https://​github.com/​vert-x3/​vertx-tcp-eventbus-bridge/​pull/​8?​
 +
 +[21:38:59] <​tcrawley>​ I'm building a tcp bridge client in swift, and noticed that headers on a send don't make it across the bridge, and it looks like that pr fixes it
 +
 +[22:44:53] <​temporal_>​ tcrawley-away you probably should an email on vertx-dev for this
 +
 +[23:24:27] *** ChanServ sets mode: +o temporalfox