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