Differences

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

Link to this comparison view

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