This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[10:28:39] *** ChanServ sets mode: +o purplefox

[13:34:45] <BadApe> with a stomp server is it possible to send a message down to the client?

[15:37:52] <thanos> hello there, I am wondering if you can help me!

[15:37:54] <thanos> vertx.createHttpClient().getNow(url.getPort(), url.getHost(), “/groups/”+Config.getGroupId()+“/cars”, new Handler<HttpClientResponse>() { public void handle(HttpClientResponse httpClientResponse) { httpClientResponse.bodyHandler(new Handler<Buffer>() { public void handle(Buffer buffer) { logger.debug(“Response (” + buffer.length() + “): ”); logger.debug(buffer.getStrin

[15:39:31] <thanos> I have this code and I would like to get the REST reply and return a WSDL object after a transformation, the goal is to take the rest reply and transform it to a SOAP reply to another service

[15:51:26] <D-Spair> thanos: Could you put that up as a Gist so it's easier to read please?

[15:51:34] <D-Spair> Or PasteBin?

[15:54:04] <thanos> Hello D-Spair, it is the first time I get here, I do not really know how to do that even though I understand it does not look good in this format :(

[15:55:29] <thanos> My questions are : return the reply of the rest service is “bad” for the vert.x asynchronous style of programming?

[15:57:05] <thanos> vertx.createHttpClient().getNow(url.getPort(), url.getHost(), “/groups/”+Config.getGroupId()+“/cars”, new Handler<HttpClientResponse>() { public void handle(HttpClientResponse httpClientResponse) { httpClientResponse.bodyHandler(new Handler<Buffer>() { public void handle(Buffer buffer) { logger.debug(“Response (” + buffer.length() + “): ”); logger.debug(buffer.getString(

[15:57:59] <D-Spair> thanos: Open a web browser, go to and paste your code, submit it and copy the link here.

[15:58:56] <thanos>

[15:59:30] <D-Spair> OK, now I can readit…

[15:59:37] <thanos> great :)

[15:59:53] <D-Spair> So what is your question/problem? It looks OK to me so far.

[15:59:53] <thanos> return the reply of the rest service is “bad” for the vert.x asynchronous style of programming?

[16:00:16] <D-Spair> Not particularly.

[16:00:31] <D-Spair> But you can't just “return” it..

[16:00:55] <D-Spair> You have to have a reference to the SOAP session on which you want to send the response.

[16:01:04] <thanos> actually I need to get the reply which I can get fine with this code, and then transform it to a SOAP object

[16:01:29] <D-Spair> Well, transforming it into a SOAP object if beyond the capabilities of Vert.x

[16:01:35] <D-Spair> s/if/is/

[16:01:45] <thanos> yes I know, I was wondering just about the return

[16:01:54] <D-Spair> Vert.x, as far as I know, does not have a SOAP implementation.

[16:02:13] <thanos> OK then you answered to my question, that's great

[16:02:48] <D-Spair> thanos: You could, however, use Vert.x in conjunction with another Java library for doing SOAP…

[16:03:15] <D-Spair> For example, you could wire up your Vert.x code to CXF or another SOAP library.

[16:03:27] <D-Spair> Or use Apache Camel and it's Vert.x component.

[16:03:27] <thanos> thank you. Actually I am new to vert.x and asynchronous programming and I wanted to see if there is a channel available for help since I am alone on this project

[16:04:08] <thanos> ah camel, I will check this out

[16:04:30] <D-Spair> Camel would probably be your easiest path: Then you could do something like SOAP Request→Camel→Vert.x→Camel→SOAP Response

[16:04:53] <D-Spair> Camel already has SOAP components and Vert.x components baked in.

[16:05:18] <thanos> that's great, I am checking this right now

[16:05:21] <D-Spair> Though SOAP is not the simplest thing in the world to use…. :(

[16:05:31] <thanos> I know but I have to :)

[16:05:49] <D-Spair> I understand, been there a few times…

[16:06:16] <D-Spair> Stupid VMware and their stupid antiquated SOAP API… GRUMBLE…

[16:08:30] <thanos> so I am having a problem now, if you see my code, there is this jsonReply I want to return

[16:08:48] <thanos> jsonReply is defined outside of this block of code

[16:09:09] <thanos> so when I get this in eclipse : Local variable jsonReply defined in an enclosing scope must be final or effectively final

[16:10:02] <thanos> I manage to get the reply and I log it, but I cannot return the value in order to transform it outside of the lambda expression

[16:13:28] <thanos> so here is the whole thing with the declaration

[16:13:28] <thanos>

[16:18:59] <D-Spair> The way that I would approach this is to handle this via the EventBus…

[16:19:46] <D-Spair> Then you can loosely couple your SOAP code to the Vert.x code.

[16:21:55] <thanos> ah really? I am not very comfortable with all this yet

[16:22:31] <thanos> that is why I am asking, to get this code working the right way, not to write bad code

[16:23:32] <thanos> could you elaborate a bit more please? an online example maybe

[16:24:18] <D-Spair> An example would be touch without knowing what sort of libraries you are using for SOAP and how it is structured. There's probably over 100 different ways to wire this up.

[16:24:26] <D-Spair> s/touch/tough/

[16:26:34] <thanos> OK, so the event bus is used to send/receive messages

[16:26:54] <thanos> should I send this jsonObject as a message through the event bus?

[16:27:07] <D-Spair> If the “final/effectively final” portion is the only hurdle you are experiencing, then you could write the Vert.x code in Groovy and use “real” closures and that requirement goes away.

[16:27:44] <thanos> I do not want to use groovy code, I prefer to stay in java

[16:28:40] <D-Spair> Understood, but you could write the Groovy code in an almost identical fashion to Java. In fact, most Java code can be run as Groovy code, with the exception of Lambdas.

[16:29:28] <D-Spair> So, let me see if I can provide you with an example of how I would arrange it…

[16:30:14] <thanos> I know what you say about groovy but there will be more developers in the team and I do not know if I have the “right” to start coding in groovy

[16:30:45] <thanos> thank you! The thing is that I do not really understand this problem of final anyway

[16:31:59] <D-Spair> The reason that it has to be final is the asynchronous nature of the calls… When you provide a lambda as a handler, there is no guarantee that the lambda handler will be called immediately. If the underlying object changes before the lambda get's evaluated, it will cause problems.

[16:32:30] <thanos> I see now, it makes sense :)

[16:44:13] <D-Spair> thanos: Are you using JAX-WS or some other SOAP implementation?

[16:44:25] <D-Spair> Spring perhaps?

[16:44:58] <thanos> no spring here, I use CXF yes

[16:45:32] <thanos> I used CXF to generate the java classes from the WSDL

[16:46:12] <Sticky_> ahhhhh, good olde soap

[16:46:20] <D-Spair> Hmmm… Tougher than I originally though… JAX-WS is designed around return values.

[16:46:31] <thanos> so this code I pasted is in the implementation of the @WebService

[16:46:42] <thanos> hehe yes good old SOAP indeed

[16:46:44] <thanos> yes exactly

[16:47:47] <D-Spair> So, opening up to the rest of the group… If you wanted use Vert.x Async capabilities within a method which returns the results of the Vert.x async operations, how would you do it? My gut reaction is that it would nullify all of the reactive benefits.

[16:49:42] <Sticky_> normally you return a future that gives the result

[16:49:44] <D-Spair> Perhaps some sort of Future await?

[16:50:08] <thanos> what would be the difference then? I have to read more about Future actually

[16:51:16] <Sticky_> A future would allow you to be non-blocking, as it allows you to defer your future processing until there is a result

[16:52:04] <thanos> it is like the promise in AngularJS?

[16:52:10] <Sticky_> yes

[16:52:11] <thanos> I see

[16:52:26] <thanos> so can I use it in my HttpClient response?

[16:53:23] <Sticky_> does the httpclient support returning results in an async manner?

[16:54:11] <thanos> I am not sure if I can give a valid answer but I would say yes

[16:54:22] <thanos> it seems to me that it is async

[16:54:23] <D-Spair> Got it… Pasting up in a sec

[16:54:27] <Sticky_> if so then yes

[16:54:52] <thanos> I have to find an example of how to use Future in the httpClient and the bodyHandler then

[16:54:59] <Sticky_> what framework is HttpClient from?

[16:55:10] <D-Spair>

[16:55:32] <D-Spair> Sticky_: He's trying to use Vert.x HttpClient to call a REST service and then return the result via SOAP

[16:56:11] <Sticky_> yeah its entierly possible to to all that non-blocking then

[16:56:28] <thanos> that's awesome, I am testing it immediately

[16:56:35] <D-Spair> thanos: That example I pasted above uses CompletableFuture and the call to `responseFuture.get()` will block until the future is resolved.

[16:58:33] <Sticky_> that example also returns something from a void method

[16:59:56] <thanos> I see D-Spair, I am trying to see if I can get it to work

[17:01:50] <Sticky_> so what framework is consuming the result of this http request?

[17:03:07] <thanos> I have a CXF JAXB java classes generated and this is done in a @WebMethod and I want to transform the result to a SOAP reply

[17:07:29] <Sticky_> yeah so there does look like there are async jax-ws apis, so you want to use them

[17:07:51] <thanos> I integrated this code and even if I log the reply from the REST service, it does not move forward to get out of the lambda

[17:08:17] <thanos> It seems to stay blocked in this line responseFuture.complete(buffer.toJsonObject());

[17:10:15] <thanos> so Sticky you mean that it makes sense to use vert.x in that case

[17:11:10] <Sticky_> well, you are mixing a bunch of technologies here, which is probably partialy why you are getting confused

[17:11:20] <thanos> absolutely

[17:12:11] <Sticky_> if you are purely using vertx as an async httpclient and nothing else, I would probably just use insted

[17:13:06] <Sticky_> if you are using vertx for other stuff, fair enough. But its a big framework to bring in just for an httpclient

[17:13:07] <thanos> would that be easier to integrate in this SOAP reply?

[17:13:41] <Sticky_> whichever framework you use is not going to make that easier

[17:13:59] <thanos> ah really? I have to think about it, it didn't seem so big to me

[17:14:00] <Sticky_> you need to figure out how to make that response in an async manner

[17:14:07] <thanos> yes

[17:14:21] <Sticky_> and that is nothing to do with what actally makes the http call

[17:15:17] <Sticky_> so step 1 is figure out how to respond to the request in an async manner, then figure out how to make the async call (using async-http-client/vertx/whatever)

[17:15:41] <thanos> actually, this module is really something like a proxy which gets a SOAP request on one side, it takes this request and transforms it to a REST one, it gets the reply and transforms it back to a SOAP reply

[17:16:17] <Sticky_> but yeah, figure out step 1 first

[17:18:21] <thanos> I see what you mean

[17:18:43] <thanos> I am wondering if I could use the event bus as D-Spair suggested in the first place

[18:10:10] <D-Spair> thanos: You definitely could.