Differences

This shows you the differences between two versions of the page.

Link to this comparison view

irc:1445205600 [2017/05/27 13:44]
irc:1445205600 [2017/05/27 13:44] (current)
Line 1: Line 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