Differences

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

Link to this comparison view

— irc:1432591200 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[09:46:12] <Huntter> Hi guys, I want to build the vert.x 3 example project, but seems the artifacts are not house in the maven central, where can I get the artifacts?
 +
 +[09:47:13] <temporalfox> Huntter so either yo ucan use a tag
 +
 +[09:47:18] <temporalfox> of vertx examples
 +
 +[09:47:36] <temporalfox> or use https://oss.sonatype.org/content/repositories/snapshots/
 +
 +[09:47:42] <temporalfox> the sonatype snapshot repo
 +
 +[09:48:08] <Huntter> what I can find in maven central is vertx3 perview 1
 +
 +[09:49:00] <Huntter> Cool, there is the 3.0.0-SNAPSHOT thanks in advance
 +
 +[10:07:31] <cescoffier> the easiest I would say is to use the following dependency:
 +
 +[10:07:32] <cescoffier> <dependencies>
 +
 +[10:07:32] <cescoffier>   <dependency>
 +
 +[10:07:33] <cescoffier>     <groupId>io.vertx</groupId>
 +
 +[10:07:33] <cescoffier>     <artifactId>vertx-stack-depchain</artifactId>
 +
 +[10:07:33] <cescoffier>     <version>${vertx.version}</version>
 +
 +[10:07:33] <cescoffier>     <type>pom</type>
 +
 +[10:07:33] <cescoffier>   </dependency>
 +
 +[10:07:33] <cescoffier> </dependencies>
 +
 +[10:07:49] <cescoffier> with ${vertx.version} set to 3.0.0-SNAPSHOT
 +
 +[10:19:45] <Huntter> <repositories>     <repository>       <id>oss</id>       <url>https://oss.sonatype.org/content/repositories/snapshots</url>     </repository>   </repositories>
 +
 +[10:19:53] <Huntter> I added this to the root pom.xml and it works
 +
 +[10:20:03] <pmlopes> @purplefox are you available?
 +
 +[11:13:11] <purplefox> temporalfox: cescoffier pmlopes : good morning!
 +
 +[11:13:27] <cescoffier> morning !
 +
 +[11:13:43] <purplefox> cescoffier: and welcome :)
 +
 +[11:13:51] <cescoffier> thanks !
 +
 +[11:14:14] <purplefox> it was a national holiday in the UK yesterday (and my birthday) so I wasn't around
 +
 +[11:14:22] <temporalfox> good morning all
 +
 +[11:15:13] <cescoffier> no problem, I found stuff to do ;-)
 +
 +[11:15:44] <cescoffier> I don't know if you see, I've provided new docker images (built by maven), and two examples (on compliant with fabric 8)
 +
 +[11:15:50] <cescoffier> fabric 8
 +
 +[11:16:03] <purplefox> i haven't seen yet, but that sounds great
 +
 +[11:17:44] <purplefox> cescoffier: today is going to be a pretty crazy week, as we are supposed to be doing the final milestone for Vert.x 3 by the end of the week ;)
 +
 +[11:18:02] <cescoffier> yes, julien told me.
 +
 +[11:18:09] <purplefox> but don't worry we don't expect you or paulo to do any critical stuff for this as you're still finding your feet
 +
 +[11:18:14] <cescoffier> I'm looking at the documentation right now (file system)
 +
 +[11:18:34] <cescoffier> you should get a PR before noon (paris time ;-) )
 +
 +[11:18:45] <purplefox> awesome
 +
 +[11:21:00] <purplefox> cescoffier: temporalfox pmlopes: we should probably have a little meeting to discuss our plans for the milestone a bit later on. wdyt?
 +
 +[11:21:14] <purplefox> just so we know what needs to be done, etc
 +
 +[11:21:18] <temporalfox> purplefox ok, but I have a scheduled lunch today :-)
 +
 +[11:21:54] <cescoffier> purplefox no problem for me
 +
 +[11:21:59] <purplefox> what time is your lunch appointment?
 +
 +[11:22:44] <temporalfox> I would say between 12h00 and 14h00
 +
 +[11:22:52] <pmlopes> i was looking at the auth stuff and getting it merged to vertxweb but i am not sure how to proceed since it will break the current shiro impl
 +
 +[11:22:52] <temporalfox> I meet a JUG sponsor
 +
 +[11:23:01] <temporalfox> and it's not close to home
 +
 +[11:23:02] <purplefox> and now it is 11:22 for you?
 +
 +[11:23:07] <temporalfox> yes
 +
 +[11:23:46] <purplefox> could we do a quick irc meeting at 11:45 for 15 mins?
 +
 +[11:23:51] <purplefox> i don't think will take long
 +
 +[11:23:53] <temporalfox> yes
 +
 +[11:24:21] <purplefox> great. then we can do a proper meeting next week (on videoconf) after the mileston. i think this week is going to be just too hectic
 +
 +[11:24:51] <temporalfox> shaving yaks
 +
 +[11:25:19] <purplefox> as always ;)
 +
 +[11:30:15] <cescoffier> :-)
 +
 +[11:36:56] <purplefox> temporalfox: cescoffier is paulo around this morning?
 +
 +[11:37:19] <temporalfox> pmlopes seems here but perhaps we don't have his attention yet
 +
 +[11:37:34] <pmlopes> i am here
 +
 +[11:38:05] <pmlopes> just multitasking alot :)
 +
 +[11:38:25] <purplefox> :)
 +
 +[11:38:37] <pmlopes> top
 +
 +[11:38:57] <purplefox> pmlopes: one important thing we need to figure out is if we need further changes to auth or now, as this needs to be done before the end of the week
 +
 +[11:39:05] <purplefox> s/or now/or not
 +
 +[11:41:01] <pmlopes> my only concern now is to make the API clear, we currently have a clear seperation between roles and permissions, but it is not explicit if the matching is done with string equality or also allowing wildcard, also if the model is user > role > permission
 +
 +[11:41:43] <purplefox> agreed, that's not clear
 +
 +[11:42:08] <purplefox> i'm thinking that perhaps we don't enforce any particular semantics of the actual strings and just document that it is "up to the implementation"
 +
 +[11:42:16] <purplefox> so shiro can do it one way, something else can do it another way
 +
 +[11:43:17] <purplefox> ok let's leave that discussion to the end of the meeting as julien has to leave in 15 mins
 +
 +[11:43:37] <purplefox> temporalfox: pmlopes: cescoffier: ok folks let's start
 +
 +[11:43:46] <temporalfox> purplefox ok
 +
 +[11:43:52] <cescoffier> purplefox ok
 +
 +[11:44:03] <purplefox> so just a quick one
 +
 +[11:44:36] <purplefox> as you know from the roadmap we are due a final milestone before 3.0 on thursday https://github.com/vert-x3/wiki/wiki/Vert.x-Roadmap
 +
 +[11:45:01] <purplefox> the idea is most things are done by this milestone then we just tweak stuff for the final release
 +
 +[11:45:15] <temporalfox> define tweak :-)
 +
 +[11:45:31] <purplefox> tweak - some changes to docs, examples, website, maybe fix some bugs
 +
 +[11:45:44] <purplefox> but no new functionality, new components
 +
 +[11:46:04] <purplefox> no big refactorings or changes to important APIs
 +
 +[11:46:17] <purplefox> that's what I was thinking
 +
 +[11:46:29] <pmlopes> agree
 +
 +[11:46:34] <purplefox> now realistically i think thursday is only 2 days, which is not enough
 +
 +[11:46:44] <purplefox> so I'm going to suggest we push this until Monday next week
 +
 +[11:46:45] <cescoffier> what do the numbers means on the roadmap. Is it priority ?
 +
 +[11:46:52] <temporalfox> cescoffier yes
 +
 +[11:47:08] <cescoffier> Is 1 the higher priority ?
 +
 +[11:47:19] <temporalfox> cescoffier yes
 +
 +[11:47:57] <purplefox> ok so what's outstanding:
 +
 +[11:48:13] <purplefox> 1. stack changes (i.e. building the different distros)
 +
 +[11:48:47] <purplefox> 2. possible auth changes (discussing with paulo)
 +
 +[11:48:59] <purplefox> 3. clients (!?)
 +
 +[11:49:31] <temporalfox> mongo client has a PR for date support
 +
 +[11:49:44] <purplefox> right, we should do that
 +
 +[11:49:54] <purplefox> redis needs documentation, but is more or less done
 +
 +[11:50:28] <purplefox> email.... i think it is more or less there but maybe needs a little guidance
 +
 +[11:50:45] <purplefox> amqp: i think rajith is nearly there, but also needs to be looked at
 +
 +[11:50:54] <purplefox> rabbit - not sure if we have the time for this
 +
 +[11:51:03] <purplefox> so maybe delay until 3.1
 +
 +[11:51:17] <purplefox> it's not a huge issue i think if we push some of the client stuff
 +
 +[11:51:29] <purplefox> imho it's more important we have the central stuff working well
 +
 +[11:51:59] <purplefox> 4. there's also a serious hazelcast bug we are awaiting progress on. but i seem to have found a workaround
 +
 +[11:52:14] <temporalfox> speaking of bugs, I've done some bug fixes / test cases for client/server worker in vertx core
 +
 +[11:52:25] <purplefox> right, we need to implement those fixes too
 +
 +[11:52:37] <purplefox> some of the smaller bug stuff we can fix after the final milestone
 +
 +[11:52:41] <temporalfox> https://github.com/eclipse/vert.x/tree/network-worker-bugs
 +
 +[11:52:49] <temporalfox> I made 3 tests
 +
 +[11:52:50] <temporalfox> 2 fixes
 +
 +[11:52:56] <purplefox> great
 +
 +[11:53:06] <temporalfox> the last one is the big block with synchronized block
 +
 +[11:53:09] <temporalfox> that you should look :-)
 +
 +[11:53:23] <temporalfox> these bugs make the vertx core test suite fail currently
 +
 +[11:53:30] <temporalfox> sometimes
 +
 +[11:53:34] <temporalfox> depending on os
 +
 +[11:54:38] <temporalfox> there maybe other bugs, I'll keep looking after milestone6
 +
 +[11:55:14] <purplefox> ok, so let's split up the work
 +
 +[11:55:18] <purplefox> for this week
 +
 +[11:55:32] <purplefox> (sorry going so fast here... ;) )
 +
 +[11:55:55] <purplefox> julien can you complete the distro stuff, then perhaps help with some of the client stuff
 +
 +[11:56:14] <purplefox> i can do the hazelcast bug and also help with client stuff
 +
 +[11:56:30] <purplefox> and paulo and i can discuss auth changes
 +
 +[11:56:33] <temporalfox> purplefox I'm on the distro / build stuff
 +
 +[11:56:35] <purplefox> (and maybe make some changes)
 +
 +[11:56:41] <temporalfox> purplefox I'll look at the mongodb PR
 +
 +[11:57:13] <purplefox> paulo - maybe you could also take a look at the redis client, as you wrote the original version? :)
 +
 +[11:57:17] <temporalfox> clement is helping me a bit on the distro with docker
 +
 +[11:57:32] <cescoffier> I can have a look at the redis and mail
 +
 +[11:57:48] <pmlopes> sure, i can have a look
 +
 +[11:58:17] <cescoffier> for docker, if we have more stacks- we should provide an image per stack
 +
 +[11:58:27] <cescoffier> as soon as stacks are there, I can do that
 +
 +[11:58:35] <purplefox> pmlopes: basically i think it just needs a bit of documentation (not much) then it's there. and most of the docs can just say "hey look at the redis commansd docs for more info" ;)
 +
 +[11:58:56] <purplefox> cescoffier: one really useful thing for 3.0 would be to have it working on openshift too
 +
 +[11:59:09] <pmlopes> ok
 +
 +[11:59:11] <purplefox> i think it should be pretty simple, but maybe that would be one area to look at
 +
 +[11:59:18] <cescoffier> ok, I have a look
 +
 +[11:59:35] <cescoffier> as a java program or something more integrated ?
 +
 +[11:59:40] <temporalfox> cescoffier for openshift there is a plugin for Vert.x 2, but Vert.x 3 should run more or less in the java main spirit
 +
 +[11:59:58] <cescoffier> ok, no problem
 +
 +[12:00:26] <purplefox> temporalfox: right, so it might just be a case of some simple docs... to use openshift you first create your fatjar then blah, blah, blah..,.
 +
 +[12:00:48] <cescoffier> oh as fat jar[unknown:hellip] so definitely easy
 +
 +[12:00:53] <purplefox> i'll handle the mail client as there are some tricky context related stuff there
 +
 +[12:00:56] <temporalfox> purplefox and perhaps also use the docker images you're buidling :-)
 +
 +[12:01:07] <purplefox> temporalfox: +1
 +
 +[12:01:09] <temporalfox> I mean both use case are good
 +
 +[12:01:32] <cescoffier> there is some holes in the main documentation
 +
 +[12:01:43] <cescoffier> should we fix them before the RC ?
 +
 +[12:03:02] <temporalfox> purplefox you need to announce cescoffier on vertx group too :-)
 +
 +[12:03:15] <purplefox> yes will do! :)
 +
 +[12:04:13] <purplefox> cescoffier: right we need to fix those holes :) we can fix more docs stuff after RC too but the sooner the better :)
 +
 +[12:04:54] <cescoffier> ok
 +
 +[12:04:57] <purplefox> temporalfox: cescoffier pmlopes: ok folks, are we all good for now?
 +
 +[12:05:10] <cescoffier> everything fine for me
 +
 +[12:05:12] <temporalfox> all good for me, good to have new blood :-)
 +
 +[12:05:16] <purplefox> temporalfox: are you cool with delaying the milestone to next monday?
 +
 +[12:05:29] <temporalfox> yes, n/p, I need to work on the build too a bit
 +
 +[12:05:38] <purplefox> ah... btw next monday and tuesday I will be in newcastle office meetings
 +
 +[12:05:47] <temporalfox> purplefox when do you think hazelcast will be fixed ?
 +
 +[12:05:52] <temporalfox> purplefox who is supposed to do the release ?
 +
 +[12:06:00] <temporalfox> because you are :-)
 +
 +[12:06:10] <pmlopes> yes, i just need some discussion on the auth
 +
 +[12:06:38] <purplefox> hazelcast.. they are still investigating, so I don't know... but we have a workaround that seems to work, so I am not too worried for now
 +
 +[12:06:48] <purplefox> i am fairly confident it will be fixed before the final release
 +
 +[12:07:06] <temporalfox> purplefox it just that it makes the build fail when releasing :-)
 +
 +[12:07:38] <temporalfox> if neceesary we'll exclude that test for the release
 +
 +[12:07:40] <purplefox> temporalfox: do you know what doesn't build?
 +
 +[12:07:46] <purplefox> (which test)
 +
 +[12:07:56] <temporalfox> purplefox what do you mean
 +
 +[12:08:17] <purplefox> sorry, thought you said it stops the build from working.. :)
 +
 +[12:08:38] <temporalfox> purplefox I do hae a vertx-aggregator project I use for rleease
 +
 +[12:08:42] <temporalfox> that deploy all the modules
 +
 +[12:08:52] <temporalfox> and the HZ makes this whole build fail :-)
 +
 +[12:09:10] <purplefox> hmm, really? don't think that is related to that bug
 +
 +[12:09:24] <purplefox> you mean the HZ test suite doesn't work for you?
 +
 +[12:09:38] <cescoffier> for me it bocks (for ever)
 +
 +[12:09:48] <temporalfox> purplefox yes
 +
 +[12:10:06] <purplefox> ok. i'm not sure that is the same issue
 +
 +[12:10:28] <purplefox> you are running OSX right?
 +
 +[12:10:43] <purplefox> there are some multicast setup issues on OSX, iirc
 +
 +[12:10:44] <temporalfox> yes
 +
 +[12:10:56] <temporalfox> sometimes eventloop is blocked
 +
 +[12:11:30] <temporalfox> and sometimes it fails with
 +
 +[12:11:30] <temporalfox> [127.0.0.1]:5701 [dev] [3.4] All migration tasks have been completed, queues are empty.
 +
 +[12:11:31] <temporalfox> [127.0.0.1]:5702 [dev] [3.4] Address[127.0.0.1]:5702 is STARTED
 +
 +[12:11:31] <temporalfox> java.lang.AssertionError: expected:<[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33,
 +
 +[12:11:34] <temporalfox> lot of numbers
 +
 +[12:11:36] <purplefox> ok that's interestin.. can you take a copy of the stacktrace when that happens and add it is an issue on the vertx-haszelcast project?
 +
 +[12:11:41] <temporalfox> ok
 +
 +[12:11:59] <temporalfox> I do two issues
 +
 +[12:13:35] <purplefox> ok great :)
 +
 +[12:13:46] <cescoffier> it seems that the doc generator has some issues on {@code}
 +
 +[12:14:19] <temporalfox> cescoffier that's post M6 priority
 +
 +[12:14:40] <cescoffier> yes, just we should not forget
 +
 +[12:14:43] <temporalfox> I would call that polish :-)
 +
 +[12:15:06] <temporalfox> it's quite shiny though :-)
 +
 +[12:15:45] <purplefox> pmlopes: i just remembered... you don't officially start until next week.. so of course anything you do is completely voluntary, no compulsion there :)
 +
 +[12:16:57] <temporalfox> cescoffier started officially yesterday :-)
 +
 +[12:17:10] <temporalfox> so we are good with him
 +
 +[12:17:31] <cescoffier> :-)
 +
 +[12:20:52] <pmlopes> yes, that is fine, about the auth, so lets agree to document that implementations will decide on the matching either string equality or wildcard and document that.
 +
 +[12:21:33] <pmlopes> regarding the data model, should we stick to apache shiro user > role > permission (which is logical)
 +
 +[12:27:57] <purplefox> pmlopes: right so that's the main question.. we could either stick with role/permission or just use string like authority and for shiro it's prefixed with "role:" or "perm:"
 +
 +[12:28:06] <purplefox> (or suchlike)
 +
 +[12:28:58] <purplefox> i'm not sure what is better... what is your opinion on this?
 +
 +[12:32:00] <pmlopes> purplefox: spring security uses just a string (they call it authorities) but then they implement hasRole where they match against: ROLE_<someString>, so i think they realized that they miss the role/permission model and made it work with convention use of prefixes. We can make it explicit by keeping the role/permission seperation but we need now to agree that a role is a property of a user and that a permission is a property of a rol
 +
 +[12:32:03] <pmlopes> e, otherwise we end up with complex models where users can have also permissions and in that case when looking for permissions we need to look both on user and roles
 +
 +[12:32:19] <pmlopes> and if we end that doing that we need to clarify how to handle overlaps
 +
 +[12:33:25] <pmlopes> so in order to not break much of the existing code I would propose lets keep roles and permissions but make clear that a user has roles and a role has permissions, no user has permissions
 +
 +[12:34:23] <purplefox> ok that seems sensible, so this becomes more of a documetation issue for us I guess?
 +
 +[12:35:07] <pmlopes> yes and i need to adjust the jwt since the implementation treated roles and permissions as user properties instead of user > role > permission
 +
 +[12:36:17] <purplefox> ok great. i'll also give you push/pull rights on the repos so you can make small changes directly
 +
 +[12:36:31] <pmlopes> thanks!
 +
 +[12:37:20] <purplefox> np
 +
 +[12:37:23] <purplefox> that reminds me:
 +
 +[12:37:44] <purplefox> cescoffier: pmlopes: can you also look at this if you haven't already
 +
 +[12:38:02] <purplefox> https://github.com/vert-x3/wiki/wiki/Development-Process
 +
 +[12:38:45] <purplefox> TLDR; basically all changes need to be done via PR, unless they are small < 10 or 20 lines or so then you can do directly in master. everyone follows this including me and julien
 +
 +[12:39:12] <purplefox> i think ur probably already familiar with this anyway
 +
 +[13:01:32] <purplefox> cescoffier: pmlopes: i've added you both the committers list so you should have push/pull rights to most of the Vert.x official repos to make small changes. If you don't just ping me and I will sort it out :)
 +
 +[13:01:44] <pmlopes> purplefox: currently I use git-flow, it works well with the whole PR and even integrates with maven
 +
 +[13:05:16] <pmlopes> purplefox: about the PRs, we also have a cloudbees account, we could have it automatically building the the PRs and reporting a build status badge on the github page for each sub project. I currently do it at work and it quite nice since when reviewing PR i just look at the code and do not bother to see if it breaks the build
 +
 +[13:05:52] <purplefox> pmlopes: that's a good idea
 +
 +[13:06:42] <purplefox> out cloudbees ci is here https://vertx.ci.cloudbees.com/view/vert.x-3/
 +
 +[13:06:46] <purplefox> s/out/our
 +
 +[13:06:57] <cescoffier> yes, that would be great
 +
 +[13:07:11] <purplefox> i can add you as admin if you send me your cloudbees email address you use for your account
 +
 +[13:08:58] <cescoffier> BTW, for custom build, I've my own CI if we need (use it to test part of my code against non public TCK)
 +
 +[13:09:34] <purplefox> ok, cool
 +
 +[13:12:56] <purplefox> cescoffier: if you submit a PR for this page, we can get you up there on the team section too http://vert-x3.github.io/community/
 +
 +[13:13:32] <purplefox> https://github.com/vert-x3/web-site/blob/master/src/site/community/index.html
 +
 +[13:17:04] <cescoffier> ok will do
 +
 +[13:40:25] <AlexLehm> purplefox: I have done some improvements to the tests of the mail module for the connection pool and I think I fixed one thread issue
 +
 +[13:41:53] <purplefox> AlexLehm: ok great. do the tests all run through nicely now?
 +
 +[13:43:33] <purplefox> temporalfox: julien, I'm adding an @Ignore to the MetricsContextTest for now in core, as it causes the test suite to hang for me
 +
 +[13:46:32] <Narigo> cescoffier, pmlopes: Just wanted to say hi and great to see more people joining Vert.x officially :)
 +
 +[13:46:44] <AlexLehm> currently one test fails on the jenkins, which didn't fail when i run the tests locally, everything else works
 +
 +[13:47:11] <AlexLehm> it doesn't take so long anymore
 +
 +[13:48:19] <AlexLehm> maybe the test doesn't make sense after all
 +
 +[13:48:42] <purplefox> AlexLehm: in my experience when tests fail on CI but not locally it is often a timing issue, e.g. you are relying on things to complete in a certain time, and problem is CI can often be slow or subject to big pauses
 +
 +[13:49:18] <purplefox> so basically non deterministic tests, e.g. ones which rely on timing are usually a bad idea
 +
 +[13:49:30] <purplefox> e.g. you wait 250 ms and expect something to happen
 +
 +[13:51:28] <AlexLehm> i think i am doing a race between the two mail send operations and that is apparently not working everywhere
 +
 +[13:51:58] <pmlopes> purplefox my cloudbees username is pmlopes
 +
 +[13:52:35] <AlexLehm> should I remove the tests with Pool*Test?
 +
 +[13:52:56] <AlexLehm> the real ConnectionPool tests are working now
 +
 +[13:53:54] <AlexLehm> or direct ConnectionPool I should say
 +
 +[13:56:07] <purplefox> AlexLehm: what's the difference?
 +
 +[13:56:41] <cescoffier> thanks Narigo
 +
 +[13:56:54] <AlexLehm> the files called Pool*Test create a MailClient and try to test the pool and the ConnectionPool tests create a ConnectionPool and operate on the SMTPConnection
 +
 +[13:56:59] <AlexLehm> (and do not really send a mail)
 +
 +[13:58:17] <pmlopes> Narigo: thanks!
 +
 +[13:58:19] <AlexLehm> using the MailClient requires some assumptions about the operation that are not always correct I think (which I didn't realize when I started writing the tests)
 +
 +[13:59:30] <purplefox> pmlopes: i think i need your email address to add you as a user
 +
 +[13:59:44] <pmlopes> pmlopes at gmail dot com
 +
 +[14:00:25] <purplefox> pmlopes: ok, done :)
 +
 +[14:01:02] <purplefox> AlexLehm: not sure what you mean by "using the MailClient requires some assumptions about the operation that are not always correct"
 +
 +[14:01:26] <purplefox> if the tests are invalid.. the of course remove them
 +
 +[14:01:43] <purplefox> but generally i am not a fan of fine grained unit tests
 +
 +[14:03:18] <AlexLehm> ok
 +
 +[14:06:43] <AlexLehm> purplefox: i will remove the tests this evening
 +
 +[14:07:23] <purplefox> AlexLehm: ok thanks. bear in mind that the deadline is pretty close now
 +
 +[14:14:01] <AlexLehm> i am not sure if we have enough time to get this reviewed
 +
 +[14:16:15] <purplefox> AlexLehm: well it won't get reviewed unless you submit a PR ;) So.. if you think it is ready then please submit a PR. But prerequisite for this is for all the tests to pass, and Docs to be done :)
 +
 +[14:21:36] <AlexLehm> the old pr is still open, i can close the pr and create a new one
 +
 +[14:22:26] <purplefox> yes, please. I don't know when you are ready ;) as I am not psychic, so you need to signal this to me somehow
 +
 +[14:25:15] <AlexLehm> ok, will do
 +
 +[14:26:04] <AlexLehm> we need a psychic messenger service
 +
 +[14:27:15] <purplefox> lol
 +
 +[14:42:03] <rajith> temporal_: julien ?
 +
 +[14:42:21] <temporal_> rajith hello
 +
 +[14:42:42] <rajith> temporal_: good morning
 +
 +[14:42:46] <rajith> temporal_: would you know where the source docs for the following https://github.com/eclipse/vert.x/tree/master/src/main/asciidoc/java/override comes from?
 +
 +[14:43:14] <rajith> temporal_: just want to find a way to keep the docs organized as it's hard to put everything inside package-info
 +
 +[14:43:37] <temporal_> override is only for vertx core
 +
 +[14:43:53] <rajith> temporal_: :(
 +
 +[14:43:56] <temporal_> do you have thuch doc ?
 +
 +[14:43:59] <temporal_> that much
 +
 +[14:44:37] <rajith> temporal_: kind of ... I have more additions to make
 +
 +[14:45:06] <temporal_> why don't you just add it at the bottom :-) ?
 +
 +[14:45:10] <rajith> temporal_: I've checked in a fairly recent version. You can have a quick look when u get a chance
 +
 +[14:45:35] <rajith> temporal_: what do u mean by 'add it at the bottom' ?
 +
 +[14:45:58] <rajith> temporal_: u mean put everything in package-info ? :p
 +
 +[14:47:52] <temporal_> yes
 +
 +[14:49:35] <rajith> temporal_: that's what I have done. I will leave it as it is until we find a better way.
 +
 +[14:52:40] <temporal_> rajith yes good idea
 +
 +[14:53:14] <purplefox> rajith: did you see all the recent threads on the google groups about client refactorings? and how we are moving from service-> client?
 +
 +[14:55:23] <rajith> purplefox: yes I saw that
 +
 +[14:55:42] <rajith> purplefox: could I tackle any of those changes after the milestone release?
 +
 +[14:56:49] <rajith> purplefox: Is mongo and jdbc a model to follow? I noticed you have already some changes there
 +
 +[14:58:14] <purplefox> yeah, so mongo, jdbc, redis etc are already following this model
 +
 +[15:00:04] <rajith> purplefox: conceptually I don't see any of the methods changing as it's more or less like a client.
 +
 +[15:00:23] <rajith> purplefox: I guess what's needed is to change the 'name' to adhere to the new model.
 +
 +[15:15:52] <aesteve> hi everyone :) and welcome to the new people !
 +
 +[15:24:32] <purplefox> temporal_: sendNoContext - is this a test you added recently?
 +
 +[15:25:21] <temporal_> purplefox no
 +
 +[15:25:35] <temporal_> ah
 +
 +[15:25:54] <purplefox> it has a strange naming (no testXXX)
 +
 +[15:25:56] <temporal_> now you're saying it
 +
 +[15:26:15] <temporal_> indeed it's me
 +
 +[15:26:21] <rajith> purplefox: is this the link u were referring to https://groups.google.com/forum/#!searchin/vertx-dev/service$20to$20client/vertx-dev/kd-P8yje_EQ/RKJccqU7MXQJ ?
 +
 +[15:26:44] <purplefox> nope
 +
 +[15:26:46] <temporal_> it's the test that always use the same internal context for messages that' don't have a current context
 +
 +[15:26:47] <purplefox> that's old
 +
 +[15:27:17] <temporal_> https://github.com/eclipse/vert.x/commit/b6ab4002bde85fb08fab6e72dbd929977ab30579
 +
 +[15:27:22] <temporal_> it fails sometimes
 +
 +[15:28:10] <temporal_> I'm gonig to execute again all the HZ tests on mac
 +
 +[15:28:15] <temporal_> does it fail for you ?
 +
 +[15:29:38] <purplefox> yes it's easy to reproduce with a repeat rule
 +
 +[15:29:50] <purplefox> I.e. add this to HazelcastClustsredEventBusTest:
 +
 +[15:29:50] <purplefox> @Override
 +
 +[15:29:50] <purplefox>   @Test
 +
 +[15:29:51] <purplefox>   @Repeat(times = 100000)
 +
 +[15:29:51] <purplefox>   public void sendNoContext() throws Exception {
 +
 +[15:29:51] <purplefox>     super.sendNoContext();
 +
 +[15:29:52] <purplefox>   }
 +
 +[15:30:38] <temporal_> is the test wrong ?
 +
 +[15:30:57] <temporal_> (because the fix in EventBus is pretty trivial)
 +
 +[15:30:58] <purplefox> No, but I wouldn't expect it to pass
 +
 +[15:31:10] <temporal_> why ?
 +
 +[15:31:12] <purplefox> unless you have added the code for the default context
 +
 +[15:31:32] <temporal_> that was added
 +
 +[15:31:40] <temporal_> +        };
 +
 +[15:31:40] <temporal_> +        if (Vertx.currentContext() == null) {
 +
 +[15:31:40] <temporal_> +          // Guarantees the order when there is no current context
 +
 +[15:31:40] <temporal_> +          sendNoContext.runOnContext(v -> {
 +
 +[15:31:40] <temporal_> +            subs.get(message.address(), resultHandler);
 +
 +[15:31:40] <temporal_> +          });
 +
 +[15:31:41] <temporal_> +        } else {
 +
 +[15:31:41] <temporal_> +          subs.get(message.address(), resultHandler);
 +
 +[15:31:41] <temporal_> +        }
 +
 +[15:32:21] <temporal_> https://github.com/eclipse/vert.x/commit/b6ab4002bde85fb08fab6e72dbd929977ab30579
 +
 +[15:44:51] <purplefox> temporal_: looks like a race on the isInitialised on the ChoosableSet
 +
 +[15:45:06] <purplefox> (if you comment out the setInitialised it passes)
 +
 +[15:45:27] <temporal_> shave that yak :-)
 +
 +[15:45:35] <rajith> purplefox: I have a hard time finding that you mentioned about. If you could pls point me to it :)
 +
 +[15:45:41] <temporal_> my machine is still running HZ tests again
 +
 +[15:45:53] <rajith> purplefox: I meant the thread :p
 +
 +[15:46:44] <purplefox> rajdavies: search for "client service" on the google group. it is the 3rd result returned
 +
 +[15:47:25] <purplefox> https://groups.google.com/forum/?fromgroups#!searchin/vertx/client$20service/vertx/pK_Tcem4MXs/ns-M_pKuVWIJ
 +
 +[15:49:54] <rajith> purplefox: thanks
 +
 +[15:51:04] <purplefox> and it's the first result (after the google group itself) on google ;)
 +
 +[15:56:37] <rajith> purplefox: only if u know what to search for :p
 +
 +[15:58:02] <purplefox> rajith: well the words "client" and "service" take you straight there ;) but don't worry I quite understand it's a pain with all the refactorings going on but unfortunately that is the nature of the beast right now as we're in a mad development phase, but everything will settle down after 3.0 :)
 +
 +[15:58:15] <purplefox> so no hard feelings, i'm just teasing you ;)
 +
 +[15:59:22] <rajith> purplefox: not at all sir .. I will make every effort to conform to the new model. I don't see many disruptive changes on my end.
 +
 +[16:02:44] <purplefox> temporal_: would you like me to take a look at that test or are you ok with it?
 +
 +[16:03:17] <temporal_> purplefox you mean the choosable set race ?
 +
 +[16:03:41] <temporal_> purplefox I can have a look and ping you if I realize I'm not able to reproduce
 +
 +[16:03:47] <temporal_> I mean fix
 +
 +[16:03:51] <purplefox> ok
 +
 +[16:04:22] <purplefox> i'm pretty sure it's sometihng to do with the caching of the results as if you comment out the caching it works for me
 +
 +[16:05:16] <temporal_> which caching ?
 +
 +[16:06:05] <temporal_> entries.isInitialised() / sids.setInitialised(); ?
 +
 +[16:07:08] <temporal_> indeed it passes
 +
 +[16:16:45] <purplefox> temporal_: do you have a link to the reproducers you created for the executeOnIO issues?
 +
 +[16:17:36] <temporal_> so
 +
 +[16:17:47] <temporal_> there is a branch with 3 test cases
 +
 +[16:17:57] <temporal_> 1 is not solved (websocket big block)
 +
 +[16:18:05] <temporal_> 2 are tested and (according to me) fixed
 +
 +[16:18:29] <temporal_> is this this branch : https://github.com/eclipse/vert.x/tree/network-worker-bugs
 +
 +[16:18:43] <temporal_> then I made another reproducer
 +
 +[16:19:01] <temporal_> that reproduce same bug with websocket client
 +
 +[16:19:06] <temporal_> that is more low level
 +
 +[16:19:16] <temporal_> and use a TCP server to send an handshake to the client
 +
 +[16:19:17] <temporal_> quickly
 +
 +[16:19:33] <temporal_> I believe it's worth checking it works too
 +
 +[16:19:39] <temporal_> it is in this  branch : https://github.com/eclipse/vert.x/tree/client-worker-websocket-handshake-race-condition
 +
 +[16:21:49] <purplefox> do you have a link to the actual tests, not the entire repo?
 +
 +[16:22:24] <temporal_> ok
 +
 +[16:22:26] <temporal_> one sec
 +
 +[16:22:36] <temporal_> "let me use github for you"
 +
 +[16:23:58] <purplefox> lol
 +
 +[16:24:36] <purplefox> yeah i guess i could pull all branches and then do  a diff, but a link to the actual reproducer in the bug report would be quite helpful ;)
 +
 +[16:25:52] <temporal_> here is one test
 +
 +[16:25:53] <temporal_> https://github.com/eclipse/vert.x/commit/5ba0d60301947a6305c19797fdcea702efe44cb8#diff-04dadd1b91359310cc70281df3bc3b6bR1950
 +
 +[16:25:53] <purplefox> "hey the test is somewhere in this repo, it's my fun game for the next 15 mins to find where is is ...."
 +
 +[16:26:47] <temporal_> the trick is to drain the worker pool from the server
 +
 +[16:26:52] <temporal_> I mean vertx
 +
 +[16:27:02] <temporal_> so the server receives a netty event
 +
 +[16:27:07] <temporal_> but has no worker to process it
 +
 +[16:27:27] <temporal_> and then send a message
 +
 +[16:27:54] <temporal_> when the message is processed the connection that is not yet in the connection map
 +
 +[16:27:59] <temporal_> because it's done by the worker
 +
 +[16:28:09] <temporal_> and so the buffer is lost
 +
 +[16:28:12] <purplefox> ok... that commit, i can see it is correct without running it, so feel free to commit that to master :)
 +
 +[16:29:02] <temporal_> there is one unsolved
 +
 +[16:29:03] <temporal_> https://github.com/eclipse/vert.x/commit/c04d33f3f66ea7f73f5f33a8f5d87475c4cc6a57#diff-823a0f985a6c71bbfafac4ea06cbab71R1102
 +
 +[16:29:24] <temporal_> because it involves the synchronized / big block in websocket lcient
 +
 +[16:29:55] <temporal_> so if you fix this bug in this branch
 +
 +[16:30:01] <temporal_> I think you can then merge the branch
 +
 +[16:33:17] <rajith> temporal_: purplefox this is how the amqp docs look atm http://people.apache.org/~rajith/vert.x/docs/java/
 +
 +[16:33:51] <rajith> purplefox: the advanced example uses the service API. I might as well convert it to the new "client model" and complete the docs for that part.
 +
 +[16:34:11] <rajith> purplefox: temporal_ that is the only missing part.
 +
 +[16:34:22] <cescoffier> just for information, openshift provides java 7, not 8[unknown:hellip]. (current), in 28 days, they provides a completely new openshift (docker based)
 +
 +[16:34:54] <temporal_> cescoffier good to know
 +
 +[16:35:22] <cescoffier> so, for now, we are a bit stuck
 +
 +[16:35:39] <aesteve> cescoffier: just in case this might be helpful https://gist.github.com/aesteve/50e366a2efd6571f414b
 +
 +[16:35:48] <aesteve> (i faced the same issue some months ago)
 +
 +[16:36:00] <cescoffier> cool ! Thanks
 +
 +[16:36:07] <purplefox> cescoffier: interesting.. i suspect they are timing their release to Red hat summit
 +
 +[16:36:08] <rajith> temporal_: btw I noticed that any formatting done inside a table is ignored (see the config section in the link I posted). Not sure if it's bug in the assiidoc generation or a bug on my part.
 +
 +[16:36:11] <cescoffier> yes, we can provision the JVM ourself
 +
 +[16:36:20] <purplefox> cescoffier: and we are releasing at the same time
 +
 +[16:37:26] <purplefox> cescoffier: yeah i guess we do that for now, we can also enquire internally to see if we can get early access to the new openshift
 +
 +[16:37:45] <purplefox> temporal_: that test times out for me, as that what you get?
 +
 +[16:38:54] <purplefox> rajith: the other thing for the client api.. .as it does not need to be proxygen any more it means it can be richer
 +
 +[16:40:44] <temporal_> purplefox yes
 +
 +[16:40:54] <temporal_> it cannot really fail
 +
 +[16:41:24] <temporal_> I think it can only pass or timeout
 +
 +[16:43:12] <rajith> purplefox: I went through the thread and the use cases I had in mind ... I think we can make the case for both a service and a client. The beauty of the current impl I have is, that you can get existing vertx apps and amqp apps to talk without much changes in code
 +
 +[16:44:18] <rajith> purplefox: The bridge seems a very useful piece and the Service API was a really nice way to interact with it. But I do see the value of the "client API"
 +
 +[16:44:34] <rajith> purplefox: maybe AMQP is one case where you could have both. What do you think?
 +
 +[16:45:42] <rajith> purplefox: I think advocated for both right at the beginning ;)
 +
 +[16:47:41] <rajith> purplefox: I have examples (not in doc yet) which uses the service API to do the traditional publish/consume from a message broker and the more modern peer-to-peer approach of communicating with other AMQP apps directly. The "Client API" is great option for the former use case as there is no reason to really go through the bridge.
 +
 +[16:48:16] <rajith> But for the latter use case I see both the 'service' approach and 'client' approach being useful.
 +
 +[16:49:53] <rajith> purplefox: the bridge merely extends the Vert.x event-bus into the AMQP space. So a Verticle can communicate with an AMQP node as it's just another Verticle :)
 +
 +[16:50:32] <purplefox> temporal_: did you see my message before about marking MetricsContextTest as Ignore?
 +
 +[16:50:55] <purplefox> rajith: we will take a look before long, but we are just very overwhelmed with other  stuff at the moment
 +
 +[16:51:24] <temporal_> purplefox yes
 +
 +[16:51:33] <temporal_> purplefox but fixing this bug will fix the MetricsContextTest
 +
 +[16:51:44] <temporal_> purplefox as they are just failing because of this
 +
 +[16:51:46] <rajith> purplefox: I understand. Maybe after friday? I understand u are busy with the milestone release for this friday
 +
 +[16:53:02] <temporal_> purplefox so about Hazelcast : the problem is that there are two kinds of tasks that go into AsyncMultiMap#get
 +
 +[16:53:15] <temporal_> the one that go in the executeBlockign and are serialized properly
 +
 +[16:53:32] <temporal_> and the other that find the boolean and are executed directly (already in the context)
 +
 +[16:53:46] <temporal_> so we endup with two ordered series
 +
 +[16:53:51] <purplefox> right
 +
 +[16:53:59] <temporal_> one suggestion I had
 +
 +[16:54:06] <temporal_> was to do like CompletableFuture and such
 +
 +[16:54:21] <temporal_> to have a List of actions on the ChoosableSet
 +
 +[16:54:34] <temporal_> to reorder actions
 +
 +[16:54:39] <temporal_> and use that list until it's not empty
 +
 +[16:54:58] <temporal_> do you have a more trivial fix ?
 +
 +[16:55:10] <purplefox> the trivial fix would be to always use executeBlocking
 +
 +[16:55:13] <temporal_> yes
 +
 +[16:55:28] <purplefox> but.. it's slow
 +
 +[16:55:30] <purplefox> (er)
 +
 +[16:55:49] <purplefox> you could keep an atomic count of outstanding executeblocking
 +
 +[16:56:07] <purplefox> and use executeblocking only if count > 0
 +
 +[16:56:12] <temporal_> yes
 +
 +[16:56:14] <purplefox> but you have to be careful of races there
 +
 +[16:56:32] <temporal_> the issue I think will be to block event loop thread
 +
 +[16:56:39] <temporal_> well no
 +
 +[16:57:08] <temporal_> I think we can remove the boolean initiliazed and have this count
 +
 +[16:57:22] <temporal_> as having count > 0 means it's not initialized
 +
 +[16:57:28] <temporal_> and use CAS operations
 +
 +[16:58:40] <purplefox> hmm another thought is now to update the cache until the resultrHandler of the executeblocking
 +
 +[16:58:47] <purplefox> and then should always be run on the callers context
 +
 +[16:58:53] <purplefox> so it should be non racy
 +
 +[16:59:20] <temporal_> I did that first
 +
 +[16:59:40] <temporal_> I did that
 +
 +[16:59:41] <temporal_> , ar -> {
 +
 +[16:59:41] <temporal_>         if (ar.succeeded()) {
 +
 +[16:59:41] <temporal_>           ChoosableSet<V> sids = ar.result();
 +
 +[16:59:41] <temporal_>           sids.setInitialised();
 +
 +[16:59:41] <temporal_>           resultHandler.handle(Future.succeededFuture(sids));
 +
 +[16:59:41] <temporal_>         } else {
 +
 +[16:59:43] <temporal_>           resultHandler.handle(Future.failedFuture(ar.cause()));
 +
 +[16:59:43] <temporal_>         }
 +
 +[16:59:43] <temporal_>       }
 +
 +[16:59:47] <temporal_> that fixes some order
 +
 +[16:59:53] <temporal_> but we still endup with two series
 +
 +[16:59:59] <purplefox> yeah
 +
 +[17:00:01] <temporal_> the very first invocation is always first
 +
 +[17:00:12] <temporal_> but the pending are interveaved
 +
 +[17:00:15] <temporal_> interleaved
 +
 +[17:08:47] <purplefox> temporal_: I'm trying to understand the sequence of actions that make the websocket context test fail... I understand from you this is because the netty stack is changed, but do you have something a bit more specific?
 +
 +[17:09:06] <temporal_> yes
 +
 +[17:09:15] <temporal_> let me find that back in my memory for you
 +
 +[17:10:55] <temporal_> one way to find out is to set a breakpoint in Netty stack
 +
 +[17:11:34] <temporal_> there is also this test I wrote https://github.com/eclipse/vert.x/commit/7862e3f22da716f73ff515af02e8fd9644cc9dc9
 +
 +[17:11:40] <temporal_> that reproduce the same bug
 +
 +[17:12:12] <temporal_> what is does : send in one buffer the handshake + a buffer to the client
 +
 +[17:12:18] <purplefox> i have a reproducer working. what I don't quite understand right now, is why the issue occurs
 +
 +[17:12:56] <temporal_> yes it's tricky
 +
 +[17:13:02] <temporal_> I'm looking for the class
 +
 +[17:15:39] <temporal_> so in ClientConnection#channelRead
 +
 +[17:15:49] <temporal_> we do have
 +
 +[17:15:50] <temporal_> handshakeComplete(ctx, response);
 +
 +[17:15:55] <temporal_> that modifies the Netty stack
 +
 +[17:16:03] <temporal_> to add the correct websocket protocol decoder
 +
 +[17:16:19] <temporal_> and this protocol decoder arrives after the buffer is received as it is executed in the worker
 +
 +[17:16:30] <temporal_> and the websocket frame is just ignored
 +
 +[17:17:13] <temporal_> this happens when the message is handled by netty before the worker thread process the lambda of executeFromIO
 +
 +[17:18:01] <temporal_> as far as I remember it happens in "handshaker.finishHandshake(channel, response);"
 +
 +[17:18:49] <temporal_> Netty's WebSocketClientHandshaker finishHandshake method
 +
 +[17:18:56] <temporal_> modifies the stack
 +
 +[17:18:59] <temporal_> p.replace(ctx.name(), "ws-decoder", newWebsocketDecoder());
 +
 +[17:19:48] <purplefox> ok, so there is already a mechanism there to buffer messages that arrive
 +
 +[17:19:57] <purplefox> buffered.add(msg);
 +
 +[17:20:16] <purplefox> maybe an easy fix would be to remove that outside of the executeonIo block
 +
 +[17:20:33] <temporal_> I missed that one :-)
 +
 +[17:20:35] <purplefox> the handshaker/handshaking flag would need to be removed too
 +
 +[17:20:40] <purplefox> s/removed/moved
 +
 +[17:20:48] <temporal_> my fix was to move everything outside of executeFromIO
 +
 +[17:21:04] <temporal_> and only keep the handler callback inside
 +
 +[17:21:12] <temporal_> to the client handlers
 +
 +[18:11:16] <purplefox> temporal_: i'm splitting vertx-auth into maven submodules and I'm getting a codegen error:
 +
 +[18:11:17] <purplefox> Could not generate model for io.vertx.ext.auth.jdbc: A module cannot be nested inside another module
 +
 +[18:11:20] <purplefox> any ideas?
 +
 +[18:24:59] <purplefox> temporal_: ok, it seems i can't have a package-info in one package and more package-infos in subpackages :(
 +
 +[18:40:00] <temporal_> purplefox this is a codegen problem
 +
 +[18:40:04] <temporal_> not a doc problem
 +
 +[18:40:17] <temporal_> you need to remove a @GenModule annotation that you forgot
 +
 +[18:40:37] <temporal_> that's the annotation that generates JS modules
 +
 +[18:40:39] <temporal_> and ruby modules
 +
 +[18:40:47] <temporal_> (so it does not make sense to have such nested modules)
 +
 +[18:41:04] <purplefox> where do i remove it from?
 +
 +[18:41:20] <temporal_> look for @GenModule
 +
 +[18:41:30] <temporal_> in package-info.java
 +
 +[18:41:45] <purplefox> i've done a search but they all look ok to me
 +
 +[18:41:46] <temporal_> for instance
 +
 +[18:42:00] <temporal_> push it somewhere and I'll look at it tonight
 +
 +[18:42:06] <temporal_> I need to go soon
 +
 +[18:42:13] <purplefox> i'm trying to understand  the restriction
 +
 +[18:42:28] <purplefox> so now we have io.vertx.auth - which contains the common auth interfaces
 +
 +[18:42:43] <purplefox> and we have, for example, io.vertx.auth.jdbc which contains the jdbc implementation
 +
 +[18:42:55] <purplefox> and they both have  package-info for their docs
 +
 +[18:42:56] <temporal_> https://github.com/vert-x3/vertx-codegen/blob/master/src/main/java/io/vertx/codegen/CodeGen.java#L156
 +
 +[18:43:08] <purplefox> not sure why this doesn't make sense
 +
 +[18:43:10] <temporal_> it's a codgen failure
 +
 +[18:43:25] <temporal_> not sure why it's related to doc
 +
 +[18:43:31] <temporal_> I need to go :-)
 +
 +[18:43:38] <purplefox> ok, i don't understand
 +
 +[18:43:53] <temporal_> push it somewhere and I try to understand later
 +
 +[18:44:00] <temporal_> just send me a link in a mail
 +
 +[18:44:42] <purplefox> ok, i don't understand why we make the restriction
 +
 +[18:44:57] <temporal_> because  @GenModule generates a JavaScript
 +
 +[18:44:58] <temporal_> module
 +
 +[18:45:06] <purplefox> it's seems quite ok to me to have one package with docs and a subpackage with docs too
 +
 +[18:45:14] <temporal_> but that's a codegen failure
 +
 +[18:45:22] <temporal_> I htink it works fine with doc
 +
 +[18:45:29] <temporal_> so this error does not make sense to me
 +
 +[18:45:33] <temporal_> that's why I want to look at it :-)
 +
 +[18:45:51] <purplefox> if i rename the packages so there is a flat hierarchy it works fine
 +
 +[18:46:57] <temporal_> do you have nested @GenModule ?
 +
 +[18:47:07] <temporal_> because this is only that triggers this
 +
 +[18:47:12] <temporal_> if not , there is a bug
 +
 +[18:47:23] <temporal_> anyway, need to disconnect and reconnect later
 +
 +[18:50:14] <jua03> hi!, is there any "3.0.0" compatible gradle template out there?
 +
 +[18:50:45] <jua03> everything I seem to find is 2.x and somehow different :)
 +
 +[18:55:11] <purplefox> ?
 +
 +[20:19:53] <purplefox> pmlopes: hi paulo - one thing i noticed is i get lots of NPEs when running the JWT auth tests, but they all pass ok. Is this deliberate?
 +
 +[20:39:05] <pmlopes_> purplefox: please read the following issue: https://github.com/vert-x3/vertx-auth/issues/16
 +
 +[20:42:36] <purplefox> pmlopes: i'm not sure i understand the logic in your example
 +
 +[20:43:23] <purplefox> pmlopes: i can see the value in having a simple isPermitted(), that's fine. But I can't see why the current implementation is wrong...
 +
 +[20:44:22] <purplefox> if you want to know is Paulo can push to production why is the following not sufficient? :
 +
 +[20:44:30] <purplefox> paulo.hasPermission("push")
 +
 +[20:44:45] <pmlopes_> because there is no context push can be either from dev or devops
 +
 +[20:45:37] <purplefox> not sure i follow...
 +
 +[20:46:02] <purplefox> isn't it up to the implementation to work this out?
 +
 +[20:46:42] <purplefox> for example the jdbc impl does a join between user / user_roles / roles_permissions to get the set of permissions for the user
 +
 +[20:48:30] <pmlopes_> ok let me use some json {roles: {dev: [push], devops: [read]}} this is the data model graph however from the auth api we do: user.hasPermission("push"), since there is context we don't know if we should read the "push" from dev role or devops role
 +
 +[20:48:47] <pmlopes_> {roles: {dev: [push], devops: [read, push]}}
 +
 +[20:49:05] <pmlopes_> in the last example which permission "push" is the correct one?
 +
 +[20:49:18] <purplefox> the implementation should calculate the set of permissions by traversing the graph of roles that the user has
 +
 +[20:49:30] <pmlopes_> and from the first we cannot assume just becaus i can push it is the devops one
 +
 +[20:50:19] <purplefox> are you saying there are two different permissions both called "push"?
 +
 +[20:50:44] <pmlopes_> yes, that is a fair assumtion, think of "read" is can be applied to many roles
 +
 +[20:51:00] <purplefox> i think the assumption is that the permission name is globally unique
 +
 +[20:52:03] <purplefox> otherwise the whole role/permissions model doesn't really work as you'd have to prefix the permision with the role every time
 +
 +[20:52:17] <pmlopes_> ok, but if you do have unique permissions they are explicit and i would say the role is just noise, for example in my case it would be devops_push, dev_push, devops_read
 +
 +[20:52:19] <purplefox> which would be kind of pointless, then you'd have just a roles model really
 +
 +[20:52:31] <pmlopes_> exactly :)
 +
 +[20:52:55] <purplefox> but the value in a roles/permissions model is it allows you to group permissions
 +
 +[20:53:13] <pmlopes_> now we can call it roles, permissions or authorities, after reading the apache shiro docs today i kind of like the hasPermission
 +
 +[20:53:45] <purplefox> my 2c on this is.. a standard roles/permissions model like we currently have is fine.. IF you like roles/permisions models ;)
 +
 +[20:53:54] <purplefox> but I agree that a simple isPermitted is more flexible
 +
 +[20:54:13] <purplefox> and allows us to support basically anything
 +
 +[20:54:19] <purplefox> e.g. hierarchies and prefixes etc etc
 +
 +[20:54:59] <pmlopes_> well we can make it like in string, so in spring they have the strings and then there is a helper hasRole() which just filters the authorities based on a prefix
 +
 +[20:54:59] <purplefox> so I like your proposal. but I just didn't agree the current roles/permission is broken ;) basically
 +
 +[20:55:36] <pmlopes_> ok, i will be more positive with my comments :)
 +
 +[20:56:33] <purplefox> i think it makes sense to make the string meaning opaque as you suggested :)
 +
 +[20:56:39] <purplefox> so... do you want to implement this? ;)
 +
 +[20:57:36] <pmlopes_> yes, sure, but i cannot promise that it will be ready thursday :)
 +
 +[20:57:43] <pmlopes_> but next week for sure!
 +
 +[20:58:07] <purplefox> we would need it done before monday as that's when julien will do the release
 +
 +[20:58:48] <pmlopes_> ok, i think i can make it.
 +
 +[20:58:56] <pmlopes_> deal!
 +
 +[20:59:27] <purplefox> awesome, thanks paulo
 +
 +[20:59:49] <purplefox> tbh i don't think it's a very big change as the change are isolated to vertx-auth and vertx-web
 +
 +[21:00:17] <pmlopes_> I will keep hasPermission and modify hasRole for filtering on on a pattern so we don't change the API
 +
 +[21:04:22] <purplefox> pmlopes: why do we need to keep the current API?
 +
 +[21:06:28] <purplefox> it seems to me that if we think isPermitted() is better, why keep hasRole/hasPermission at all?
 +
 +[22:01:37] <AlexLehm> jua03, https://github.com/vert-x3/vertx-examples
 +
 +[22:01:48] <AlexLehm> the gradle-simplest should work as a gradle template
 +
 +[22:04:12] <jua03> thanks... already tried, but probably was missing some point... probably something misconfigured in my side, will try again :)
 +
 +[22:16:17] <AlexLehm> haven't tried gradle in a while though