[02:16:48] <s0x> hey guys, Im just trying to setup a small vertx rest service which should use a bearer token to authorize the user. Is there an easy, straight-forward way (maybe a simple example) to do so? Im struggling quite a bit with that

[02:18:52] <s0x> well, im using keycloak as auth server

[08:12:44] *** ChanServ sets mode: +o temporalfox

[09:13:43] <yunus> Hi, I created src/main/conf/application-config.json file for accessing config properties in verticle but my application cannot load it. Do you know how can load it ?

[09:31:55] <qsys> from http://vertx.io/blog/vert-x-application-configuration/ → run 'java -jar target/my-first-app-1.0-SNAPSHOT-fat.jar -conf src/main/conf/my-application-conf.json'

[09:32:18] <qsys> 'This class is reading the -conf parameter'

[10:06:23] <yunus> qsys: I know but it is not workign

[10:11:58] <cescoffier> qsys yunus - check that the fat jar manifest as a Main-Class

[10:12:04] <cescoffier> (and Main-Verticle)

[10:12:12] <cescoffier> can you give the exact stack trace

[10:12:20] <yunus> i am using gradle for making fat jar

[10:13:14] <yunus> I'll check how can i make correctly fat jar for vert.x in gradle

[10:15:42] <cescoffier> there is examples about that in vertx-example

[10:16:11] <cescoffier> yunus : https://github.com/vert-x3/vertx-examples/tree/master/gradle-verticles/gradle-verticle

[10:16:27] <yunus> cescoffier: thank you

[10:17:04] <yunus> thats great !

[13:31:25] <donghee_na> s0x there are lots of simple example of rest service

[13:32:10] <donghee_na> http://vertx.io/blog/contract-driven-rest-services-with-vert-x3/

[13:32:28] <donghee_na> is best example I ever seen

[13:35:40] <s0x> donghee_na: sry, I guess my question was not pointing out the issue i have clear enough. It's not about creating the webservice but about securing it using oauths bearer token, using keycloak as auth server

[13:44:14] <donghee_na> Hmm I am sorry I didnt read it exactly..

[14:59:50] <Philip_> Hi

[15:01:59] <Philip_> i'm a little confused by vertx-sync. Im getting an exception for calling a blocking method from an uninstumented method. The callstack trace tells me, that this method call is made from a fiberHandler

[15:02:04] <Philip_> how can that be?

[15:04:12] <Philip_> aren't fiberHandlers @Suspendable by default?

[15:10:23] <qsys> calling blocking methods in fibers will block threads, not fibers… fibers don't like to be thread blocked. I suppose: 'A fiber that is stuck in a loop without blocking, or is blocking the thread its running on (by directly or indirectly performing a thread-blocking operation) is called a runaway fiber.'

[15:11:06] <qsys> 'It is perfectly OK for fibers to do that sporadically' (from http://docs.paralleluniverse.co/quasar/ )

[15:11:34] <qsys> vertx-sync is about 'syncing async calls', not about syncing blocking calls

[15:11:43] <qsys> if I'm not mistaken…

[16:21:12] <yunus> Is vert.x run http request handler in isolated thread ? example router.route(HttpMethod.POST, “/endpoint”).handler(this::endpoint); in this definition, is vert.x create thread for per request ?

[16:54:26] <oksuz> anyone ?

[18:24:08] <pnutbutr> Is there a utility like CompositeFuture that waits until all provided Futures complete before completing?

[18:25:02] <pnutbutr> Something like CompositeFuture.all(), but something that waits until all Futures are completed before completing itself?

[18:25:29] <temporalfox> you mean even in case of failure pnutbutr ?

[18:25:39] <pnutbutr> I'm looking for a way of coordinating a list of Futures, waiting for them all to complete or fail, then responding

[18:25:49] <temporalfox> I think you should come up with your own strategy for composing them

[18:25:55] <temporalfox> and contribute it to CompositeFuture

[18:26:21] <temporalfox> so you would have your own strategy and it would be in vertx CompositeFuture in next release 3.3

[18:26:33] <pnutbutr> sounds good. I just wanted to make sure I wasn't re-inventing the wheel if it was already built somewhere

[18:27:49] <sfxplayer> Would any one know if vertx has a built in logging library

[18:30:07] <temporalfox> pnutbutr I think we have under designed the CompositeFuture strategies, meaning we just provided a couple of them and there are more needs

[18:30:32] <temporalfox> sfxplayer vertx delegates to other loggers like JDK, Log4J, SLF, etc…

[18:30:40] <temporalfox> but it has its wrapper for this of course: -)

[18:30:57] <sfxplayer> thanks

[22:20:27] <pnutbutr> what is the purpose of executeBlocking

[22:20:35] <pnutbutr> maybe I'm using it incorrectly, but it still seems to block the event loop

[22:22:02] <pnutbutr> or is that a sign that I'm using it incorrectly?

[22:26:49] <AlexLehm> you should be able to run a blocking code with executeBlocking and get the handler call when it is finished

[22:26:54] <AlexLehm> and the handler should be async

[22:28:20] <pnutbutr> I'm basically running the example here: http://vertx.io/docs/vertx-core/java/#blocking_code

[22:28:31] <pnutbutr> just to test out how it works.

[22:29:28] <pnutbutr> instead of someAPI.blockingMethod(“hello”), I'm calling a method that executes Thread.sleep(4000) to emulate a long running blocking call.

[22:30:22] <pnutbutr> I put a logger message at the start of the blocking code, so I can see when it starts in the logs.

[22:31:02] <AlexLehm> that should work, let me try

[22:31:17] <pnutbutr> in the result handler, I log when the executeBlocking has completed

[22:32:02] <pnutbutr> but if I quickly make multiple calls to my method that has the executeBlocking, the logs will say: starting blocking… (4 seconds pass) stopped blocking… started blocking (4 seconds pass) stopped blocking

[22:32:28] <pnutbutr> I thought i would show: started blocking… started blocking… stopped blocking…. stopped blocking…

[22:33:51] <AlexLehm> the executeBlocking operations are executed sequentially by default

[22:34:09] <AlexLehm> you can set a parameter to turn that off

[22:34:45] <AlexLehm> by putting a false between the blocking block and the result block

[22:36:04] <pnutbutr> ahhh, so you can only have one executeBlocking running at a time per thread?

[22:37:11] <pnutbutr> by default, that is.

[22:37:21] <pnutbutr> if I pass 'false' for ordering, I can run multiple executeBlocking's

[22:37:37] <AlexLehm> yes

[22:38:08] <pnutbutr> that fixed it. thank you sir.

[22:38:18] <AlexLehm> i think its one per context

[22:38:22] <AlexLehm> yw