This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[09:04:37] *** ChanServ sets mode: +o purplefox

[09:37:43] <pmlopes> good morning

[09:57:17] <purplefox> pmlopes: cescoffier: morning

[09:57:24] <cescoffier> good morning purplefox

[10:00:01] <cescoffier> pmlopes: do we have a swagger support ?

[10:00:07] <cescoffier> pmlopes: we have this question here: http://vertx.io/blog/some-rest-with-vert-x/index.html#comment-2190271848

[10:03:26] <pmlopes> no there is no swagger support, what i've already answered in a vertx-web issue is that one can use the yaml/json swagger file generated from the editor (editor.swagger.io) and serve it as a static file along with the swagger client as a solution to document the API but this does not guarantee that the API matches the documentation since it is not auto generated

[10:04:26] <purplefox> +1 I've never really understood what “swagger support” really means, as swagger is just a json file served by the web server

[10:05:06] <purplefox> I guess we could create a “SwaggerHandler” to make it slightly simpler

[10:05:13] <purplefox> like we currently have with a favicon handler

[10:05:28] <purplefox> that just serves a swagger.json from file or classpath

[10:07:49] <pmlopes> i think what the guys wants is what i did for yoke, but that is half baked, and requires kind of a codegen project to parse the routers and params and extra annotations to fill all the blanks expected by swagger, if we do that then people will ask the same for raml. However since both swagger and raml support having a simple yaml/json file describing all i would say that we should keep suggesting to stick to serving the file

[10:09:32] <purplefox> +1. I don't think it makes sense for vertx-web to generate the file - that's more the job of an opinionated framework

[10:09:33] <pmlopes> we should also suggest if someone from the community is interested why not make a PR to https://github.com/swagger-api/swagger-codegen (its their tool to convert the json file to a router stub)

[10:15:34] <cescoffier> yes, the generation requrie a declarative approach

[10:15:43] <cescoffier> (as jersey or whatever)

[10:16:04] <cescoffier> generally what people want it a REST client - a UI that let them test there REST API

[10:16:17] <cescoffier> but there is plenty of extension for this (at least in chrome)

[10:22:12] <cescoffier> purplefox: we may have to disable codetrans on the sync examples (java.lang.ClassCastException: com.sun.tools.javac.code.Symbol$ClassSymbol cannot be cast to javax.lang.model.element.ExecutableElement)

[10:26:24] <purplefox> cescoffier: yes, these are java only

[10:26:38] <cescoffier> ok, I will do that as well as add the snpashot repo

[10:26:52] <cescoffier> (as right now, you need vertx-sync to be installed locally to get it built)

[10:31:16] <purplefox> cescoffier: vertx-sync artifact snapshot should be in oss.sonatype

[10:31:22] <purplefox> with our other snapshots

[10:31:32] <cescoffier> yes it is

[10:31:36] <purplefox> it's created on CI

[10:31:45] <purplefox> so you shouldn't need to build locally

[10:31:51] <cescoffier> but right now the examples do not use this repository

[10:32:26] <purplefox> ah i see what you mean

[10:32:37] <purplefox> maybe we need to add the oss sonatype parent thingy in the main examples pom.xml?

[10:33:30] <cescoffier> examples need to be 'sefl-contained'

[10:33:48] <cescoffier> so if someone want to build only a part he can

[10:34:09] <purplefox> true

[10:34:14] <purplefox> so what do you suggest?

[10:34:24] <cescoffier> I've added the repo to the sync-example pom

[10:34:31] <cescoffier> (as well as disable the codetrans)

[10:34:37] <cescoffier> https://github.com/vert-x3/vertx-examples/commit/9beb808692e3d2c6b2bcc7d88485575879462843

[10:34:45] <purplefox> that seems sensible, then when we release the next relesae we can remove it

[10:34:51] <cescoffier> when it will be released, I will remove the repo

[10:35:00] <purplefox> cool, thanks

[10:36:10] <cescoffier> ok, now it builds from scratch, let's execute the examples

[10:41:20] <cescoffier> oh it requires guava.

[11:15:56] <cescoffier> purplefox: when we will introduce vertx-sync in the stack we need to be very careful. It adds some dependencies (such as guava, which may lead to conflcits in user app). It also requires to be able to load ALL classes (even isolated ones). For instance, in the mongo examples, I add to add the embedded mongodb driver and its dependencies to the classpath. It should not be required normally.

[11:16:45] <purplefox> not sure i follow - how do you mean by conflicts?

[11:17:37] <cescoffier> vertx-sync requires guava 18

[11:18:09] <cescoffier> if a user application use guava 14 (or a different versions) it may conflicts as classes have been added / removed / and updated in incompatibly ways

[11:18:46] <purplefox> well.. you could say the same about any dependency of vert.x no?

[11:19:04] <cescoffier> guava is known for this

[11:19:36] <purplefox> this is always going to be the case for a flat classpath

[11:19:40] <purplefox> same issue with netty

[11:19:42] <purplefox> jackson

[11:19:43] <purplefox> etc

[11:20:00] <cescoffier> jackson tries to keep compatibility

[11:20:15] <purplefox> netty doesn't

[11:20:18] <purplefox> neither does hazelcast

