[05:58:01] * ChanServ sets mode: +o temporalfox [06:13:42] * ChanServ sets mode: +o temporalfox

[08:56:02] * ChanServ sets mode: +o temporalfox [11:48:58] <simonbasle> greeting VertX people! I was wondering if Codegen would still make sense/be usable on a plugin around an RxJava-based API? [12:07:03] <cescoffier> simonbasle: can you elaborate ? vertx-rx is generated by codegen [12:07:16] <cescoffier> (part of the API) [12:08:48] <simonbasle> cescoffier: I'm looking into implementing a Couchbase client plugin for vertx, and the Couchbase SDK is naturally async and exposes RxJava methods [12:10:08] <cescoffier> simonbasle: I'm not sure you need codegen for this, but follow the approach we use in the other clients (jdbc-client, mongo-client…) [12:14:02] <simonbasle> cescoffier: convert the Observable to Handler<AsyncResult<T»? [12:15:08] <cescoffier> simonbasle: yes, something like that, look at https://github.com/vert-x3/vertx-rx/tree/master/rx-java [12:21:50] <simonbasle> mmh ok, the wrapping should be simple enough that it is not too wasteful to go Observable → Handler<AsyncResult> → Observable again [12:39:19] <simonbasle> looks like for Mongo there was a Facade built around the client, is that enforced because of the types supported by vertx? [12:39:27] <simonbasle> the Couchbase API has quite a large number of methods :( [15:02:30] <temporalfox> simonbasle you cannot expose rxjava as is in polyglot stuff [15:03:42] <simonbasle> makes sense, there has to be a “lingua franca”, that happens to be java with AsyncResult :) [15:54:41] <tsegismont> Hi everyone [15:55:09] <tsegismont> I'm writing tests for the Hawkular integration module [15:55:37] <tsegismont> I want to write integration tests in Groovy [15:56:15] <tsegismont> in order to user vertx groovy APIs [15:56:43] <tsegismont> I should add vertx-lang-groovy in test scope in my POM file [15:56:46] <tsegismont> Is that all? [16:02:44] <tsegismont> it seems so [16:09:41] <tsegismont> cescoffier, hi [16:09:46] <tsegismont> might be a silly question [16:09:56] <tsegismont> I'm trying to start a test straight from IJ [16:10:02] <tsegismont> I have “Erreur : impossible de trouver ou charger la classe principale @{surefireArgLine}” [16:10:11] <cescoffier> tsegismont: Hi [16:10:32] <tsegismont> Must be something stupid [16:10:42] <cescoffier> you need to uncheck something in intellij [16:10:48] <tsegismont> ha [16:11:19] <cescoffier> Here it is: https://github.com/vert-x3/vertx-ext-parent/issues/7 [16:11:30] <cescoffier> see my first comment [16:13:31] <tsegismont> perfect, thx cescoffier ! [16:14:48] <cescoffier> you're welcome ! [17:12:06] <tsegismont> I have a VertxHawkularOptions which extends MetricsOptions [17:12:20] <tsegismont> VertxHawkularOptions is annotated with @DataObject(generateConverter = true, inheritConverter = true) [17:12:45] <tsegismont> now, one of VertxHawkularOptions fields is a HttpClientOptions object [17:13:32] <tsegismont> Shouldn't the generated VertxHawkularOptionsConverter#fromJson method handle HttpClientOptions ? [17:14:00] <tsegismont> io.vertx.codegen.annotations.DataObject Javadoc says: [17:14:02] <tsegismont> Properties types can be: [17:14:08] <tsegismont> a valid data object type [17:17:53] <temporal_> yes it should be [17:17:56] <temporal_> perhaps it's a bug [17:18:01] <temporal_> give me a reproducer [17:18:25] <temporal_> normally it works, for instance TCPSSLOptions has nested options [17:18:29] <temporal_> and the converter handle them [17:20:07] <tsegismont> temporal_, sorry, I'm still in week end mode… I had forgotten the getter and setter in VertxHawkularOptions, now it works [17:20:16] <temporal_> [21:21:21] <chirino> purplefox: hey [21:21:29] <chirino> I like where https://github.com/purplefox/vertx-proton is going [21:22:05] <chirino> one thing to consider is that the proton sessions can remain decoupled from sockets [21:22:48] <chirino> so the api might want to basically keep those two things kinda separated. [21:23:25] <chirino> you can basically do work on an AMQP connection while disconnected from a socket [22:05:38] * ChanServ sets mode: +o purplefox

