Differences

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

@@ Line 1: / Line 1: @@
+[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