Differences

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

Link to this comparison view

irc:1443477600 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[00:25:13] *** ChanServ sets mode: +o purplefox
 +
 +[01:53:53] *** ChanServ sets mode: +o purplefox
 +
 +[07:22:07] <​voidDotClass>​ what's the latest version on maven?
 +
 +[09:01:37] *** ChanServ sets mode: +o purplefox
 +
 +[09:11:53] <amr> i think i know the answer to this, but do message codecs work on fields on other objects?
 +
 +[09:12:14] <amr> i.e. i have a pojo with a JsonObject, will the JsonObject messagecodec get triggered?
 +
 +[09:12:17] <amr> i expect/​suspect not
 +
 +[10:07:08] *** ChanServ sets mode: +o purplefox
 +
 +[10:13:56] <amr> hmm, going from jsonobject -> string using Json.encode() is straightforward,​ going the other way using Json.decodeValue and then calling new JsonObject() is a bit fiddly
 +
 +[10:14:08] <amr> any reason readValue can't just inflate the JsonObject rdirectly?
 +
 +[10:14:47] *** ChanServ sets mode: +o purplefox
 +
 +[10:15:39] <​pmlopes>​ amr you can also do new JsonObject(String jsonString)
 +
 +[10:29:59] <amr> yeah, i was just playing with using Json as a general purpose object mapper so i can pass around pojos
 +
 +[10:30:25] <amr> as i thought itd have (de)serializers for jsonobjects
 +
 +[10:31:01] <amr> serialising works as id expect, but not deserialising
 +
 +[10:31:23] <amr> suppose i shouls really just make things properly typed instead of relying on jsonobject
 +
 +[11:46:30] <​cescoffier>​ pmlopes: I've an issue with bower on windows. It looks it can't resolve the amd module (don't have much details). It's when you run the vertx-web client example
 +
 +[11:46:39] <​cescoffier>​ any hint you can give me ?
 +
 +[11:47:35] <​pmlopes>​ is that with the 3.0.0-1? or just the latest git?
 +
 +[11:54:49] <​purplefox>​ cescoffier: clement, is the new launcher stuff currently active in vertx-core master?
 +
 +[11:57:39] <​cescoffier>​ purplefox: yes, except the redeploy
 +
 +[11:57:43] <​cescoffier>​ I'm going to open the PR today
 +
 +[11:58:28] <​purplefox>​ cescoffier: i have an possible issue with -ha
 +
 +[11:58:48] <​purplefox>​ cescoffier: it seems that if i specify -ha at the command line using a fatjar the verticle doesn'​t get deployed
 +
 +[11:59:09] <​cescoffier>​ run -ha ? or just -ha ?
 +
 +[12:01:00] <​cescoffier>​ but it might be a regression
 +
 +[12:01:15] <​cescoffier>​ java -jar my-fat-jar -ha should launch the jar in ha mode right ?
 +
 +[12:01:50] <​cescoffier>​ (and deploy it)
 +
 +[12:02:47] <​purplefox>​ ah forget it.. .the user is using an old vert.x version :(
 +
 +[12:02:52] <​purplefox>​ sorry for the noise
 +
 +[12:03:02] <​cescoffier>​ no problem
 +
 +[12:03:52] <​cescoffier>​ I ran all the previous test with the launcher to detect regression, it's not exhaustive, so we may have some.
 +
 +[12:04:11] <​cescoffier>​ BTW, I've ran all test (except vertx-web) on windows this morning
 +
 +[12:04:16] <​cescoffier>​ everything fine (on 3.1)
 +
 +[13:31:57] *** ChanServ sets mode: +o temporalfox
 +
 +[14:28:26] <amr> how unique does a message codec'​s systemCodecID need to be?
 +
 +[14:31:49] <amr> i have a generic-y message codec that i add per class i use for messages (~5/6)
 +
 +[14:32:04] <amr> but it's one implementation... so defining the systemCodecId isnt terribly easy
 +
 +[14:34:16] <amr> oh, set it to -1, interesting
 +
 +[14:34:55] <amr> i need to rtfsc
 +
 +[15:43:41] <​Sticky>​ is there for a given message a way to turn off the no handlers exception?
 +
 +[16:16:41] <​purplefox>​ cescoffier: pmlopes: temporalfox:​ would anyone like to look at a potential clustering bug? I think this would be good practice for someone to get up to speed with core / clustering :)
 +
 +[16:17:04] <​temporalfox>​ @purplefox I can spend time on this
 +
 +[16:17:16] <​purplefox>​ cool
 +
 +[16:17:47] <​purplefox>​ temporalfox:​ here's the issue: https://​github.com/​vert-x3/​vertx-hazelcast/​issues/​13
 +
 +[16:18:05] <​purplefox>​ it's a race condition and only occurs if the kill to both nodes happens concurrently
 +
 +[16:18:11] <​purplefox>​ it could be a bug in hazelcast
 +
 +[16:18:14] <​temporalfox>​ ok
 +
 +[16:18:17] <​temporalfox>​ sounds fun
 +
 +[16:18:25] <​purplefox>​ i had a quick look, but i'm not 100% sure
 +
 +[16:18:33] <​purplefox>​ yes a lot of fun ;)
 +
 +[16:18:41] <​temporalfox>​ how do you investigate this ?
 +
 +[16:18:45] <​temporalfox>​ with hazelcast logging ?
 +
 +[16:18:47] <​temporalfox>​ wireshark ?
 +
 +[16:19:02] <​temporalfox>​ system.out.println ?
 +
 +[16:19:06] <​temporalfox>​ a bit of everything :-) ?
 +
 +[16:19:27] <​purplefox>​ first i would reproduce the issue then add logging in the vert.x code (vertx-core and vertx-hazelcast) to see what is going on
 +
 +[16:19:35] <​temporalfox>​ ok
 +
 +[16:19:45] <​temporalfox>​ I'll let you know my progress
 +
 +[16:19:57] <​purplefox>​ thanks. if you need any help ping me
 +
 +[16:20:26] <​temporalfox>​ sure
 +
 +[20:57:53] <​pulse00>​ hi all. can anyone recommend any examplex for vertx-web form validation and binding?
 +
 +[20:58:38] <​Sticky>​ not sure if any of the examples do validation
 +
 +[20:59:33] <​pulse00>​ are complex forms a thing vertx-web would be a good candidate for? or do you think something like play or grails is better suited for that in the jvm ?
 +
 +[21:03:22] <​Sticky>​ so it really depends on what you are out for I think, from my breif play with grails, like most of those style tools you get a lot out of the box very quick, but as soon as you want to do something a bit uniq/​outside their idomatic way it gets painful fast
 +
 +[21:04:32] <​Sticky>​ vertx by comparison does not really provide you THAT much out of the box, but does not really dictate how to write/​structure your app so much
 +
 +[21:08:34] <​pulse00>​ yeah, i have the same view on that. so i'm basically looking for something less opinionated (it seems vertx is designed that way). the only thing i really think should be handled by he web-layer is form-binding and validation, where i'd rather not reinvent the weel.
 +
 +[21:08:53] <​Sticky>​ also since with vertx there is less magic going on behind the scenes, some problems I have with those frameworks is that since they hide much of the detail of how the app is working from you, diagnosing issues when things go wrong becomes a nightmare
 +
 +[21:10:04] <​Sticky>​ so form binding is easy enough, since your form should make a post request, so you will get a JsonObject server side with your data
 +
 +[21:10:19] <​Sticky>​ however validation afaik, is up to you
 +
 +[21:10:43] <​Sticky>​ having said that I havent used vertx-web that much so there could be something in there
 +
 +[21:11:20] <​pulse00>​ i've stumbled upon this here https://​github.com/​pmlopes/​yoke which seems to have some abstractions for forms
 +
 +[21:11:57] <​Sticky>​ oh yeah that, is that vertx 3?
 +
 +[21:12:40] <​pulse00>​ meh, doesn'​t look like https://​github.com/​pmlopes/​yoke/​blob/​develop/​pom.xml#​L112