[23:39:36] <jtruelove> temporal_ running in to an issue with SPI

[23:39:44] <temporal_> hi

[23:39:53] <temporal_> what is it ?

[23:40:24] <jtruelove> when the event bus metrics hook is called aka public EventBusMetrics createMetrics(EventBus eventBus)

[23:40:37] <jtruelove> the eventBus is null on the vertx instance

[23:41:17] <jtruelove> which i use to give each metrics implementor a publisher which takes an event bus ref

[23:41:50] <jtruelove> seems there is a valid eventBus on the vertx instance otherwise for the other hooks

[23:42:19] <temporal_> perhaps this is realted to recent event bus refactor

[23:42:44] <temporal_> dropwizard seems to fail also

[23:43:01] <temporal_> https://vertx.ci.cloudbees.com/view/vert.x-3/job/vert.x3-dropwizard-metrics/

[23:43:10] <temporal_> this is perhaps related

[23:43:25] <temporal_> can you provide a failing test for vert.x core that reproduce it ?

[23:43:50] <jtruelove> just try stepping in to your InfluxDb sample

[23:43:52] <paulecoyote> Hello, I want to deploy a verticle from a subfolder from java source - path to the .java file would seem to be correct, but I wonder if it has to be in the classpaths or something?

[23:43:57] <temporal_> influxdb is old

[23:44:12] <jtruelove> it implements that interface though

[23:44:25] <jtruelove> VertxMetrics

[23:44:40] <temporal_> I mean it has not been updated since 3.0 milestone or something

[23:45:02] <jtruelove> yeah i'm running against 3.0 stable

[23:45:13] <temporal_> paulecoyote what do you use as deploy path ?

[23:45:29] <jtruelove> io.vertx:vertx-core:3.0.0 specifically

[23:45:48] <temporal_> ok

[23:45:50] <temporal_> why not 3.1 ?

[23:46:04] <jtruelove> it's released yet?

[23:46:12] <jtruelove> err is it i meant

[23:46:43] <temporal_> yes

[23:46:56] <jtruelove> ah didn't think it was out yet

[23:48:08] <temporal_> it was released 2w ago

[23:48:49] <jtruelove> gotcha thought it was still in flight, i'll try it real fast with 3.1 and let you know if it still happens

[23:49:18] <temporal_> ok

[23:49:38] <paul_e_coyote> sorry they are messing around with the internet here

[23:49:43] <paul_e_coyote> got dc'ed

[23:50:15] <paul_e_coyote> so was using “pipeline/Hello.java”

[23:51:09] <paul_e_coyote> also tried building a path up to that file via the current working directory

[23:51:42] <paul_e_coyote> so say ./resources/example/pipeline/Hello.java

[23:53:02] <paul_e_coyote> I also tried to pass an extra classpath via cp that was relative so ./resources/example/java

[23:53:08] <paul_e_coyote> for pipeline/Hello.java

[23:55:09] <temporal_> let me check

[23:55:44] <jtruelove> temporal_ bug is still there in 3.1

[23:55:48] <paul_e_coyote> I was trying to figure out how Starter.java works in io.vertx.core - but my Java is way rusty

[23:57:33] <jtruelove> my guess is createMetrics on VertxMetricsImpl gets called before the eventbus is created or initialized on the vertx instance

[23:58:18] <temporal_> that is possible

[23:58:35] <temporal_> I think in the impl at the moment we don't use it

[23:58:42] <temporal_> paul_e_coyote it works for me

[23:59:15] <temporal_> public class Test extends io.vertx.core.AbstractVerticle { }

[23:59:20] <temporal_> in foo/Test.java

[23:59:31] <temporal_> and

[23:59:42] <temporal_> vertx.deployVerticle(“foo/Test.java”, function(res,err) { console.log(res); console.log(err); });

[23:59:44] <temporal_> in test.js

[23:59:46] <temporal_> when I do

[23:59:48] <jtruelove> the interesting bit is the interface on Impl takes an EventBus

[23:59:49] <temporal_> vertx run test.js

[23:59:52] <temporal_> it deployes the verticle