Approvals: 0/1
[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