[10:20:32] *** ChanServ sets mode: +o purplefox
[10:20:49] <cescoffier> good morning purplefox
[10:21:06] <purplefox> cescoffier: morning clement
[10:21:24] <purplefox> cescoffier: how are you?
[10:21:40] <cescoffier> I'm fine and you, how were your vacations ?
[10:22:37] <cescoffier> purplefox: FYI, paulo and julien are in vacations
[10:23:03] <purplefox> hols were good. now beginning the readjustment to work ;)
[10:23:13] <purplefox> ok, so it's just us then
[10:23:54] <purplefox> email mountain climbing in action ;)
[10:24:12] <purplefox> i think it will take me most of today to just get up to speed again
[10:24:27] <purplefox> i can see things were pretty active while i was away
[10:24:37] <cescoffier> When you have time we should discuss
[10:24:49] <cescoffier> yes, but everything went smoothly
[10:25:03] <purplefox> great
[10:25:25] <purplefox> so perhaps, after lunch, we shold have a short irc meet, status update?
[10:25:27] <cescoffier> I would like to discuss the new CLI sutff, the STOMP client and server, a PR on the vert.x 2 openshift cartridge
[10:25:41] <cescoffier> perfect
[10:26:17] <cescoffier> (oh and the redeploy feature too)
[10:58:47] <s0va> purplefox: i've written a simple patch for vertx2 to allow more human readable json for verticle configuration; i've used hjson for that. Would you consider adding merging into 3.x if i submit pull request?
[12:28:51] <Sticky> So I am having issues with the FormLoginHandler, I keep hitting this line and cant figure out why: https://github.com/vert-x3/vertx-web/blob/master/src/main/java/io/vertx/ext/web/handler/impl/FormLoginHandlerImpl.java#L86
[12:29:34] <Sticky> “Form body not parsed - do you forget to include a BodyHandler?”, where am I supposed to add a BodyHandler?
[12:47:42] <purplefox> Sticky: can you show me your router?
[12:47:56] <cescoffier> Sticky: here is an example https://github.com/vert-x3/vertx-examples/blob/master/web-examples/src/main/java/io/vertx/example/web/form/Server.java
[12:48:10] <cescoffier> look at the line 25
[12:50:08] <purplefox> s0va: hi. i'm not sure what you mean exactly by “human readable json for configuration”. do you have an example?
[12:51:15] <cescoffier> purplefox: Hjson is an extension to json to support comments, and multi line quotes
[12:51:48] <purplefox> cescoffier: we already support comments in our json config
[12:52:02] <cescoffier> yes, it's a flag in jackson
[12:52:42] <cescoffier> if people wants to use hjson or the typesafe hocon syntax they can just parse the configuration with their own tool and produce a json object to pass to the verticles
[12:52:44] <purplefox> yes, so i don't understand why a patch is necessary
[12:53:56] <cescoffier> no it's not. Integration hocon is actually one of the post I plan to write in the intro to vert.x
[12:56:28] <cescoffier> purplefox - jenkins is going to restart once there are no more job in the queue (Monday in the jenkins admin day)
[13:00:38] <Sticky> cescoffier: ahhh, yes, thats it
[13:00:43] <Sticky> purplefox: cescoffier thanks
[13:02:46] <msavy_> cescoffier, purplefox: one thing that would be nice is a jpath-style (or hocon, whatever) query syntax that allows more convenient traversing of json config (e.g. “verticle.http.port”) - particularly with nice null handling.
[13:03:35] <cescoffier> msavy_ that would require some work in the current JsonObject, but I agree, if would be a nice feature
[13:05:20] <purplefox> msavy_: can you give an example of how you would use that?
[13:05:57] <msavy_> sure
[13:05:58] <purplefox> current api is already fluent, e.g. verticle.getObject(“http”).getInteger(“port”)
[13:05:59] <msavy_> let me gist it up
[13:10:37] <cescoffier> @purplefox: the 'null' support is the important part. In your example if the json does not contains a json object in the “http” field, it will throw a NPE.
[13:11:23] <purplefox> what exception will it return with this jpath style call if there is no http in the config:
[13:11:48] <purplefox> int myInt = verticle.getJPath(“http.port”)
[13:11:48] <purplefox> ?
[13:12:26] <purplefox> s/return/throw
[13:13:41] <msavy_> https://gist.github.com/msavy/cc80ab47039010b7a9f1
[13:14:01] <msavy_> and yes, precisely - no intermediary null checking is necessary
[13:14:39] <purplefox> ok, but what does it return is the element does not exist?
[13:14:46] <purplefox> s/is.if
[13:14:54] <msavy_> it can return null at that point - that's fine
[13:15:02] <purplefox> i see
[13:15:05] <millrossjez> i'd like Optional support in Json object :)
[13:15:06] <msavy_> the problem is often that if an intermediary step returns null, it throws an NPE
[13:15:35] <millrossjez> so instead of returning null you return an Optional which could be Optional.empty :)
[13:15:36] <purplefox> well.. jsonobject allows defaults which avoids NPE too, but it's more verbose
[13:15:47] <purplefox> millrossjez: sounds like scala ;)
[13:15:51] <millrossjez> Java 8 :)
[13:16:40] <msavy_> java isn't great at this sort of config fiddling vs duck-typed languages, but that's life.
[13:16:59] <millrossjez> java 8 Optional not quite as nice as Scala option, but I suspect you could use nested flatmapping if getJsonObject returned Optional<JsonObject> (but rather depends on the final result being Optional)
[13:18:26] <millrossjez> seems to me to be a bit cleaner than handling the internal NPEs by returning a null, but maybe that's just me
[13:19:00] <purplefox> you can do this already to avoid npe but it's a bit verbose
[13:19:26] <purplefox> verticle.getObject(“http”, new JsonObject()).getInteger(“port”)
[13:27:04] <purplefox> cescoffier: any idea how to change the license that intellij uses (they have sent me a license extension now) ?
[13:29:36] <cescoffier> no idea
[13:33:15] <cescoffier> purplefox: this may help : http://stackoverflow.com/questions/26584948/how-do-i-remove-my-intellij-license
[13:37:32] <cescoffier> purplefox: in ~/Library/Preferences/IntellijVERSION/, you may have a .key file
[13:38:14] <cescoffier> remove them and restart your ide
[13:43:19] <purplefox> I'm not using OSX
[13:45:39] <monko> hey everybody. sorry for a really dumb question, i've never dealt with this particular facet of java before, even though it's one of the most basic things
[13:46:00] <monko> so, i've developed a little blog engine running on vertx and i'm trying to deploy it now
[13:46:05] <maschmid> purplefox, so look either for ~/.IntelliJIdea14/config or c:\DOS\INTELIJ\CONFIG\
[13:46:44] <monko> usually, i did this with fat jars, but the whole runnable jar with (all of) vert.x in it is 60mb, while the app alone is only ~120kb
[13:47:00] <monko> so i figured i'll just upload vert.x separately and point the classpath at it
[13:47:12] <cescoffier> purplefox- right, forgot that you are using Linux, you probably have .key files somewhere
[13:47:33] <purplefox> monko: what do you mean by “all of vert.x” ?
[13:47:34] <s0va> monko: and the question is?
[13:47:42] <monko> but running it with -cp “~/vert.x/lib” doesn't work. do i have
[13:47:49] <monko> to specify every single jar?
[13:48:02] <monko> all of vert.x = all jars in the lib directory
[13:48:05] <purplefox> monko: a simple fatrjar with vert.x is much smaller than 60MB
[13:48:07] <monko> i don't need most of it
[13:48:21] <s0va> monko: export CLASSPATH=“/path/to/jar1.jar:/path/to.jar2”
[13:48:22] <purplefox> round about 5MB
[13:48:45] <monko> so no java classpath wildcard matching on jars …
[13:49:26] <monko> CLASSPATH=“/vert.x/lib/*,jar” is out of the question?
[13:49:28] <s0va> java org.vertx.java.platform.impl.cli.Starter;
[13:49:30] <s0va> args
[13:49:58] <s0va> monko: i have a simple shell script which discovers all jars in multiple directories
[13:50:09] <s0va> adds them to CLASSPATH env variable
[13:50:27] <s0va> then it just invokes exec java org.vertx.java.platform.impl.cli.Starter “[email protected]”
[13:50:30] <s0va> and that's it
[13:50:50] <monko> okay, thanks
[13:52:31] <purplefox> s0va: here's an example of some json config with comments that we test in the Vert.x 2.x test suite:
[13:53:17] <s0va> monko: you can use this script for a template
[13:53:20] <s0va> http://pastebin.com/MEWAUMWa
[13:54:23] <s0va> purplefox: 10x
[13:54:57] <purplefox> monko: the number of jars in the lib directory depends on which distro you installed
[13:55:03] <purplefox> does your app really use all of them?
[13:55:28] <purplefox> if you use a fatjar it should only package those you actually depend on, not everything
[13:57:00] <purplefox> monko: but… if you don't want to use fatjars, just install vert.x and use the “vertx” command - there is no need to manually construct a classpath containing all the jars in the lib directory
[13:57:10] <purplefox> the “vertx” command does that for you
[13:57:23] <monko> well, this is kind of awkward
[13:57:28] <monko> (for me)
[13:57:43] <monko> because i really like distributing jars instead of using the vert.x launcher
[13:57:43] <purplefox> what is awkward>
[13:57:55] <monko> i know it goes against the spirit of vert.x
[13:58:02] <purplefox> ok, i am confused about what you want to do here
[13:58:20] <purplefox> i thought you said you'd rather just install vert.x and use that?
[13:58:26] <monko> basically “java -jar myapp.jar”
[13:58:51] <purplefox> a fat jar?
[13:59:12] <purplefox> if it's a fatjar you don't need to install anything (other than a JDK)
[13:59:17] <monko> i mean i've uploaded the vert.x lib directory and thought my slim runnable jar would use the vert.x dist on the classpath (which wont work with wildcard matching)
[13:59:48] <purplefox> just use the “vertx” command
[14:00:20] <purplefox> that will construct the classpath for you
[14:01:06] <purplefox> vertx run <yourverticlename> -cp myapp.jar
[14:02:05] <monko> there's no real reason for it, but i did construct the app as an app that embeds the vert.x server
[14:02:51] <purplefox> ok
[14:03:00] <purplefox> in that case fatjar would be simplest
[14:04:10] <monko> okay, i'll do that
[14:04:29] <monko> btw., totally different question
[14:04:43] <monko> if you've got another second
[14:04:57] <monko> i made my own templating engine - with a twist
[14:05:36] <monko> it's a preprocessor that emits java code; your templates are java files in a generated source directory
[14:06:17] <monko> upside to this approach: fast (practically only StringBuilder.append calls and a couple of loops)
[14:06:26] <monko> and ide autocompletion of placeholders
[14:06:56] <monko> downside is, of course, a separate preprocessing step every time one changes a template
[14:07:13] <monko> the thing is, my google fu left me - couldn't find anyone who did that before
[14:08:26] <monko> example: ctx.response().end(new IndexTemplate().setName(jo.getString(“name”)).setId(jo.getInteger(“id”)).toString());
[14:09:02] <monko> currently, there's support for placeholders, conditionals, blocks and includes
[14:09:41] <monko> ah, the other upside: it's nonblocking because there's no runtime IO
[14:09:54] <purplefox> sounds interesting
[14:10:30] <monko> well, if there's already a mature library out there that does this … but i couldn't find any
[14:11:45] <purplefox> not sure
[14:11:53] <monko> i'm hopefully going to publish it eventually, after brushing it up a bit. there are still a couple of kinks. and of course, i have no idea how to unit-test generated code …
[14:12:54] <purplefox> i think some template engines take a similar approach - i.e. they “compile” templates so they're not evaluated from template source each time
[14:12:55] <cescoffier> monko: it's quite similar to the template engine used by Play Framework 2
[14:13:14] <monko> okay, i'll have a look at that
[14:13:18] <cescoffier> as far as I remember, it generates a java class from their own templating language (sort of scala))
[14:13:32] <monko> most template engines i know use a kind of meta representation
[14:13:39] <monko> smarty for php
[14:13:51] <monko> but there are still external dependencies
[14:15:33] <monko> well, thanks tim - and everyone else. i'm going to build a fat jar now and get that thing running
[14:15:36] <monko> ah
[14:15:49] <monko> that reminds me, a curious occurence
[14:17:00] <monko> i tried to download youtube oembed (json) files with the vert.x HttpClient, and youtube reported a 404. worked in the browser but not with the httpclient. tried spoofing the user-agent, no dice
[14:18:02] <monko> then i swapped it out for a URLConnection via executeBlocking, and it worked
[14:18:54] <monko> the vert.x httpClient did work with different files from other hosts …
[14:19:01] <s0va> purplefox: i have a question regarding http client. what is a rationale for manually specifing host and uri separately?
[14:21:27] <purplefox> s0va: you can specify the full url too if you like. but that's going to be less efficient as it requires parsing of the uri.
[14:21:54] <purplefox> if you're making a lot of requests to the same host it's more efficient to set the host and port and provide relative uris
[14:35:37] <s0va> ok, makes sense
[14:40:46] <AlexLehm> monko: google closure templates does a bit of code generation for the variable bindings, but they do not generate java code for the compete template
[14:43:03] <monko> okay
[14:51:50] <monko> AlexLehm: looks like closure templates are a bit different again; parsing is done on startup into an intermediate representation (soy) …
[15:15:31] <purplefox> cescoffier: hey clement, wanna meet?
[15:15:41] <cescoffier> purplefox: yes, I'm ready
[15:16:08] <purplefox> great
[15:16:55] <cescoffier> so, by what do you want to start ?
[15:19:16] <purplefox> just an update on progress while I was away would be good
[15:19:32] <purplefox> or anything else you want to bring me up to date with
[15:20:41] <cescoffier> so, Julien has improved Codegen a lot, mainly because Ceylon is kind of picky with generics
[15:20:57] <cescoffier> he has also made progress on vertx-shell
[15:21:15] <purplefox> cool
[15:21:19] <cescoffier> Paulo has fixed lots of issues in vertx web
[15:21:20] <purplefox> is this a new project?
[15:21:42] <purplefox> ah yes i see it, vertx-shell
[15:22:03] <cescoffier> vertx-shell, yes it's a new project: https://github.com/vert-x3/vertx-shell
[15:22:31] <purplefox> nice. i need to try that out
[15:22:36] <cescoffier> on my side I've implemented a new 'starter'
[15:23:04] <purplefox> is it merged?
[15:23:05] <cescoffier> this is several slice of work: first I've defined a CLI system (polyglot) to parse options and arguments
[15:23:21] <cescoffier> this is going to be reused in vertx-shell (because julien don't want to reimplement the parser)
[15:23:24] <purplefox> or in a branch somewhere?
[15:23:30] <purplefox> (would like to take a look)
[15:23:50] <cescoffier> https://github.com/cescoffier/vert.x/tree/polyglot-cli
[15:24:08] <cescoffier> I will open pull request, but you will see why it's not done
[15:24:29] <cescoffier> the CLI is here: https://github.com/cescoffier/vert.x/tree/polyglot-cli/src/main/java/io/vertx/core/cli
[15:25:03] <cescoffier> 'cli' have a model that can be dinfined using java annotation if you are using java or groovy. It can also be defined using the API
[15:25:20] <cescoffier> Base on this CLI, I've made a “Command” SPI
[15:25:37] <cescoffier> (sorry Launcher SPI)
[15:25:39] <cescoffier> https://github.com/cescoffier/vert.x/tree/polyglot-cli/src/main/java/io/vertx/core/spi/launcher
[15:25:52] <cescoffier> this is what replace the Starter class
[15:26:14] <cescoffier> you can implement new 'command' for your own usage
[15:26:25] <cescoffier> this is purely java (not polyglot))
[15:27:03] <cescoffier> using this system, I've implemented the Run, Bare, Version commands (that our current one): https://github.com/cescoffier/vert.x/tree/polyglot-cli/src/main/java/io/vertx/core/impl/launcher
[15:27:25] <cescoffier> in addition, I've the start/stop/list commands (working on linux, mac and windows)
[15:28:09] <cescoffier> to use this system, it just needs to replace the Starter main class by https://github.com/cescoffier/vert.x/blob/polyglot-cli/src/main/java/io/vertx/core/Launcher.java
[15:28:28] <purplefox> it uses reflection?
[15:28:52] <cescoffier> the CLI part, yes to inject the values inside annotated setter methods
[15:29:15] <cescoffier> the rest does not use reflection (well, it uses a service loader using reflection)
[15:29:47] <cescoffier> I'm going to divide this into a set of PR, because it would be impossible to review in one
[15:29:55] <cescoffier> PR1 - the CLI
[15:29:55] <purplefox> what does reflection and annotations buy us here?
[15:30:09] <purplefox> vert.x commands are unlikely to change very often
[15:30:18] <cescoffier> it's musch easier to write vertx-shell command and SPI command
[15:31:00] <cescoffier> I agree SPI commands won't change a lot, but people can now implement their own
[15:31:13] <purplefox> true, but 99.99% of people won't do that ;)
[15:31:21] <purplefox> I'm not saying it's wrong. I need to look in more detail
[15:31:31] <cescoffier> you can probably add one or two 9.
[15:31:50] <cescoffier> but in vert.x shell people are going to write commands
[15:31:56] <cescoffier> and here, it can be very useful
[15:32:05] <purplefox> when i see annotations and reflection and lots of classes my initial reaction is to freak out a little ;)
[15:32:26] <purplefox> as you know i like things done the simplest way possible. but I accept that for vertx-shell it could make sense
[15:32:32] <cescoffier> The CLI has lots of classes, the rest is much smaller
[15:33:15] <cescoffier> if you want to see the annotaiton in action, you can look at: https://github.com/cescoffier/vert.x/blob/polyglot-cli/src/main/java/io/vertx/core/impl/launcher/commands/RunCommand.java#L55
[15:34:39] <purplefox> cool
[15:34:59] <cescoffier> so, I will divide this is several PRs.
[15:35:00] <purplefox> it certainly looks very flexible
[15:35:12] <cescoffier> I've also implemented a first version of the redeploy
[15:35:25] <cescoffier> (not in that branch, need cleanup and tests)
[15:35:39] <purplefox> sounds good
[15:35:55] <cescoffier> so, that was my first part
[15:35:57] <cescoffier> STOMP
[15:36:02] <cescoffier> I need a repo
[15:36:32] <cescoffier> I've implemented a STOMP client and server compliant with the 1.2, 1.1 and 1.0 versions of the specification
[15:37:24] <purplefox> awesome, you seem to have been on fire the last 3 weeks! :)
[15:37:25] <cescoffier> I've tested the client against ActiveMQ and RabbitMQ (both implementing the specification with let's say some freedom….)
[15:37:42] <purplefox> let me create a repo for you
[15:38:02] <cescoffier> the only last thing that is not done in STOMP is the event bus bridge
[15:38:08] <cescoffier> I think it would be a nice feature
[15:38:17] <purplefox> https://github.com/vert-x3/vertx-stomp
[15:38:20] <cescoffier> thanks
[15:38:35] <cescoffier> gonna push my work in the initial-work branch just after our meeting
[15:38:57] <cescoffier> we have a PR on the vert.x 2 openshift cartridge
[15:39:14] <purplefox> you mean bridging some stomp addresses with vert.x event bus addresses?
[15:39:29] <purplefox> agreed, that would be nice
[15:39:35] <cescoffier> yes, bidirectional like the sockJS bridge
[15:40:00] <cescoffier> I would like to 'reuse' that same type of configuraiton (inbout / outbound / match…)
[15:40:23] <purplefox> +1 this could be reused
[15:40:35] <purplefox> actually we should abstract out the transport part of the event bus bridge
[15:40:45] <purplefox> so different transports can be plugged in
[15:40:54] <purplefox> e.g. stomp, sockjs, also paulo is writing a tcp version
[15:41:04] <cescoffier> oh, something to notice on the STOMP server, you can change the behavior of almost anything by replacing the default handlers. I've made this because the specificaiton is quite unclear on some parts
[15:41:17] <cescoffier> yes, I forgot that, he is done on the TCP bridge
[15:41:30] <cescoffier> so we should look and extract a 'common' configuration format
[15:41:55] <purplefox> you guys, have been super productive. I guess I can just retire now and let you get on with it ;)
[15:42:18] <purplefox> yeah, config can be extracted but I think more than that - the code that does the security etc too
[15:42:52] <cescoffier> yes, I will have a look into that with Paulo
[15:42:58] <cescoffier> (we discussed it a bit already)
[15:43:00] <purplefox> the only thing that should be different for stomp/tcp/sockjs is the actual code that reads/writes to the transport, imho
[15:43:11] <purplefox> or something like that
[15:43:33] <cescoffier> exactly
[15:44:02] <cescoffier> Could you merge this PR: https://github.com/vert-x/openshift-cartridge/pull/16 (or give me the right)
[15:44:40] <cescoffier> this was the openshift stuff discussed on the internal mailing list. Don't ask, it's a one line fix.
[15:45:06] <purplefox> done
[15:45:15] <cescoffier> thanks
[15:45:26] <cescoffier> so, next topic, documentation.
[15:45:43] <cescoffier> I've made a small improvements to docgen, to let use write 'language' specific documentation.
[15:46:24] <purplefox> ok
[15:46:28] <cescoffier> We had this issue in vert.x web - some part of the documentation where only for java, but the ruby, js and groovy parts also contained such content
[15:46:47] <purplefox> this is different from the doc override stuff?
[15:47:29] <cescoffier> yes, the docoveride means that you replace the full 'document' by another one
[15:47:55] <cescoffier> for one line or a small section it's not optimal
[15:48:02] <purplefox> ok fair enough
[15:48:39] <cescoffier> https://gist.github.com/cescoffier/0d71d17d4bd7ed506643
[15:49:16] <cescoffier> language is a 'post-processor' we can add more if we need to
[15:49:36] <cescoffier> last point, the blog
[15:49:36] <purplefox> nice
[15:50:07] <cescoffier> technically, no big change their, just the support of admonitions
[15:50:38] <cescoffier> In term of content, I've published 2 posts from the introduction to vert.x series
[15:51:05] <cescoffier> I'm on another one right now (async & jdbc)
[15:51:34] <cescoffier> and that's all we did when you were away
[15:52:42] <cescoffier> oh last thing, I'm in vacations Friday and Monday (back to work on Tuesday)
[15:53:03] <purplefox> that's *all* you did. lol
[15:53:07] <purplefox> i think you did quite a lot
[15:53:49] <purplefox> thanks for the update
[15:53:59] <purplefox> i will probably spend the rest of today in catch up
[15:54:04] <cescoffier> so, my main issue right now is how to structure the CLI (we can separate the annotations)
[15:54:43] <cescoffier> BTW, most of our exmaples are automated now: https://vertx.ci.cloudbees.com/view/vert.x-3/job/vertx3-examples-it/
[15:55:22] <purplefox> cool
[15:55:35] <purplefox> at this rate, it won't be long before vert.x becomes sentient ;)
[15:55:41] <cescoffier> so for the CLI / Command stuff, let's wait until Julien is back (except if you want it sooner)
[15:55:55] <cescoffier> so we can see with him how it integrates with vert.x shell
[15:55:55] <purplefox> yeah we should probably wait
[15:56:07] <purplefox> he is back 24 aug?
[15:56:11] <cescoffier> yes
[15:56:20] <purplefox> and paulo is back next monday?
[15:56:25] <cescoffier> yes
[15:56:57] <cescoffier> my next task is the scala to java translation of the mysql / postgres driver
[15:57:26] <purplefox> good
[15:57:34] <purplefox> how are your scala skills?
[15:57:42] <cescoffier> okish
[15:57:51] <cescoffier> I can read scala code
[15:57:55] <purplefox> cescoffier: perhaps Narigo can help you if you get stuck
[15:58:06] <cescoffier> I can also write some but it's not as fast as writing java code
[15:58:20] <cescoffier> yes, it's plan to contact him
[15:58:47] <cescoffier> I will see how far I can go with this. I hope to have it done before Thursday night
[15:58:50] <Narigo> cescoffier, I started with porting, but time… :( if you want, I can commit the work in progress, if it helps at all
[15:59:12] <cescoffier> Narigo: please do, it will be a very good starting point
[16:00:12] <cescoffier> purplefox: I've also contacted SonarQbe to get some of our project on their Sonar server (http://nemo.sonarqube.org/)
[16:00:55] <Narigo> cescoffier, there is a “port-to-java” branch now
[16:01:22] <cescoffier> for know I've asked for vertx-shell, vertx auth, service-proxy. Let's see how it goes. Then we can have more projects
[16:01:27] <cescoffier> thanks Narigo
[16:01:29] <purplefox> +1
[16:01:49] <cescoffier> vertx-web not vertx-shell
[16:02:11] <Narigo> But there is not really much there yet. I've used a lot of scala.concurrent.Future and its ExecutionContext is a bit strange. Not sure if one can directly translate it…
[16:02:41] <cescoffier> Narigo: already played with that, it's close to the Akka system.
[16:03:12] <cescoffier> so no the is no direct way to translate it, but it's easy to turn around this
[16:03:16] <Narigo> cescoffier, the thing is that the underlying driver is written in Scala and exposes a Scala API with Futures
[16:03:32] <cescoffier> oh, I see
[16:03:39] <cescoffier> it's gonna be fun
[16:03:43] <purplefox> indeed
[16:04:06] <Narigo> Maybe you need to write a small wrapper around it in Scala that turns the Future-API into an API for Java with callbacks etc
[16:04:10] <purplefox> +1
[16:04:26] <purplefox> or (bigger job) : port the scala driver to java too ;)
[16:04:40] <purplefox> then we wouldn't need the scala runtime jar
[16:04:43] <cescoffier> purplefox: I don't have the right to push on vertx-stomp
[16:04:46] <Narigo> that would be this: https://github.com/mauricio/postgresql-async/
[16:05:23] <purplefox> cescoffier: should be ok now
[16:07:46] <cescoffier> purplefox: it is thanks
[16:12:39] <cescoffier> purplefox: It's pushed: https://github.com/vert-x3/vertx-stomp/tree/initial-work.
[16:12:48] <cescoffier> purplefox: documentation here: https://github.com/vert-x3/vertx-stomp/blob/initial-work/src/main/java/io/vertx/ext/stomp/package-info.java
[16:13:21] <cescoffier> (in ascidoc: https://github.com/vert-x3/vertx-stomp/blob/initial-work/src/main/asciidoc/java/index.adoc)
[16:13:52] <cescoffier> as I said, it supports the whole specification. So it's not tiny (don't worry, it's not big either)
[17:58:03] <jtruelove> purplefox: was there plans to more tightly integrate with kafka in vert.x 3.1? I saw it on the roadmap at some point
[17:59:47] <Sticky> I am having trouble getting the vertx-web module to track the users session between calls in tests. How does it track the session? I am adding the Cookie:“vertx-web.session=2354f2354….” headder, but doesnt seem to be working
[18:04:18] <purplefox> jtruelove: i don't think there were any plans to “tightly integrate” kafka, but a kafka client was on the roadmap at some point
[18:04:29] <purplefox> Sticky: can you show your code?
[18:06:04] <Sticky> eurgh, unfortunatly will be quite hard to show any code here, as this test is part of quite a large test framework
[18:07:01] <Sticky> If I cant get this working ill try to produce a concise test case
[18:07:28] <purplefox> there are session examples in the examples repo
[18:07:46] <purplefox> and quite a lot of info in the docs
[18:08:23] <purplefox> for simplest case you just need a cookie handler and a session handler
[18:08:30] <purplefox> as per the example above
[18:11:01] <purplefox> Sticky: also session tests here https://github.com/vert-x3/vertx-web/blob/master/src/test/java/io/vertx/ext/web/handler/SessionHandlerTestBase.java#L78
[18:18:52] <Sticky> purplefox: ok thanks, ill take a look
[18:19:52] <Sticky> I think it may be that I am using the Spring sockjs client library to test across sockjs, and that lib may not be forwarding the headders
[18:23:27] <jtruelove> purplefox: no plans for that now? I just saw it wasn't on the roadmap page any more
[18:25:01] <purplefox> jtruelove: it's not on the roadmap currently
[18:26:02] <Sticky> purplefox: ahah, yes thanks again, was due to the Spring sockjs client not setting the cookie
[18:26:54] <jtruelove> purplefox: just lack of demand? i can also update my lib to vertx 3 and make it support consuming
[18:28:25] <purplefox> it's just not high priority for the official stack. but that doesn't mean larger community can't do it :)
[18:29:14] <jtruelove> yeah totally, I'd love to hear you feedback on the promises stuff if you have any
[21:39:17] <bytor99999> Welcome back Tim. Hope you had a great vacation.