[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:43] <temporal_> https://github.com/vert-x3/vertx-lang-ruby/blob/initial-work/src/main/resources/vertx/buffer.rb#L34

[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:53] <temporal_> https://github.com/vert-x3/vertx-lang-ruby/blob/with_java_method/src/main/resources/vertx/buffer.rb#L34

[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:44:56] <temporal_> https://github.com/vert-x3/vertx-lang-ruby/blob/initial-work/src/test/java/io/vertx/test/lang/jruby/DeployTest.java#L69

[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:08] <purplefox> http://stackoverflow.com/questions/13456017/what-does-258eafa5-e914-47da-95ca-c5ab0dc85b11-means-in-websocket-protocol

[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:22:49] <purplefox> https://github.com/eclipse/vert.x/blob/master/src/test/java/io/vertx/test/core/WebsocketTest.java#L1049

[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:16:50] <gigo1980_> because the pom vertex-core only exists for 3.0.0-dev_preview1 [21:29:36] <Ephemeral> http://mvnrepository.com/artifact/io.vertx/vertx-core [21:29:39] <Ephemeral> by opening the full thing [21:29:42] <Ephemeral> and using your eyes. [21:29:44] <Ephemeral> :I [21:29:58] <gigo1980_> ok and is it posible to mix javascript an java code in one project ?

[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:41:06] <LouKrazy> gigo1980: just started using vertx, if you come from a Java background I would say v3 makes a lot more sense than v2. I have a project that includes javascript and java together as separate verticles using shared proxy services, works really well

[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