Differences

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

Link to this comparison view

irc:1449615600 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[08:45:11] *** ChanServ sets mode: +o temporalfox
 +
 +[10:21:43] <​aesteve>​ hi everyone !
 +
 +[10:25:06] <​pmlopes>​ hi
 +
 +[10:25:46] <​aesteve>​ made progress avout the groovy sugar stuff, and I was wondering if maybe something could be added to codegen
 +
 +[10:26:23] <​aesteve>​ In groovy, an Handler is a Closure, but what about setting the closure'​s delegate to the closure'​s parameter
 +
 +[10:27:48] <​aesteve>​ https://​github.com/​aesteve/​vertx-groovy-sugar/​blob/​master/​src/​test/​resources/​routes.groovy#​L35
 +
 +[10:28:18] <​aesteve>​ that would allow ppl to use response() directly, without calling context.response() or it.response()
 +
 +[10:30:54] <​aesteve>​ iirc that's what ratpack does
 +
 +[10:30:56] <​aesteve>​ https://​github.com/​ratpack/​example-ratpack-gradle-groovy-app/​blob/​master/​src/​ratpack/​Ratpack.groovy#​L19
 +
 +[10:32:49] <​aesteve>​ tbh, if I continue working on the sugar stuff, you'll be able to write pretty much the same Groovy stuff in Vert.x than you would with Ratpack :)
 +
 +[13:03:18] <​temporalfox>​ aesteve ​ that would be a good thing
 +
 +[13:03:59] <​temporalfox>​ the delegate thing that would rather be done in vertx-lang-groovy right ?
 +
 +[13:10:04] <​aesteve>​ hi temporalfox sorry I was away for lunch
 +
 +[13:10:24] <​aesteve>​ yes the delegate thing could be done in vertx-lang-groovy,​ I suppose
 +
 +[13:11:59] <​temporalfox>​ so what would it change ?
 +
 +[13:12:18] <​temporalfox>​ the properties would be on "​this"​ instead of the object, right ?
 +
 +[13:12:37] <​temporalfox>​ cescoffier just tried the vertx stack manager with cache, it seems much more responsive
 +
 +[13:12:41] <​temporalfox>​ where is the cache stored ?
 +
 +[13:12:47] <​aesteve>​ req.handler { ctx -> ctx.response().end('​stuff'​) }
 +
 +[13:12:49] <​aesteve>​ becomes
 +
 +[13:13:00] <​aesteve>​ req.handler { ctx -> response().end('​stuff'​) }
 +
 +[13:13:13] <​temporalfox>​ why do we still need ctx then ?
 +
 +[13:13:25] <​aesteve>​ typo, you can remove ctx idd
 +
 +[13:13:27] <​temporalfox>​ ok
 +
 +[13:13:32] <​temporalfox>​ I think we would not do that for now
 +
 +[13:13:34] <​temporalfox>​ however
 +
 +[13:13:45] <​temporalfox>​ it could be an alternative implementation
 +
 +[13:13:47] <​aesteve>​ if you mix that with response() who becomes getResponse()
 +
 +[13:14:08] <​temporalfox>​ and become later the main impl
 +
 +[13:14:13] <​aesteve>​ then you get : req.handler { response.end '​stuff'​ }
 +
 +[13:14:21] <​temporalfox>​ yes about that
 +
 +[13:14:26] <​aesteve>​ which is really cool and readable
 +
 +[13:14:34] <​temporalfox>​ I believe it would be good to have support for properties at some pont
 +
 +[13:14:50] <​temporalfox>​ although it means more annotation and error prone
 +
 +[13:15:01] <​temporalfox>​ so I have mixed feelings about it
 +
 +[13:15:11] <​temporalfox>​ yesterday [unknown:​icirc] had to make change in ceylon
 +
 +[13:15:22] <​temporalfox>​ because it transforms getToto() -> toto property
 +
 +[13:15:25] <​aesteve>​ if it's just about Groovy, get* methods would be enough
 +
 +[13:15:30] <​temporalfox>​ so it is getTotto() now like in java
 +
 +[13:15:55] <​temporalfox>​ because getOrCreateContext() was translated to orCreateContext property
 +
 +[13:16:03] <​temporalfox>​ that sucks :-)
 +
 +[13:16:23] <​aesteve>​ ah ok, I see
 +
 +[13:16:33] <​aesteve>​ Groovy does the same, but the method still exists
 +
 +[13:16:43] <​temporalfox>​ in ceylon the method is erased
 +
 +[13:17:09] <​aesteve>​ still early in my Ceylon learning, didn't know about that
 +
 +[13:18:31] <​temporalfox>​ well now it is gone :-)
 +
 +[13:18:35] <​temporalfox>​ I didn't like it that much
 +
 +[13:18:42] <​temporalfox>​ also in vertx read-only properties are
 +
 +[13:18:44] <​temporalfox>​ foo()
 +
 +[13:18:50] <​temporalfox>​ and r/w are getFoo() / setFoo()
 +
 +[13:18:56] <​temporalfox>​ so read only property where still foo()
 +
 +[13:19:09] <​temporalfox>​ but r/w prop were "​.foo"​ and ".foo = "
 +
 +[13:19:18] <​temporalfox>​ I did not like that differene
 +
 +[13:19:24] <​temporalfox>​ + the getOrCreateContext() thing
 +
 +[13:19:49] <​aesteve>​ mmh actually, this can be misleading in my Groovy implementation
 +
 +[13:20:01] <​temporalfox>​ yes
 +
 +[13:20:02] <​aesteve>​ because you can write : response += buffer
 +
 +[13:20:24] <​temporalfox>​ that's the problem of this convention
 +
 +[13:20:31] <​temporalfox>​ which is nice for java
 +
 +[13:20:51] <​temporalfox>​ perhaps we should have a getFoo() convention and code generate an api with "​foo()"​ :-)
 +
 +[13:20:58] <​temporalfox>​ I mean java api
 +
 +[13:21:11] <​aesteve>​ so Java would no longer be the top-level ?
 +
 +[13:21:19] <​aesteve>​ that sounds interesting
 +
 +[13:21:31] <​aesteve>​ an idiomatic API on top of the Java API
 +
 +[13:28:01] <​temporalfox>​ I was kidding
 +
 +[13:28:19] <​aesteve>​ I liked the idea :P
 +
 +[13:29:01] <​temporalfox>​ ok but we do it in Scala :-)
 +
 +[13:29:32] <​aesteve>​ let me get some aspirin
 +
 +[13:31:15] <​cescoffier>​ @temporalfox (changing channel again ;-)
 +
 +[13:31:27] <​temporalfox>​ why are you saying that ?
 +
 +[13:31:32] <​cescoffier>​ @temporalfox the cache is just a json file (.something.json)
 +
 +[13:31:40] <​temporalfox>​ where ?
 +
 +[13:31:44] <​cescoffier>​ @temporalfox was not expecting ping on IRC
 +
 +[13:31:50] <​temporalfox>​ .stack-manager-cache.json
 +
 +[13:31:55] <​cescoffier>​ in the current directory / VERTX_HOME if set
 +
 +[13:31:58] <​cescoffier>​ yep
 +
 +[13:31:58] <​temporalfox>​ ok
 +
 +[13:32:09] <​cescoffier>​ it just stored the path to the resolved artifact
 +
 +[13:32:10] <​temporalfox>​ we should have several .json files in the vertx
 +
 +[13:32:13] <​temporalfox>​ full
 +
 +[13:32:14] <​temporalfox>​ etc...
 +
 +[13:32:20] <​cescoffier>​ if the file is not there (anymore) it resolves it again
 +
 +[13:32:22] <​temporalfox>​ so user can easily switch to it
 +
 +[13:32:27] <​temporalfox>​ mayeb put them in a directory
 +
 +[13:32:30] <​temporalfox>​ so if someone does
 +
 +[13:32:36] <​temporalfox>​ vertx resolve whatever
 +
 +[13:32:42] <​temporalfox>​ it would look for whatever.json
 +
 +[13:32:45] <​cescoffier>​ I'm not sure about this "​profile"​ idea
 +
 +[13:32:50] <​temporalfox>​ if it's not found
 +
 +[13:32:54] <​temporalfox>​ it's not a profile
 +
 +[13:32:58] <​cescoffier>​ because it asks the user to change set the stack file
 +
 +[13:33:06] <​cescoffier>​ if he forget to set it, it's back to the default one
 +
 +[13:33:12] <​cescoffier>​ so, really error prone
 +
 +[13:33:21] <​cescoffier>​ well kind of profile stored in different file
 +
 +[13:33:27] <​temporalfox>​ it avoids the user creating new files on purpose
 +
 +[13:33:33] <​temporalfox>​ or inventing them
 +
 +[13:33:39] <​temporalfox>​ let's say I download the not full distrib
 +
 +[13:33:43] <​temporalfox>​ and I want to have "​more"​
 +
 +[13:33:56] <​cescoffier>​ you edit the exiting file
 +
 +[13:33:57] <​temporalfox>​ how do I do that ?
 +
 +[13:34:06] <​temporalfox>​ yes but you need to create the content
 +
 +[13:34:12] <​temporalfox>​ you cannot copy it from somewhere else
 +
 +[13:34:14] <​temporalfox>​ that already exists
 +
 +[13:34:15] <​cescoffier>​ "​full"​ does not really exist anymore
 +
 +[13:34:31] <​temporalfox>​ somwehre we need a list of everything user can take
 +
 +[13:34:33] <​cescoffier>​ it is just created for docker and NPM, but IMHO, it should not be distributed anymore
 +
 +[13:34:33] <​temporalfox>​ that is released
 +
 +[13:34:46] <​temporalfox>​ so perhaps we should comment some parts in the json file
 +
 +[13:34:49] <​cescoffier>​ everything he can take ? well, list the full maven repo
 +
 +[13:34:52] <​temporalfox>​ I don't know
 +
 +[13:34:57] <​cescoffier>​ no !
 +
 +[13:35:00] <​temporalfox>​ so you mean someone goes in maven central
 +
 +[13:35:05] <​cescoffier>​ open the file, everything is there, just not included
 +
 +[13:35:07] <​temporalfox>​ and find what could be the supported stuff ?
 +
 +[13:35:15] <​cescoffier>​ it's already in the file
 +
 +[13:35:25] <​temporalfox>​ ah ok
 +
 +[13:35:35] <​temporalfox>​ could we have them
 +
 +[13:35:35] <​cescoffier>​ the "​default"​ json file list all the component from the official stack (except JCA)
 +
 +[13:35:39] <​temporalfox>​ or maybe it works
 +
 +[13:35:40] <​temporalfox>​ have
 +
 +[13:35:41] <​temporalfox>​ "​included":​ true
 +
 +[13:35:50] <​temporalfox>​ be resolvable as a property
 +
 +[13:35:54] <​temporalfox>​ ${whatever}
 +
 +[13:36:18] <​temporalfox>​ and perhaps we should have a format more flexible
 +
 +[13:36:29] <​cescoffier>​ macro are not supported for included I guess (need to check) what that's rather easy to add
 +
 +[13:36:37] <​temporalfox>​ define the various versions somewhere
 +
 +[13:36:44] <​temporalfox>​ andthen have a coma separated list of the actual content
 +
 +[13:36:50] <​cescoffier>​ json is not really flexible ....
 +
 +[13:37:05] <​cescoffier>​ (missing inclusions, inheritence...)
 +
 +[13:37:20] <​temporalfox>​ like "​content":​ [ "​vertx-core",​ "​vertx-lang-ceylon",​ ... ]
 +
 +[13:37:59] <​temporalfox>​ or perhaps we need something more tooled with vertx manager
 +
 +[13:38:07] <​cescoffier>​ does not work for artifacts having the same artifact id
 +
 +[13:38:37] <​temporalfox>​ ah ok
 +
 +[13:38:48] <​cescoffier>​ but yes, the json format is not flexible enough
 +
 +[13:38:50] <​temporalfox>​ maybe we could support several descriptor files
 +
 +[13:38:57] <​cescoffier>​ HOCON would have been better I would say
 +
 +[13:38:58] <​temporalfox>​ so one can combine a vertx descriptor
 +
 +[13:39:07] <​temporalfox>​ and a "​user"​ descriptor"​
 +
 +[13:39:19] <​cescoffier>​ it's what I was trying to do in the first place (inclusion and inheritence of stacks)
 +
 +[13:39:24] <​temporalfox>​ or we do support inclusion ?
 +
 +[13:39:27] <​cescoffier>​ but this leads to non-determinitic resolution
 +
 +[13:39:40] <​temporalfox>​ well I'm just saying things are aggregated
 +
 +[13:39:40] <​cescoffier>​ json does not support inclusions (YAML did)
 +
 +[13:39:52] <​temporalfox>​ like if it were one single file
 +
 +[13:39:56] <​temporalfox>​ but it's several files
 +
 +[13:40:20] <​cescoffier>​ aggragation implieis order, this would be distrubing as it won't be the "​Same"​ order as what you would expect in Maven
 +
 +[13:40:22] <​temporalfox>​ I think what we are missing at least is a report
 +
 +[13:40:29] <​temporalfox>​ that list everything in the config file
 +
 +[13:40:38] <​temporalfox>​ and print "​yes"​ / "​no"​
 +
 +[13:40:39] <​temporalfox>​ on the console
 +
 +[13:40:49] <​cescoffier>​ well, don't forget we have transitive
 +
 +[13:40:54] <​cescoffier>​ and so it's not yes / no
 +
 +[13:40:55] <​temporalfox>​ I mean top level
 +
 +[13:41:01] <​temporalfox>​ there could be a --transitive
 +
 +[13:41:02] <​cescoffier>​ it's yes / no / already selected by
 +
 +[13:41:03] <​temporalfox>​ flag
 +
 +[13:41:09] <​cescoffier>​ no
 +
 +[13:41:21] <​cescoffier>​ not a flag, this would be a disater, transitivity is decided at the dependency level
 +
 +[13:41:36] <​temporalfox>​ without a falg then
 +
 +[13:41:46] <​temporalfox>​ something that allows easy reporting of what is actually there
 +
 +[13:41:54] <​temporalfox>​ so if someone adds new jar in libs
 +
 +[13:41:57] <​temporalfox>​ and you do a resolve
 +
 +[13:42:01] <​temporalfox>​ are these jars removed ?
 +
 +[13:43:06] <​cescoffier>​ yes
 +
 +[13:43:11] <​cescoffier>​ everything not listed is removed
 +
 +[13:43:24] <​cescoffier>​ it's the only way to cleanup things correctly
 +
 +[13:43:25] <​temporalfox>​ I think we should keep them :-)
 +
 +[13:43:32] <​cescoffier>​ if you want to add jar manually, don't use the stack manager
 +
 +[13:43:33] <​cescoffier>​ no
 +
 +[13:43:48] <​cescoffier>​ I've tried, went out of control
 +
 +[13:44:02] <​cescoffier>​ (conflicts, not understanding why a jar was still there)
 +
 +[13:44:18] <​temporalfox>​ just tried vertx resolve error
 +
 +[13:44:19] <​temporalfox>​ got
 +
 +[13:44:20] <​cescoffier>​ if you want to do stuff manually, don't use the resolver
 +
 +[13:44:20] <​temporalfox>​ https://​gist.github.com/​vietj/​c607831263ca5dec7de0
 +
 +[13:44:24] <​cescoffier>​ do it by yourself
 +
 +[13:44:24] <​temporalfox>​ it's a bit cryptic
 +
 +[13:44:37] <​temporalfox>​ " .//​Users/​julien/​java/​vertx-stack/​stack-manager/​target/​vert.x-3.2.0-SNAPSHOT/​--launcher-class=io.vertx.core.Launcher"​
 +
 +[13:44:50] <​temporalfox>​ .// should not be here if we can
 +
 +[13:44:53] <​cescoffier>​ hum, I did something wrong yesterday (missing a space)
 +
 +[13:45:01] <​temporalfox>​ and there is no extra space before "​--"​
 +
 +[13:46:13] <​temporalfox>​ perhaps this list entries should have "​\r\n"​ before
 +
 +[13:46:18] <​temporalfox>​ so they are listed
 +
 +[13:46:19] <​temporalfox>​ vertically
 +
 +[13:48:32] <​cescoffier>​ except that you have only one location if VERTX_HOME is not defined
 +
 +[13:48:46] <​temporalfox>​ ok
 +
 +[13:48:52] <​cescoffier>​ I can use \n\t - ...
 +
 +[13:49:02] <​cescoffier>​ and display only one line in this case
 +
 +[13:49:25] <​temporalfox>​ I'm wondering if we could in the vertx script start the shell and have this followed by an SSH command to this vertx instance
 +
 +[13:49:36] <​temporalfox>​ so you have an implicit console to the running instance
 +
 +[13:50:03] <​temporalfox>​ and cert would be created on the fly
 +
 +[13:51:17] <​cescoffier>​ should probably be an interactive mode
 +
 +[13:51:23] <​cescoffier>​ (--console, or --shell)
 +
 +[13:51:31] <​temporalfox>​ but would it work technically ?
 +
 +[13:51:44] <​cescoffier>​ generating certificate is always tricky, but yes
 +
 +[13:51:50] <​temporalfox>​ I don't want to manage the JVM ios for shell
 +
 +[13:51:54] <​temporalfox>​ because it's really messy
 +
 +[13:52:16] <​temporalfox>​ and need to use JVM internal features
 +
 +[13:52:18] <​temporalfox>​ like Signal
 +
 +[13:52:30] <​temporalfox>​ and hard to maintain
 +
 +[13:53:09] <​temporalfox>​ do we have documentation on the website for the stack manager ?
 +
 +[13:53:16] <​temporalfox>​ or it is only in CLI ?
 +
 +[13:54:16] <​cescoffier>​ yes the stack manager is already on the 32.0. web site
 +
 +[13:54:22] <​cescoffier>​ (in advanced)
 +
 +[19:39:54] *** ChanServ sets mode: +o temporalfox
 +
 +[20:43:08] *** ChanServ sets mode: +o temporalfox
 +
 +[21:00:29] <​befagos>​ who is using vertx in docker enviroments?​
 +
 +[21:19:28] <​aesteve>​ hi :)
 +
 +[21:19:37] <​aesteve>​ I need some advice if anyone'​s here
 +
 +[21:20:06] <​aesteve>​ https://​github.com/​aesteve/​vertx-groovy-sugar#​invoking-an-async-service
 +
 +[21:20:17] <​aesteve>​ it's a common pattern I'd like to write some sugar for
 +
 +[21:20:33] <​aesteve>​ but the '>>'​ stuff isn't self explainatory
 +
 +[21:20:39] <​aesteve>​ if anyone has an idea
 +
 +[21:20:43] <​aesteve>​ ... :/
 +
 +[21:24:01] <​aesteve>​ '​context.onSuccess'​ or '​context.asyncSuccess'​ maybe
 +
 +[22:04:42] *** ChanServ sets mode: +o temporalfox
 +
 +[22:05:30] <​Sam______>​ hi guys
 +
 +[22:14:33] <​Sam______>​ there seems to be a overall url size limit of 4kb for the httpserver. In my use case we do want to support more.
 +
 +[22:17:15] <​Sam______>​ you could make it configurable
 +
 +[22:18:10] <​AlexLehm>​ Sam______: for the request size?
 +
 +[22:18:45] <​Sam______>​ yeah
 +
 +[22:19:12] <​Sam______>​ i see it hard coded to 4096
 +
 +[22:19:14] <​AlexLehm>​ i think someone has asked for the a while back, not sure if there is a feature request for that
 +
 +[22:19:44] <​Sam______>​ yeah, i came across that
 +
 +[22:19:50] <​AlexLehm>​ i know the problem, we had a cookie issue on tomcat at some point (in my work project, which has nothing to do with vertx)
 +
 +[22:20:09] <​AlexLehm>​ if this is on the bugzilla, you could write a request
 +
 +[22:22:19] <​AlexLehm>​ no, it doesn'​t look like there is a ticket for that
 +
 +[22:23:02] <​AlexLehm>​ temporalfox:​ Julien, I think I remeber someone asked about making the request size limit configurable some time ago, but i am not sure what became of that
 +
 +[22:24:36] <​Sam______>​ what is the typical turn around time after i create a ticket?
 +
 +[22:26:36] <​Sam______>​ asking cause I could make the change and issue a pull request
 +
 +[22:27:33] <​temporalfox>​ Sam______ we plan to release soon, by end of next week
 +
 +[22:27:43] <​temporalfox>​ Sam______ make sure you follow guidlines
 +
 +[22:27:46] <​AlexLehm>​ hm, if you already have the cla for eclipse signed that is not a problem, there are a few things to observe when contributing
 +
 +[22:27:48] <​temporalfox>​ Sam______ provide a test
 +
 +[22:28:12] <​temporalfox>​ https://​github.com/​vert-x3/​wiki/​wiki/​How-to-contribute-to-Vert.x
 +
 +[22:28:18] <​temporalfox>​ if the PR is fine, that can make it
 +
 +[22:28:29] <​temporalfox>​ we will review it and comment
 +
 +[22:28:31] <​temporalfox>​ be reactive :-)
 +
 +[22:29:23] <​Sam______>​ cool, will do follow up soon. Thanks.
 +
 +[22:32:17] <​Sam______>​ i had another one I will add. Basically I did not find a way a direct way to query the scheme of the url
 +
 +[22:35:22] <​Sam______>​ the only way I saw was to use absoluteURI. But if the url is invalid the absoluteURI method fails.