[11:27:52] <purplefox> temporal_: hi julien
[11:27:55] <purplefox> temporal_: how are you?
[11:28:06] <temporal_> hi purplefox I'm doing good, what about you ?
[11:28:46] <purplefox> i'm pretty well. i have recently taken up cycling as I need to get more fit, so I've been doing some bike rides this weekend :)
[11:29:56] <purplefox> i guess we should figure out what we're going to do with this release
[11:30:06] <temporal_> purplefox +1
[11:30:30] <purplefox> i am keen not to delay it too long, as the final release is basically timeboxed and an immovable deadline
[11:30:52] <purplefox> what are your thoughts?
[11:31:05] <temporal_> I think like you
[11:31:20] <temporal_> I think what matters is to include what can be included to get feedback
[11:31:27] <temporal_> I'm thinking of jruby mostly
[11:31:47] <purplefox> i think most things are there
[11:31:55] <purplefox> jruby is nearly there, http factories also
[11:31:57] <temporal_> because lang has always things to improve
[11:32:06] <temporal_> I've seen that with js and groovy
[11:32:20] <temporal_> we had to fix many little important things over the time
[11:32:32] <purplefox> ok.. so how about this.. we spend today just getting the last bits together, and then start the release tomorrow?
[11:32:47] <temporal_> I think we need an extra day for ruby
[11:32:49] <purplefox> so we include jruby, bintray/http etc. also the new service-client refactoring
[11:32:50] <temporal_> or 1/2 day
[11:32:59] <temporal_> because it needs to be propagated in the stack
[11:33:13] <temporal_> and probbably do changes in code trans to test things
[11:33:30] <purplefox> ok
[11:33:40] <temporal_> also there is this pending work for jruby
[11:33:54] <temporal_> the current delegation to java is not optimal
[11:34:03] <temporal_> (you may have seen this in the generated code)
[11:34:12] <purplefox> do you have a pointer?
[11:34:45] <temporal_> for instance
[11:35:01] <temporal_> so there is a better way and this needs a fix in jruby 1.7.20
[11:35:09] <temporal_> I think that functinnaly it is the same thing though
[11:35:19] <temporal_> so we could release with this
[11:35:25] <temporal_> if jruby 1.7.20 does not come in time
[11:35:38] <purplefox> what does fixjavamethod do?
[11:35:49] <temporal_> it fixs issues in jruby
[11:35:52] <temporal_> the same code
[11:35:55] <temporal_> with the good way
[11:36:17] <temporal_> and we are supposed to get this 1.7.20 early this week
[11:36:35] <purplefox> i'm not sure I understand this, we didn't do anything like this in Vert.x 2…
[11:36:51] <purplefox> we just called the Java methods directly
[11:37:01] <temporal_> that raise issues
[11:37:19] <temporal_> with dispatch ambiguities
[11:37:50] <purplefox> ok i see. so this lets you explicitly choose the method to call
[11:37:52] <temporal_> java_method is the good way to do for us
[11:38:02] <temporal_> we've been working on that with headius
[11:38:11] <purplefox> ok fair enough. as long as there is no perf overhead :)
[11:38:25] <temporal_> headius said that java_method is good for perfs
[11:38:26] <purplefox> cool, if charlie says its ok i trust him ;)
[11:39:23] <purplefox> ok.. so how about.. add issues for any remaining tasks in ruby and then we can merge the current work more quickly
[11:39:24] <temporal_> so we can merge the initial-work
[11:39:35] <temporal_> and apply this patch when jruby 1.7.20 is available
[11:39:39] <temporal_> ys
[11:39:40] <temporal_> yes
[11:39:43] <purplefox> yes, although.. i don't think the stuff about creating new containers for each verticle is right…
[11:39:48] <temporal_> it should have been released yesterday
[11:39:58] <temporal_> I need to chec kthat
[11:40:15] <temporal_> I think creating new containers now is only done when deploying a gem
[11:40:25] <temporal_> because the GEM_PATH must be changed
[11:40:26] <purplefox> it's done if GEM_HOME is set i think
[11:40:32] <purplefox> GEM_PATH sorry
[11:40:41] <temporal_> yes
[11:40:50] <temporal_> that was the work around advocated by Charlie
[11:40:51] <purplefox> but i think GEM_PATH will be commonly set by jruby users
[11:41:31] <purplefox> the trouble with creating a new container is JRuby is heavyweight in RAM so you can then only deploy about 200 verticles
[11:41:38] <purplefox> we had this issue in Vert.x 2
[11:42:17] <purplefox> and even if GEM_PATH is not set I think you will have issues with multiple instances as they are sharing the same container
[11:42:22] <temporal_> perhaps we can maintain a Map<GEM_PATH, container> instead
[11:42:38] <purplefox> why does GEM_PATH need a new container at all?
[11:43:11] <temporal_> because it cannot be changed after it is loaded
[11:43:38] <purplefox> i'm not sure I follow
[11:44:07] <temporal_> the GEM_PATH is an env variable of jruby runtime
[11:44:16] <temporal_> and it is read when the container start
[11:44:19] <temporal_> is created
[11:44:31] <purplefox> ok
[11:44:39] <purplefox> i know that bit :)
[11:44:52] <purplefox> but why does that mean you need a new container for each verticle if it is set?
[11:44:54] <temporal_> look at this test
[11:45:39] <temporal_> it is usually set when one wants to deploy a verticle bundled as a gem
[11:45:52] <temporal_> but if the verticle is deployed in the usual GEM_PATH it is fine
[11:46:39] <purplefox> ok, but i still don't see why that implies the verticle must be in its own container
[11:47:00] <temporal_> to be able to be loaded from the GEM_PATH
[11:47:30] <purplefox> i don't get it. the GEM_PATH is an env var that the user has set
[11:47:33] <purplefox> then they do:
[11:47:40] <purplefox> vertx run myverticle.rb
[11:47:47] <purplefox> and it will use that GEM_PATh
[11:48:01] <purplefox> and if that verticle deploys others, no need for different containers
[11:48:05] <purplefox> they will all use that GEM_PATH
[11:48:57] <purplefox> as each vertx run starts a new vertx
[11:48:59] <temporal_> this new container is only created if the user set a GEM_PATH in the deployment options
[11:49:55] <purplefox> ah! you're allowing it to be configured per verticle in deployment!
[11:49:58] <purplefox> i see
[11:50:19] <temporal_> yes
[11:50:27] <purplefox> do you think that's really something users will do?
[11:51:17] <temporal_> I guess
[11:51:49] <temporal_> it's something they can use when they deploy a verticle programatically
[11:52:25] <purplefox> ok fair enough
[11:52:43] <temporal_> I think however it could use a map to reuse the same container for the same gem_path
[11:53:51] <purplefox> temporal_: maybe, although i wouldn't consider it high priority - i don't think i've heard anyone ask for this feature
[11:53:59] <temporal_> purplefox sure
[11:54:18] <purplefox> i would be more worried about wrapping verticles in a module so they are isolated as that appears to be broken currently
[11:54:19] <temporal_> I believe I also implemented it for testing deploying a verticle as gem more easily without hacks
[11:54:48] <temporal_> what do you call module ?
[11:54:53] <purplefox> so.. there are a few things from the Vert.x 2 JRubyVerticleFactory that will need implementing
[11:55:06] <purplefox> take a look at the Vert.x 2 version and you will see
[11:55:25] <purplefox> when we deploy a JRuby verticle in the same container we need to wrap it in a module
[11:55:31] <purplefox> to give it isolation
[11:55:37] <temporal_> wrappingModule
[11:55:38] <purplefox> you'll need to do this too
[11:55:43] <temporal_> ok
[11:55:50] <purplefox> otherwise everything pollutes the top level
[11:55:52] <temporal_> for global vars ?
[11:56:00] <temporal_> ok good point
[11:56:06] <temporal_> I'll come up with a test and a fix quickly
[11:56:11] <purplefox> it's similar to how in JS we wrap everything in a function (using require)
[11:56:31] <temporal_> ok
[11:57:11] <temporal_> this test seems to be about this : https://github.com/vert-x/mod-lang-jruby/blob/master/src/test/java/org/vertx/java/tests/core/isolation/RubyIsolationTest.java
[11:57:12] <purplefox> also take a look at the method requireCallback in JRubyVerticleFactory
[11:57:31] <purplefox> yes
[11:57:45] <temporal_> I will
[11:57:58] <purplefox> we will basically need to override the default require method
[11:58:09] <purplefox> as we do in Vert.x 2
[11:58:18] <purplefox> otherwise get race conditions when deploying multiple verticles
[11:58:25] <temporal_> is it endorsed by Charlie ?
[11:58:42] <purplefox> no idea. but it's needed to fix bugs, or we'll have regressions :)
[11:59:07] <purplefox> basically there are various things in the old JRubyVerticleFactory that are there to fix various issues reported by users
[11:59:18] <temporal_> ok I will have a careful look
[11:59:40] <purplefox> problem is, if you deploy N jruby verticles and they all do a require(“foo.rb”) at the same time
[11:59:51] <purplefox> then you can get failures, as jruby doesn't like concurrent requires
[12:00:14] <purplefox> so we have to create our own require method which basically has a bit synchronized block to serialise everything
[12:00:19] <temporal_> can't we synchronize around the jruby container when deploying or do something like that ?
[12:00:45] <purplefox> no, i think require can happen in jruby at any time, not just at deploy time
[12:01:20] <temporal_> ok
[12:01:24] <purplefox> maybe charlie has a better solution, but that worked well in 2 :)
[12:01:30] <purplefox> it might be worth asking him
[12:01:49] <temporal_> I agree
[12:01:50] <purplefox> basically there are quite a few “hacks” in the old 2 factory that users will rely on
[12:02:00] <purplefox> so we need to be a bit careful
[12:02:19] <temporal_> yes
[12:07:03] <purplefox> temporal_: could you also review those remaining PRs then I can get them into master? :)
[12:07:19] <temporal_> sure, I will too
[12:21:59] <purplefox> temporal_: are there any outstanding PRs from you that I still need to review?
[12:31:28] <temporal_> purplefox no there is not I think
[12:31:48] <temporal_> purplefox I spent time improving a bit the rx refactor branch and found a way to get a Vertx instance
[12:32:18] <temporal_> purplefox for integrating with reactive-streams
[12:32:27] <purplefox> ok
[12:32:35] <temporal_> https://github.com/vert-x3/vertx-rx/tree/back-pressure
[12:32:38] <temporal_> you may want to look at it
[12:35:41] <alober> hi, I use vert-x3 and mongodb, I want use java.lang.Long as the mongodb's _id type, when I save it, I see :io.vertx.core.eventbus.ReplyException: java.lang.Long cannot be cast to java.lang.CharSequence, how can I fix it please?
[12:47:25] <AlexLehm> purplefox: have you considered a closed forum for security issues? (not sure if the report by mathis is in fact a security issue, but it might be a good idea anyway)
[12:55:31] <AlexLehm> “mathias” rather, sorry
[13:09:38] <purplefox> AlexLehm: perhaps. feel free to suggest it on the google group :)
[14:53:58] <aesteve> “kinda meh”
[14:54:05] <aesteve> oops, sry
[14:54:09] <aesteve> hello folks :)
[15:15:34] <aesteve> purplefox:I've started working on a feed aggregator using apex, handlebars, worker verticles, mongo, redis and sockjs
[15:15:44] <aesteve> is ths what you have in mind for end-end examples ?
[15:17:59] <aesteve> https://github.com/aesteve/vertx-feeds
[16:52:47] <Fuu^> hi guys. two questions: Is there a skeleton module for vertx3 that can be used as a base and includes all the required gradle stuff?
[16:53:38] <Fuu^> and, is scala usable for module development on the current development version of vertx3
[16:54:07] <Fuu^> i see it's scheduled for 3.1, just curious if it can be used at this point
[16:54:37] <aesteve> 1. https://github.com/vert-x3/vertx-examples/tree/master/gradle-simplest
[16:54:57] <aesteve> can't answer your second question though :(
[16:55:23] <Fuu^> i actually saw that basic gradle project, but it's for embedded development
[16:57:01] <aesteve> embedded development ? sorry I don't understand, what do you want to do ?
[16:58:18] <Fuu^> nevermind. there is simple verticle example next to it that i missed for some reason.
[16:59:07] <aesteve> ok :)
[19:05:50] <purplefox> temporal_: julien, can you give me a rough estimate of when you think the jruby impl will be ready?
[19:06:39] <temporal_> do you mean project merged or integrated in the stack ?
[19:06:52] <purplefox> whatever we need to do for the next release
[19:07:10] <temporal_> at most wedenesday evening
[19:07:49] <purplefox> what remains to be done?
[19:08:00] <purplefox> just the stuff we were talking about today?
[19:08:02] <temporal_> port the scoping from 2.x
[19:08:08] <temporal_> in the impl yes
[19:08:23] <temporal_> then the stack integration
[19:08:30] <temporal_> with project generating correct ruby, doc
[19:08:37] <temporal_> examples generation
[19:08:43] <purplefox> i see
[19:08:44] <purplefox> ok
[19:08:54] <purplefox> so lets aim for end of tomorrow :)
[19:09:00] <temporal_> ok
[19:09:07] <temporal_> there will be somehting for sure
[19:09:18] <purplefox> i'll update the date on the roadmap
[19:09:23] <purplefox> to thursday
[19:09:40] <temporal_> sure
[19:10:12] <temporal_> jruby 1.7.20 is being done at the moment
[19:39:33] <aesteve> purplefox: I just read your answer on the Google Group
[19:40:38] <aesteve> I'll try to integrate it into Apex, but I have to work with IntelliJ (eclipse maven plugin is a mess) so not before this weekend
[19:43:02] <purplefox> sure, no hurry
[19:43:58] <aesteve> I'm not sure the pattern I used was the right one though we'll see
[19:46:38] <jtruelove> was just looking at the magic GUID used in websocket upgrading, kinda wild
[19:47:10] <jtruelove> i wonder why you can't specialize that so a client server could use a custom GUID for added security
[19:47:18] <jtruelove> i'm sure there's a reason
[19:57:53] <purplefox> temporal_: ok, sorry forgot submit this PR too. so there's another one ;) https://github.com/eclipse/vert.x/pull/1031
[20:01:01] <aesteve> purplefox:ah, and I'd also like to work on the RSS aggregator example
[20:01:05] <aesteve> what do you prefer first ?
[20:05:16] <purplefox> i don't mind, but bear in mind, if it doesn't get done in the next 2 ore 3 weeks it won't make the final release :)
[20:05:58] <aesteve> mmh good point. The examples can still be done afterwards
[20:06:49] <purplefox> jtruelove: ah the websocket magic string… kind of odd i agree ;)
[20:08:07] <purplefox> i think the idea is to reduce the probability of “some other server” giving the same response by accident to virtually zero:
[20:08:28] <aesteve> so OK purplefox I'll fight with IntelliJ / GitHub this week-end to have something working
[20:08:50] <aesteve> maybe vertx.createSSEClient() could be interesting too ? At least for testing
[20:08:54] <purplefox> so basically we are timeboxing the final release so it doesn't drag on for ever
[20:09:03] <purplefox> so that might mean dropping features if they're not ready
[20:10:46] <aesteve> oh and there's the codegen and doc generation too, forgot about that. So yes this might take a while
[20:11:22] <purplefox> right, so the danger is we try and get too many features in, but none are properly complete so we end up with none of them in :(
[20:11:42] <purplefox> it might be better to concentrate on a smaller number of features and make sure they are well complete
[20:11:47] <aesteve> ok sounds like a fair addition for 3.1 though
[20:12:13] <purplefox> SSE looks good. and i think the server side impl will be pretty simple so maybe there is enough time.. we'll see
[20:12:25] <purplefox> but i think feature creep is an issue we will have to be strict with
[20:13:00] <aesteve> I'd rather take my time to implement it properly (especially closeHandlers on server-side) for now I'm not happy with it
[20:13:17] <aesteve> and there's some issues I thought about after writing the small example
[20:13:36] <jtruelove> i need to upgrade manually because i want access to the client cert on the http request
[20:14:07] <aesteve> like : from the SSEConnection object (Handler<SSEConnection>) the user should have access to the underlying ServerRequest
[20:14:33] <aesteve> the ability to reject and SSEConnection too, is missing for now
[20:15:07] <aesteve> and I have to check if there's an encoding negociation or not
[20:15:44] <aesteve> anyway, have a good evening everyone :)
[20:18:01] <purplefox> jtruelove: you mean using the upgrade() method on HttpServerRequest?
[20:18:16] <jtruelove> yeah sort of like the sample in the test
[20:18:30] <purplefox> which test?
[20:20:33] <jtruelove> well no test grabs the client cert, but there's an upgrading example
[20:20:50] <jtruelove> but if there's a client cert you could grab it by manually upgrading
[20:21:35] <purplefox> what do you mean by “manually upgrading”?
[20:21:47] <purplefox> do you mean handling the full handshake yourself?
[20:21:51] <jtruelove> yep
[20:22:03] <purplefox> are you using vert.x 3?
[20:22:08] <jtruelove> vs the standard API websocket/listener approach
[20:22:10] <jtruelove> yes i am
[20:22:25] <jtruelove> is there a better way to do it 3?
[20:22:36] <purplefox> in vert.x 3, you can also handle websockets using HttpServerRequest.upgrade(), and you have access to the certs too
[20:22:45] <purplefox> so no need to handle the actual handshake yourself
[20:23:23] <gigo1980_> hi together ist there an tutorial to start with vertx 3 ? [20:23:51] <jtruelove> oh splendid, yeah i was like at the vertx 2 example [20:23:54] <purplefox> gigo1980_: i recommend starting at the website and looking at the docs page, there are some links to docs and to the examples repo which has the helloworld examples
[20:24:05] <purplefox> gigo1980_: http://vert-x3.github.io/ [20:24:07] <jtruelove> i got the code up in the 3 tests now [20:24:24] <gigo1980_> and is there an installation required as the play framework
[20:24:35] <gigo1980_> or is the vertx is build in in the application it self ? [20:24:50] <purplefox> gigo1980_: take a look at the README in the examples repo, it should explain that :)
[20:25:02] <gigo1980_> ok thx [20:25:06] <jtruelove> the only thing with the request.upgrade() stuff is i couldn't customize my protocol at that point right [20:26:00] <purplefox> what do you mean by “customize my protocol”? [20:27:11] <jtruelove> like replying with a header Sec-WebSocket-Protocol: somethingSpecial [20:27:33] <gigo1980_> ok as i read in the doc. i create a plain java maven app, and simple and add the vertx dependencie, rigth ?
[20:27:42] <gigo1980_> i try to develope in java [20:28:47] <jtruelove> gigo1980 this might help also https://github.com/vert-x3/vertx-examples [20:29:20] <jtruelove> shows you a bunch samples of doing things with maven or gradle [20:29:29] <purplefox> jtruelove: well the protocol is well defined, if you change it, it will break things [20:30:20] <purplefox> jtruelove: basically, if you change the websocket protocol, then it's not the websocket protocol any more ;) [20:30:27] <jtruelove> k, when i was reading the spec it seemed there was some level of fluidity on that part but i could have miss read it [20:30:53] <jtruelove> they were showing things like 'chat' in that field etc.. [20:31:04] <purplefox> ah, is this the sub-protocol stuff? [20:31:18] <jtruelove> so it didn't seem the the field was a static thing, yeah [20:31:52] <purplefox> well.. subprotocol is poorly named,they're not really protocols [20:32:00] <purplefox> there's only one protocol - the websocket protocol [20:32:05] <purplefox> and it's as designed in the spec [20:32:22] <jtruelove> http://enterprisewebbook.com/ch8_websockets.html i was looking at this down in the handshake section [20:33:47] <jtruelove> so it appeared that you could have a custom value there for some additional level of verification, but from what you're saying that doesn't sound like the case [20:34:28] <purplefox> do you mean this: [20:34:29] <purplefox> Sec-WebSocket-Protocol: chat [20:34:45] <purplefox> i think this is just an extra field that you can optionally pass from the client [20:34:54] <purplefox> but it's not really a different protocol, it's just a field [20:35:12] <purplefox> and the server can look at that and decide to reject or whatever based on that field [20:35:23] <jtruelove> yeah i was just calling it that because it had protocol and websocket in the header name :) [20:35:45] <purplefox> vert.x allows you to do that using the subprotocols on the HttpServerOptions [20:35:53] <purplefox> and you can set it from HttpClient too [20:36:00] <jtruelove> yeah that makes sense [20:36:01] <purplefox> yeah, it's poorly named [20:36:11] <jtruelove> so it is totally doable [20:36:29] <jtruelove> it's just a nice way to have one additional check of does this client really know what they want [20:36:39] <purplefox> +1 [20:37:01] <jtruelove> cool thanks for pointers [20:37:07] <purplefox> np! [20:38:21] <jtruelove> it at least allowed me to learn a bit more on the handshake stuff which is interesting but no desire to reinvent the wheel, that's a nice change in 3 [20:41:31] <purplefox> jtruelove: i think it's always good to know the nitty gritty anyway, but it's also a bonus when you don't have to implement it yourself :) later versions of websockets were more tricky to impl because of the encryption stuff [20:43:22] <jtruelove> yeah i was digging through some of the netty code where it's split out by version and things, glad i don't need to do that myself [20:50:01] <gigo1980_> does vert.x 3 require java 1.8 or does it work also with java 1.7 ?
[20:53:06] <gigo1980_> does have anyone a working pom file for vertx3 current milestone. the entries on github does not resolve [20:59:04] <Ephemeral> vertx 3 is java 8 yes. [21:16:27] <gigo1980_> and how should the current pom file looks like ?
[21:30:18] <Ephemeral> probably?
[21:30:45] <Ephemeral> in the sense you could write two verticles and start them independently probably.
[21:30:47] <Ephemeral> Try it and see.
[21:31:56] <gigo1980___> the think is, is the documentation currently good enaught for vertx 3 to start as a newbee or should i go back to vertx2 ?
[22:12:07] <jtruelove> i personally would just learn 3, the docs and examples are good and compile and run etc..
[22:12:58] <jtruelove> things have changed since 2, it's more complicated in some ways
[22:53:01] <AlexLehm> i think i missed that, have all the *-service packaged been renamed to *-client
[22:53:05] <AlexLehm> packages
[23:24:39] <AlexLehm> purplefox, i think you started the rename changes for the mail project from the wrong branch, inital-branch was merged before Julien released milestone 4 and I merged one bugfix into master after that