Differences

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

Link to this comparison view

irc:1443996000 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[03:59:17] *** ChanServ sets mode: +o temporalfox
 +
 +[08:26:22] <​cescoffier>​ pmlopes: Hi, are you around ?
 +
 +[08:26:31] <​pmlopes>​ yes
 +
 +[08:26:43] <​cescoffier>​ I've added the OSGi metadata to vertx-web
 +
 +[08:27:05] <​cescoffier>​ however, there is some work to do to get the static handler working correctly
 +
 +[08:27:30] <​pmlopes>​ like what?
 +
 +[08:27:33] <​cescoffier>​ the main issue is that the FileResolver (vertx-core) does not support the bundle:// protocol (I've made a PR for that)
 +
 +[08:27:50] <​cescoffier>​ in addition the FileResolver is using the TCCL to get the classloader
 +
 +[08:28:23] <​cescoffier>​ right now I've to do something like (one sec starting the IDE....)
 +
 +[08:29:09] <​pmlopes>​ i'm finishing the jsproxy stuff, i'll get into that after, ok?
 +
 +[08:29:21] <​cescoffier>​ https://​gist.github.com/​cescoffier/​98adde5c26c52f0c16e3
 +
 +[08:29:50] <​cescoffier>​ so, I was thinking about adding a new create method taking a classloader as parameter and doing th switch internally
 +
 +[08:30:00] <​cescoffier>​ this method is not polyglot (so @VertxIgnore on it)
 +
 +[08:30:13] <​cescoffier>​ I can do it, I just want to discuss it with you first
 +
 +[08:30:39] <​cescoffier>​ something like     ​router.get("/​assets/​*"​).handler(StaticHandler.create("​assets",​ this.getClass().getClassLoader()));​
 +
 +[08:31:44] <​cescoffier>​ (it requires the PR on core to be merged first)
 +
 +[08:35:31] <​cescoffier>​ so the two "​sendFile"​ operation would be wrapped into a TCCL switch
 +
 +[08:42:20] <​cescoffier>​ pmlopes: as it's a dependency, I've also added the osgi metadata to auth-common. Other providers are not yet handled, as they require fine tuning (especially shiro). Anyway, OSGi user would probably use their own UserService
 +
 +[09:06:22] <​pmlopes>​ @cescoffier @temporalfox @purplefox jsproxygen is ready for review and also the examples have been updated with a PR waiting...
 +
 +[09:06:37] <​cescoffier>​ cool, will have a look
 +
 +[09:06:39] <​temporalfox>​ pmlopes I will review it
 +
 +[09:06:47] <​cescoffier>​ we need to discuss a better example
 +
 +[09:07:00] <​temporalfox>​ yes, one that uses connection style
 +
 +[09:07:00] <​cescoffier>​ what are the "​connection"​ requirement you would like to have
 +
 +[09:07:15] <​temporalfox>​ that's something that creates a temporary proxy
 +
 +[09:07:24] <​temporalfox>​ maybe a shopping cart ?
 +
 +[09:07:30] <​temporalfox>​ something like that
 +
 +[09:07:42] <​cescoffier>​ because I was thinking about having an example using vert-xweb and having request handling delegating to proxies
 +
 +[09:07:44] <​temporalfox>​ or a channel to a chat
 +
 +[09:07:56] <​temporalfox>​ each new proxy is a channel to a chat
 +
 +[09:07:58] <​cescoffier>​ hum, ok
 +
 +[09:08:02] <​cescoffier>​ so you create a chart with a specific id
 +
 +[09:08:09] <​cescoffier>​ the server keep a map of them
 +
 +[09:08:11] <​temporalfox>​ yes
 +
 +[09:08:20] <​temporalfox>​ and it makes routing between them
 +
 +[09:08:23] <​cescoffier>​ everytime you add a product you need to pass the id
 +
 +[09:08:31] <​temporalfox>​ ah with session :-)
 +
 +[09:08:35] <​temporalfox>​ actually now
 +
 +[09:08:45] <​temporalfox>​ on the client you create a shopping cart proxy
 +
 +[09:08:48] <​temporalfox>​ and then you add it
 +
 +[09:08:57] <​temporalfox>​ I mean you use it,it has its own id
 +
 +[09:09:12] <​temporalfox>​ and when the proxy is closed
 +
 +[09:09:22] <​cescoffier>​ if you use the proxi on the client yes
 +
 +[09:09:23] <​temporalfox>​ actually the proxy can have a checkout method
 +
 +[09:09:30] <​temporalfox>​ and in checkout the server closes the proxy
 +
 +[09:09:42] <​temporalfox>​ yes
 +
 +[09:09:45] <​pmlopes>​ for 3.2 i will replace the shim with the real vertxbus.js so tests cover the real vertxbus code
 +
 +[09:09:49] <​temporalfox>​ well that's just an ide
 +
 +[09:09:50] <​temporalfox>​ idea
 +
 +[09:10:05] <​temporalfox>​ pmlopes do you have an idea how to test this ?
 +
 +[09:10:33] <​temporalfox>​ now I was thinking using proxygen project to generate protobuff data structures :-)
 +
 +[09:11:23] <​pmlopes>​ thaat example is complicated it feels more like an integration test that a unit test...
 +
 +[09:12:09] <​temporalfox>​ now I mean after this feature
 +
 +[09:12:12] <​temporalfox>​ not really realted at all
 +
 +[09:12:20] <​temporalfox>​ but rather looking at what else we can do with proxygen
 +
 +[09:13:44] <​pmlopes>​ i am not sure how would protobuf work here, since protobuf is a encoding/​decoding protocol and proxygen is creating API implementations
 +
 +[09:14:24] <​temporalfox>​ yes you are right
 +
 +[09:14:31] <​temporalfox>​ I was only thinking for data types
 +
 +[09:14:53] <​pmlopes>​ then it would be a message codec
 +
 +[09:15:15] <​pmlopes>​ what could be interesting is a protobuf bridge
 +
 +[09:19:30] <​temporalfox>​ pmlopes so you didn't need changes in vertx-lang-js proxygen branch and this branch can be merged
 +
 +[09:19:53] <​pmlopes>​ yes i did not change anything there
 +
 +[09:19:59] <​temporalfox>​ ok
 +
 +[09:20:00] <​pmlopes>​ we can merge it
 +
 +[09:20:06] <​temporalfox>​ let me reread it
 +
 +[09:20:16] <​temporalfox>​ because as I handed this to you a few days ago
 +
 +[09:20:29] <​temporalfox>​ I'm affraid I could have left some things to clean up
 +
 +[09:20:35] <​temporalfox>​ I need to check
 +
 +[09:26:55] <​temporalfox>​ it looks good
 +
 +[09:27:02] <​temporalfox>​ perhaps you can review it too
 +
 +[09:27:10] <​temporalfox>​ and I think the only missing thing is documentation
 +
 +[09:27:29] <​temporalfox>​ at least in README.md of proxygen project
 +
 +[09:27:41] <​temporalfox>​ (besides the examples)
 +
 +[09:27:58] <​temporalfox>​ the doc say
 +
 +[09:27:59] <​temporalfox>​ "Of course, you don't *have to* use client proxies to access remote service if you don't want to. It's perfectly acceptable
 +
 +[09:28:00] <​temporalfox>​ to interact with them by just sending messages over the event bus."
 +
 +[09:28:18] <​temporalfox>​ I will add some doc here
 +
 +[09:30:54] <​temporalfox>​ perhaps we should rename proxy.js to ebproxy.js
 +
 +[09:30:56] <​pmlopes>​ i've also updated the proxygen examples
 +
 +[09:30:58] <​temporalfox>​ like for the java class
 +
 +[09:31:14] <​temporalfox>​ or vertxebproxy ?
 +
 +[09:31:19] <​temporalfox>​ A Java proxy class is generated during the compilation and is named as follows: `service_interface_simple_name +
 +
 +[09:31:19] <​temporalfox>​ VertxEBProxy`.
 +
 +[09:31:29] <​temporalfox>​ WDYT ?
 +
 +[09:32:34] <​pmlopes>​ sure ebproxy is fine i think...
 +
 +[09:32:56] <​temporalfox>​ ok
 +
 +[09:34:07] <​temporalfox>​ pmlopes so finally did you rename vertxbus.js in vertx-web ?
 +
 +[09:34:14] <​temporalfox>​ or is it still this name ?
 +
 +[09:34:30] <​pmlopes>​ still the same name
 +
 +[09:34:46] <​cescoffier>​ we can't really change the name
 +
 +[09:34:50] <​temporalfox>​ ok
 +
 +[09:34:50] <​cescoffier>​ it would break compatibility
 +
 +[09:34:57] <​temporalfox>​ it's for doc I'm asking
 +
 +[09:36:58] <​cescoffier>​ pmlopes: wrong branch for https://​github.com/​vert-x3/​vertx-examples/​pull/​92
 +
 +[09:37:07] <​cescoffier>​ it should be on the 3.1.0 branch
 +
 +[09:37:12] <​temporalfox>​ so we can say that the generated proxy is a javascript module right ?
 +
 +[09:39:39] <​cescoffier>​ I'm seeing a lot of "​list.add((char)(int)jobj);"​ in the new generated stuff
 +
 +[09:39:50] <​cescoffier>​ the double cast is a bit weird no ?
 +
 +[09:41:11] <​temporalfox>​ it's needed
 +
 +[09:41:45] <​temporalfox>​ otherwise it does not compile
 +
 +[09:41:50] <​temporalfox>​ it's java :-)
 +
 +[09:43:00] <​temporalfox>​ pmlopes I think I should add a "​static"​ method on the generated module and have a "​create"​ method instead of letting use the constructor
 +
 +[09:43:04] <​temporalfox>​ createProxy
 +
 +[09:43:28] <​temporalfox>​ like the java part
 +
 +[09:43:57] <​pmlopes>​ what do you mean in javascript?
 +
 +[09:44:43] <​temporalfox>​ instead of doing
 +
 +[09:44:43] <​temporalfox>​ var someDatabaseService = new SomeDatabaseService(eb,​ '​someaddress'​);​
 +
 +[09:44:44] <​temporalfox>​ in the client
 +
 +[09:44:46] <​temporalfox>​ do
 +
 +[09:44:52] <​temporalfox>​ var someDatabaseService = SomeDatabaseService.createProxy(eb,​ '​someaddress'​);​
 +
 +[09:46:10] <​pmlopes>​ personally i like the constructor but i don't have any argument against using a factory method
 +
 +[09:46:47] <​temporalfox>​ ok
 +
 +[09:47:02] <​temporalfox>​ I'll leave at is then
 +
 +[09:47:10] <​temporalfox>​ you are better at JS than me :-)
 +
 +[09:47:44] <​temporalfox>​ pmlopes so the generated proxy client is a JS module compatible with CommonJS, Webpack and AMD ?
 +
 +[09:48:01] <​pmlopes>​ yes
 +
 +[09:51:59] <​temporalfox>​ pmlopes I added this doc https://​github.com/​vert-x3/​vertx-service-proxy/​commit/​bf61baaaff39f176588c57dea6ca7c1eef71efa7
 +
 +[09:53:10] <​temporalfox>​ besides it all look fine to me, so you can merge these branches
 +
 +[09:56:58] <​pmlopes>​ ok
 +
 +[10:48:54] *** ChanServ sets mode: +o purplefox
 +
 +[12:53:00] <​purplefox>​ cescoffier: pmlopes: temporalfox:​ hi guys, how's it going?
 +
 +[12:53:08] <​cescoffier>​ hi purplefox
 +
 +[12:53:12] <​cescoffier>​ fine thank, and you ?
 +
 +[12:53:23] <​purplefox>​ not bad, just been doing a few performance tweaks
 +
 +[12:53:24] <​temporalfox>​ purplefox hi
 +
 +[12:55:54] <​purplefox>​ cescoffier: pmlopes: temporalfox:​ are we pretty much good for 3.1?
 +
 +[12:56:07] <​cescoffier>​ yes, 2 PR on core from me this weekend
 +
 +[12:56:28] <​temporalfox>​ Paulo finished the vertxbus.js changes for jsproxygen
 +
 +[12:56:29] <​purplefox>​ ok, will take a look
 +
 +[12:56:32] <​cescoffier>​ a (stupid) bug in the launcher command, and something about OSGi (lovely isn't it?)
 +
 +[12:56:40] <​purplefox>​ lol
 +
 +[12:56:46] <​cescoffier>​ I've added the OSGi support to vert.x web
 +
 +[12:56:47] <​temporalfox>​ and I'm need to finish finish a couple of vertx-shell examples
 +
 +[12:56:55] <​purplefox>​ ok cool.
 +
 +[12:56:55] <​cescoffier>​ and got a vert.x web app packaged as a bundle
 +
 +[12:57:14] <​cescoffier>​ I'm running a couple of tests on windows again
 +
 +[12:57:21] <​purplefox>​ i'm going to spend the rest of the day on performance. I'm going to try running on our perf machines (if i can remember how to login)
 +
 +[12:57:29] <​cescoffier>​ BTW, I've pushed the vertx-sync ahead of time support
 +
 +[12:57:40] <​cescoffier>​ so release tomorrow ?
 +
 +[12:57:47] <​purplefox>​ yes I think tomorrow
 +
 +[12:57:54] <​purplefox>​ is that ok with everyone?
 +
 +[12:58:16] <​cescoffier>​ better for me (have an appointment beginning afternoon, so I can catch up tonight)
 +
 +[12:59:35] <​temporalfox>​ sounds good to me
 +
 +[12:59:52] <​temporalfox>​ perhaps we need a bit of work on the poms to harmonize with dependencies though
 +
 +[12:59:55] <​temporalfox>​ with @cescoffier
 +
 +[12:59:56] <​pmlopes>​ @purplefox i'm just verifying the jsproxygen and merging what's missing and for js, and web i think we're ok, maybe we could merge the i18n support for web? it is not a requirement for 3.1 but could be a nice adition for i18n apps
 +
 +[13:00:03] <​cescoffier>​ temporalfox:​ I will do that today
 +
 +[13:00:11] <​cescoffier>​ I've started a bit this weekend in web and auth
 +
 +[13:00:21] <​temporalfox>​ cescoffier ok then we can discuss the dependencies to exclude and align
 +
 +[13:00:30] <​temporalfox>​ like in dropwizard I think there is one
 +
 +[13:00:34] <​cescoffier>​ will send you the conflict we have on our "​private"​ channel (understand slack) and we can discuss what we do
 +
 +[13:01:13] <​cescoffier>​ pmlopes: i18n looks good to me, you wanted to give it another spin
 +
 +[13:01:37] <​pmlopes>​ ok, i'll check it
 +
 +[13:01:38] <​cescoffier>​ pmlopes: I've made the change we discussed this morning on vert.x web, will submit a PR (once the core PR is merged)
 +
 +[13:34:54] <​pmlopes>​ ok, thanks
 +
 +[14:17:02] <​gobbler>​ can i mix the use of io.vertx.ext.jdbc in sync and async mode?
 +
 +[14:18:21] <​gobbler>​ i want to facilitate the pool and async handlers but will use jdbc in an executeBlocking() block - is there another way to do it?
 +
 +[14:59:41] *** ChanServ sets mode: +o temporalfox
 +
 +[15:24:47] <​purplefox>​ temporalfox:​ i've just noticed that core is using netty 4.0.28.final,​ but the latest version is netty 4.0.32.final
 +
 +[15:24:50] <​purplefox>​ we should upgrade
 +
 +[15:25:07] <​temporalfox>​ I believe we should be using 4.0.31
 +
 +[15:25:31] <​temporalfox>​ <​netty.version>​4.0.31.Final</​netty.version>​
 +
 +[15:25:49] <​temporalfox>​ that's the version we can use with Eclipse right now
 +
 +[15:27:45] <​purplefox>​ ok
 +
 +[15:28:39] <​purplefox>​ we should check all the deps to make sure we've upgraded to the latest
 +
 +[15:28:50] <​purplefox>​ including other components in the stack
 +
 +[15:28:56] <​temporalfox>​ I"ve done that 3 weeks ago for core
 +
 +[15:30:17] <​cescoffier>​ purplefox, temporalfox : finally back
 +
 +[15:30:23] <​cescoffier>​ going to look at the dependencies
 +
 +[15:32:35] <​temporalfox>​ purplefox cescoffier ​ see https://​groups.google.com/​forum/#​!msg/​vertx-dev/​L3tt2F94jTs/​oppeYE6VAAAJ
 +
 +[15:33:04] <​temporalfox>​ note I haven'​t ugpraded MVEL
 +
 +[15:33:13] <​temporalfox>​ it's not critic
 +
 +[15:33:19] <​cescoffier>​ we cannot upgrade these to another version (IP clearance)
 +
 +[15:33:32] <​temporalfox>​ it would take some time to do it
 +
 +[15:40:22] <​cescoffier>​ pmlopes: here it is: https://​github.com/​vert-x3/​vertx-web/​pull/​209
 +
 +[16:41:21] <​purplefox>​ cescoffier: temporalfox:​ pmlopes: Don't think I'm going to get any more perf out of vert.x as long as we use Netty
 +
 +[16:41:42] <​purplefox>​ but we're doing ok, somewhat faster than vert.x 2 for simple http
 +
 +[16:41:53] <​cescoffier>​ well, it's great
 +
 +[16:42:05] <​purplefox>​ about 1.75 M req/s on my new laptop
 +
 +[16:42:52] <​purplefox>​ faster on real servers (around 3M)
 +
 +[16:52:49] <​purplefox>​ cescoffier: temporalfox:​ pmlopes: ok I've finished with perf now. Is there anything you guys want any help with?
 +
 +[16:53:05] <​cescoffier>​ I'm on the maven dependencies
 +
 +[16:53:29] <​cescoffier>​ I think we will need a blog post about the 3.1 release
 +
 +[16:53:31] <​purplefox>​ ah, btw we were already using netty 4.0.31 - i was looking at an old branch, lol :(
 +
 +[16:53:50] <​temporalfox>​ purplefox yes I was surprised when you said that :-)
 +
 +[17:08:59] <​temporalfox>​ purplefox perhaps you can help debug some JS problem
 +
 +[17:21:01] <​purplefox>​ temporalfox:​ sure
 +
 +[17:22:40] <​temporalfox>​ pull the 3.1.0-SNAPSHOT branch in vertx-examples
 +
 +[17:22:42] <​temporalfox>​ then run
 +
 +[17:23:08] <​temporalfox>​ io.vertx.example.util.Runner#​JSHelloWorldRunner()
 +
 +[17:23:19] <​temporalfox>​ you should have an undefined related error in utils.js
 +
 +[17:23:25] <​temporalfox>​ hard to figure out what is going on
 +
 +[17:23:30] <​purplefox>​ ok
 +
 +[17:23:32] <​temporalfox>​ js debug does not work in my IDE
 +
 +[17:26:56] <​purplefox>​ which Runner class? there are many in vertx-examples
 +
 +[17:28:08] <​purplefox>​ temporalfox:​ ^
 +
 +[17:28:20] <​temporalfox>​ ah sorry
 +
 +[17:28:32] <​temporalfox>​ they are all in same package :-)
 +
 +[17:28:35] <​purplefox>​ yes
 +
 +[17:28:35] <​temporalfox>​ vertx-shell :-)
 +
 +[17:30:35] <​purplefox>​ vertx-examples doesn'​t even compile for me
 +
 +[17:30:41] <​purplefox>​ in that branch
 +
 +[17:31:04] <​temporalfox>​ why ?
 +
 +[17:31:07] <​purplefox>​ mvn clean install at command line fails
 +
 +[17:31:16] <​temporalfox>​ what error ?
 +
 +[17:31:26] <​purplefox>​ [ERROR] /​home/​tim/​projects/​vert-x3/​vertx-examples/​web-examples/​src/​main/​java/​io/​vertx/​example/​web/​jdbc/​Server.java:​[76,​19] cannot find symbol
 +
 +[17:31:26] <​purplefox>​ [ERROR] symbol: ​  ​method fail(java.lang.Throwable)
 +
 +[17:31:27] <​purplefox>​ [ERROR] location: variable done of type java.lang.Void
 +
 +[17:31:56] <​temporalfox>​ same here :-)
 +
 +[17:32:17] <​purplefox>​ well i can't do much unless the branch compiles ;)
 +
 +[17:32:29] <​temporalfox>​ yes
 +
 +[17:32:35] <​temporalfox>​ you can reproduce it
 +
 +[17:32:37] <​temporalfox>​ in vertx-shell
 +
 +[17:32:39] <​temporalfox>​ hold on
 +
 +[17:32:40] <​temporalfox>​ simpler
 +
 +[17:32:43] <​temporalfox>​ I reproduced it
 +
 +[17:32:47] <​temporalfox>​ I just need to push the example
 +
 +[17:33:05] <​temporalfox>​ and you can even run it from IDE
 +
 +[17:33:51] <​temporalfox>​ https://​github.com/​vert-x3/​vertx-shell
 +
 +[17:34:07] <​temporalfox>​ then run io.vertx.ext.shell.JSTest#​main in IDE
 +
 +[17:34:16] <​temporalfox>​ (perhaps you need initial compilation because of @DataObject
 +
 +[17:34:35] <​purplefox>​ that examples branch is barfed
 +
 +[17:34:39] <​temporalfox>​ yes
 +
 +[17:35:24] <​temporalfox>​ ah
 +
 +[17:35:30] <​temporalfox>​ in examples it's the change of
 +
 +[17:35:32] <​temporalfox>​ routingContext.addHeadersEndHandler
 +
 +[17:35:52] <​temporalfox>​ before done was a Future now it's Void
 +
 +[17:36:02] <​temporalfox>​ anyway it's not related ot the JS error ^^
 +
 +[17:36:16] <​purplefox>​ which branch in vertx-shell?​
 +
 +[17:36:38] <​temporalfox>​ master
 +
 +[17:36:52] <​temporalfox>​ it's a main I added
 +
 +[17:36:54] <​temporalfox>​ to reproduce
 +
 +[17:38:24] <​purplefox>​ ok i get this:
 +
 +[17:38:25] <​purplefox>​ javax.script.ScriptException:​ TypeError: undefined is not an Object in .vertx/​debug-js/​vertx-js/​util/​utils.js at line number 221
 +
 +[17:39:51] <​temporalfox>​ yes
 +
 +[17:39:58] <​temporalfox>​ that's the current problem
 +
 +[17:40:05] <​purplefox>​ ok, will take a look
 +
 +[17:41:04] <​purplefox>​ btw, js debugging works ok for me here :)
 +
 +[17:41:20] <​temporalfox>​ yes for me too but not in util.js
 +
 +[17:45:17] <​purplefox>​ where do i find the command.js file?
 +
 +[17:45:46] <​temporalfox>​ in vertx-shell-js/​command.js
 +
 +[17:45:52] <​temporalfox>​ in src/​main/​resources
 +
 +[17:47:19] <​temporalfox>​ https://​github.com/​vert-x3/​vertx-shell/​blob/​master/​src/​main/​resources/​vertx-shell-js/​command.js
 +
 +[17:58:16] <​purplefox>​ temporalfox:​ the problem seems to be in command_builder.js:​ build function
 +
 +[17:58:21] <​temporalfox>​ yes
 +
 +[17:58:30] <​temporalfox>​ you mean generated code ?
 +
 +[17:58:34] <​purplefox>​ evaluation of:
 +
 +[17:58:35] <​purplefox>​ j_commandBuilder["​build()"​]()
 +
 +[17:58:38] <​purplefox>​ returns undefined
 +
 +[17:58:48] <​purplefox>​ which causes the utils method to barf
 +
 +[17:59:13] <​temporalfox>​ maybe nashorn bug ?
 +
 +[17:59:55] <​temporalfox>​ ah I know
 +
 +[18:00:01] <​purplefox>​ where is the implementation of that method?
 +
 +[18:00:19] <​temporalfox>​ actually I don't know
 +
 +[18:00:29] <​temporalfox>​ in CommandBuildImpl
 +
 +[18:00:47] <​temporalfox>​ is it the anonymous inner class ?
 +
 +[18:00:54] <​temporalfox>​ the impl does
 +
 +[18:00:55] <​temporalfox>​ return new Command() {
 +
 +[18:01:10] <​purplefox>​ so you return a Command instance
 +
 +[18:01:21] <​purplefox>​ then you try to execute it as a javascript function
 +
 +[18:01:46] <​purplefox>​ not sure what you're trying to achieve here
 +
 +[18:01:53] <​temporalfox>​ in java ?
 +
 +[18:02:22] <​purplefox>​ no js
 +
 +[18:02:48] <​purplefox>​ can you explain to me what:
 +
 +[18:02:49] <​purplefox> ​ j_commandBuilder["​build()"​]
 +
 +[18:02:53] <​purplefox>​ is supposed to return?
 +
 +[18:03:34] <​temporalfox>​ it is supposed to return an impl of io.vertx.ext.shell.command.Command object
 +
 +[18:03:46] <​temporalfox>​ that nashorn then wraps writh a command.js
 +
 +[18:03:49] <​purplefox>​ what is j_commandbuilder?​
 +
 +[18:04:11] <​temporalfox>​ the wrapped instance of io.vertx.ext.shell.command.CommandBuilder
 +
 +[18:04:30] <​purplefox>​ so j_commandbuilder is a java object
 +
 +[18:04:34] <​purplefox>​ instance of CommandBuilder
 +
 +[18:04:51] <​purplefox>​ you then try to apply the array (index) operator to it...
 +
 +[18:04:58] <​purplefox>​ passing in "​build()"​
 +
 +[18:05:04] <​purplefox>​ what's the intention there?
 +
 +[18:05:42] <​purplefox>​ are you trying to get a reference to the build() method?
 +
 +[18:05:54] <​temporalfox>​ this is nashorn api to get a method reference
 +
 +[18:05:56] <​temporalfox>​ indeed
 +
 +[18:06:05] <​temporalfox>​ for precise method dispatch
 +
 +[18:06:35] <​temporalfox>​ and the invocation works
 +
 +[18:06:58] <​temporalfox>​ if I put a breakpoint in build() of CommandBuilder is is invoked
 +
 +[18:07:03] <​temporalfox>​ and returns a Command implementation
 +
 +[18:08:09] <​temporalfox>​ actually are you sure it's the problem ?
 +
 +[18:08:19] <​temporalfox>​ the line that has undefined error for me is
 +
 +[18:08:19] <​temporalfox>​ var obj = Object.create(constructorFunction.prototype,​ {});
 +
 +[18:08:27] <​temporalfox>​ jdel is not used in this line
 +
 +[18:09:32] <​temporalfox>​ as I can see it, undefined is either Object or constructorFunction
 +
 +[18:11:20] <​temporalfox>​ are you able to have debug info of what is going on in utils.js convReturnVertxGen method ?
 +
 +[18:11:28] <​temporalfox>​ bah I'm going to rebuild vertx-lang-js
 +
 +[18:11:29] <​temporalfox>​ directly
 +
 +[18:11:32] <​temporalfox>​ and add debug statements
 +
 +[18:11:33] <​temporalfox>​ simpler
 +
 +[18:13:13] <​purplefox>​ yes, the protype of "​Command"​ is undefined
 +
 +[18:13:29] <​temporalfox>​ and it is not in the calling method I think
 +
 +[18:13:37] <​purplefox>​ it's basically not a constructor function
 +
 +[18:13:54] <​purplefox>​ let me look at Command
 +
 +[18:14:31] <​temporalfox>​ maybe an module trickery ?
 +
 +[18:15:47] <​temporalfox>​ (require)
 +
 +[18:15:52] <​temporalfox>​ ah
 +
 +[18:16:03] <​temporalfox>​ perhaps it's the fact that Command references CommandBuilder and vice versa
 +
 +[18:16:48] <​temporalfox>​ I'm pretty sure it is this case
 +
 +[18:24:33] <​temporalfox>​ ah I see
 +
 +[18:24:38] <​temporalfox>​ I jsut read that
 +
 +[18:24:38] <​temporalfox>​ http://​know.cujojs.com/​tutorials/​modules/​authoring-cjs-modules
 +
 +[18:25:03] <​temporalfox>​ it explains that if we export directly functions we create module that don't support circular dependencies
 +
 +[18:25:29] <​temporalfox>​ basically module.exports = Command is this scheme
 +
 +[18:26:18] <​temporalfox>​ I can workaround this problem I think in the api by breaking the circular deps at this level
 +
 +[18:26:40] <​temporalfox>​ however it means that codegen for JS has limitations for circular dependencies
 +
 +[18:28:50] <​temporalfox>​ and either we should forbid that or find a way to make it work
 +
 +[18:29:12] <​temporalfox>​ (or warn when there is one)
 +
 +[18:29:25] <​temporalfox>​ that being said I'm not a JS module expert
 +
 +[18:31:34] <​temporalfox>​ ok problem solved on vertx-shell side by moving builder() method to CommandBuilder
 +
 +[18:31:59] <​temporalfox>​ I can create an issue in Vertx-lang-js about this issue
 +
 +[18:41:58] <​purplefox>​ cool
 +
 +[18:52:55] <​temporalfox>​ I think we can have a solution like lazy init of the refs
 +
 +[18:52:58] <​temporalfox>​ break
 +
 +[18:52:59] <​temporalfox>​ var Command = require('​vertx-shell-js/​command'​);​
 +
 +[18:53:06] <​temporalfox>​ in decl = late assignment
 +
 +[18:53:08] <​temporalfox>​ in such case
 +
 +[18:53:28] <​temporalfox>​ but codegen would need to provide such info
 +
 +[18:53:35] <​temporalfox>​ probably for 3.2
 +
 +[21:55:59] *** ChanServ sets mode: +o purplefox
 +
 +[22:51:26] <​Hansel>​ I am following this thread, and wanted to hear some of your opinions before I choose a JVM framework for my next project. I am still gathering feedback and deciding on pros/cons.
 +
 +[22:51:27] <​Hansel>​ https://​www.reddit.com/​r/​java/​comments/​3nl3uv/​advice_on_which_jvm_web_framework_to_choose_for/​