Differences
This shows you the differences between two versions of the page.
— |
irc:1430776800 [2017/05/27 13:44] (current) |
||
---|---|---|---|
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 | ||