Differences

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

Link to this comparison view

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