[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.