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

[00:17:19] <jtruelove> what are these warnings about

[00:17:20] <jtruelove> warning: Cannot find annotation method 'concrete()' in type 'VertxGen': class file for io.vertx.codegen.annotations.VertxGen not found

[00:17:30] <jtruelove> purplefox_ ^

[08:37:05] <cescoffier> pmlopes: are you around ?

[08:37:13] <pmlopes> ues

[08:37:33] <cescoffier> Did you implement the authjdbc example ?

[08:38:03] <cescoffier> (well I think, my question is more on the auth-jdbc than on the example)

[08:38:32] <pmlopes> i did the example and worked a bit on the jdbc=auth

[08:38:56] <cescoffier> it uses C3p0 which rely on a Class.forName to find the JDBC driver

[08:39:14] <cescoffier> that means it cannot use the driver passed in the isolated classloader given to the verticle

[08:39:18] <cescoffier> it needs to be in the classpath

[08:40:14] <cescoffier> (here is the stack trace:

[08:40:25] <pmlopes> humm that was done by Tim, i've no real preference on a connection pool and don't know the reasons he choose that one.

[08:40:44] <cescoffier> so in a fat jar it would work, but cannot work in a vertx run …. without having setup the JVM classpath with the jar containing the JDBC driver

[08:41:58] <pmlopes> but that will cause trouble for all jdbc code since the normal bootstrap of the driver is with a class.forname call

[08:42:40] <pmlopes> but if you put the drivers on the vertx lib dir? won't that work?

[08:43:21] <cescoffier> class.forName take a second (acutally third) argument: a custom classloader

[08:43:46] <cescoffier> that would mean updating the distribution with all the drivers

[08:44:30] <cescoffier> if this is the expected behavior it should be clarified somewhere.

[08:45:02] <pmlopes> no, we should not bundle drivers, however if someone is running without fat jars and uses jdbc stuff then we should say that they need to put the drivers on the lib folder

[08:46:57] <cescoffier> not really possible in my case

[08:48:53] <cescoffier> will try to find a way to turn around this

[08:48:53] <pmlopes> the we cannot change the the class.forName since it is c3p0 code not our code

[08:49:40] <cescoffier> I just need to check how I did it in Felix, as I've app using c3p0 and loading the driver using the bundle classloader

[09:03:30] <cescoffier> ok, so there is a way to configure c3p0 to let him use the TCCL to load the driver, so, we should just make sure the TCCL is set to the verticle classloader while initializing the first connection

[10:40:39] <cescoffier> pmlopes: do you have experience with the authorisation example ? It fails on javascript (and only on javascript)

[10:41:06] <pmlopes> which one?

[10:41:29] <cescoffier> web/authorisation

[10:41:32] <cescoffier> (not the custom one)

[10:42:19] <cescoffier> if you launch the js one

[10:42:40] <pmlopes> let me run it locally…

[10:42:51] <cescoffier> click on get a token with defcon1 authority and then click on get protected resource (defcon1 …) it fails

[10:43:11] <cescoffier> what is weird it works in groovy, java and even ruby

[10:45:07] <cescoffier> (custom_authorisation fails the same way - but it not yet automated)

[10:49:03] <pmlopes> yes it also fails on js for me, let me try to debug it. the custom probably fails on the same bug because it is a copy paste but using a callback to validate the user instead of relying on the default check

[11:13:46] <pmlopes> cescoffier i think it is a codegen issue

[11:13:59] <cescoffier> yes, probably

[11:17:26] <pmlopes> the example defines a JWTOptions object and sets the property permissions but in JS the method public JWTOptions setPermissions(List<String> permissions) is never called

[11:18:13] <pmlopes> and the constructor only receives {“expiresInSeconds”:60} no matter what you pass there

[11:27:12] <pmlopes> cescoffier did you work on the js lang? this is a rather nasty bug

[11:27:32] <cescoffier> a bit, but it's more temporalfox

[11:28:13] <pmlopes> the issue is that i get a list of parameters from the routing context as: var authorities = ctx.request().params().getAll(“authority”);

[11:28:33] <pmlopes> then if you do JSON.stringify({k: authorities}) is returns {}

[11:29:59] <cescoffier> hum….

[11:30:11] <cescoffier> this looks like a bug in the javascript support

[11:32:20] <temporalfox> how JSON.stringify could return something like that ?

[12:08:15] <pmlopes> from what i see the get all returns a List<String> and i think JSON.stringify does not like that

[18:23:31] <voidDotClass> in a websockets message, how would you implement cookies

[18:23:57] <voidDotClass> i.e how do you parse cookies

[18:38:37] <temporalfox> voidDotClass I'm don't think websockets have cookies

[18:39:00] <voidDotClass> i see a cookies header when connection is opened, but yeah. using a token method

[18:39:31] <temporalfox> voidDotClass you can use an httpRequestHandler to get the cookies

[18:39:46] <temporalfox> voidDotClass and then use the upgrade() method to obtain a ServerWebSocket from this request

[18:40:11] <temporalfox> if you mean the cookies provided before the websocket handshake

[18:40:18] <voidDotClass> see above

[22:37:34] <jtruelove> should i be using vertx

[22:39:29] <jtruelove> i'm seeing an issue with apex where it's referencing the old logger impl

[22:39:35] <jtruelove>

[22:50:36] <AlexLehm> apex has been renamed to vertx-web, it shouldn't be used anymore

[22:50:41] <AlexLehm> and the function should be the same

[22:51:37] <AlexLehm> you should be able to used 3.0.0 or 3.1-snapshot with vertx-web