[11:20:30] <cescoffier> user app are rarely using netty directly no ?

[11:20:44] <purplefox> drivers often use netty

[11:20:46] <purplefox> clients

[11:21:26] <purplefox> i wouldn't consider this an issue. i think it's taken as read that if you have a flat classpath you need to ensure there is only one version of each library on that classpath

[11:24:02] <purplefox> what's the issue with mongo?

[11:24:15] <cescoffier> the issue with mongo is weird actually

[11:24:27] <cescoffier> I'm using en embedded mongo

[11:24:34] <purplefox> how are you running the examples?

[11:24:56] <purplefox> they run fine for me here

[11:25:02] <cescoffier> right now it's a vertx run command

[11:25:08] <cescoffier> but that should not be the issue

[11:25:14] <purplefox> ah no, you need to run them from the IDE for now

[11:25:23] <purplefox> and add the javaagent option

[11:25:24] <cescoffier> the thing is that somehow it required the driver classes in the classpath

[11:25:30] <cescoffier> or I get java.lang.NoClassDefFoundError: de/flapdoodle/embed/mongo/distribution/IFeatureAwareVersion

[11:25:41] <cescoffier> the java agent is added

[11:26:15] <purplefox> hmm, so it's not integrated with vertx run yet so I wouldn't expect it to work

[11:26:19] <purplefox> e.g. it's not in the distro

[11:26:35] <purplefox> and the scripts will need editing

[11:26:36] <cescoffier> well, this is because I'm tweaking things

[11:26:46] <purplefox> does it run in the IDE for you?

[11:26:52] <cescoffier> yes it does

[11:27:10] <cescoffier> (it's how I compute the reference execution)

[11:27:14] <purplefox> i see

[11:27:24] <cescoffier> but the IDE has access to the full classpath

[11:27:26] <purplefox> so probably there is a dependency missing from the new distro you built?

[11:27:41] <cescoffier> yes, but why should it need the driver ?

[11:27:56] <cescoffier> for example in the mongo examples of vertx-web we don't add the driver

[11:27:58] <purplefox> because the example uses it

[11:28:53] <purplefox> web-examples pom.xml does include this

[11:30:42] <purplefox> for running examples i wouldn't assume that all dependencies will be in the distro - examples might pull in other deps that aren't part of the distro

[11:30:55] <purplefox> so if you use vertx run then you'll need to add an extra -cp to add the extra bits

[11:33:33] <cescoffier> hum, if I run against my own mongo, I get another NCDFE

[11:33:40] <cescoffier> java.lang.NoClassDefFoundError: org/apache/commons/io/FileUtils

[11:35:23] <purplefox> maybe guava depends on this or something?

[11:35:50] <cescoffier> yes probably another transitive dependencies

[11:36:00] <cescoffier> the agent seems to try to eagerly load them

[11:37:17] <purplefox> i wonder… can the maven shade plugin build all the dependencies of, say, vertx-sync, into a single fat jar, and change the classnames in order to avoid class conflicts with other versions on the user classpath?

[11:38:00] <cescoffier> changing classnames would be difficult, as all dependant are going to fail

[11:38:36] <cescoffier> I did that a couple of times (rewritting classes in a different pckages, and updating the depenant), but it's rather complex and brittle

[11:42:12] <purplefox> the agent instruments the classes, i suspect that it uses FileUtils during that instrumentation process

[11:44:00] <cescoffier> yes, it's definitely possible

[11:48:44] <cescoffier> ok seems to work now with this set of dependencies: https://gist.github.com/cescoffier/2efb9a9953e0338a527f

[11:49:16] <cescoffier> if you run against a regular mongo server, no need to the flapdoodle ones and commons-compress

[11:52:38] <Sticky> I have had success in the past using shade to move classes around and updating dependents, but not having multiple versions of the same library, not sure if that is easy with shade

[15:48:02] <purplefox> cescoffier: august is such a slow month, feels like everything is going in slow motion ;)

[15:48:22] <cescoffier> :-)

[15:48:54] <cescoffier> purplefox: I got all sync test automated

[15:49:00] <purplefox> awesome

[15:49:21] <cescoffier> I also did the new loader stuff from pmlopes

[15:49:31] <cescoffier> but I need to ask him a couple of questions

[15:50:03] <cescoffier> BTW, I've made progress on STOMP, just need to hide transactions and subscriptions internal and abstract destination

[15:50:19] <cescoffier> all other comment have been handled

[15:52:04] <cescoffier> ( purplefox - and actually it's quite better in France the heat wave is gone, so people can work again )

[15:52:52] <purplefox> that's good

[15:53:02] <purplefox> 40+ degrees is too much

[15:53:22] <purplefox> I was in Italy for my holidays (the first half) and that was almost 40 degrees at times

[15:55:32] <cescoffier> purplefox: yes it's what we got here too, it's just way too much. Even the keyboard is burning

[15:59:15] <cescoffier> purplefox: if you have 5 minutes, I would like to discuss about the destination abstraction

[20:35:58] <voidDotClass> is there a blocking version of the websockets api?

[20:39:40] <Klesh> hey guys

[20:40:24] <Klesh> i was wondering if there is any project parsing body, params, query into POJOs so one doesn't have to manually fill that?