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 http://pastebin.com/ and paste your code, submit it and copy the link here.
[15:58:56] <thanos> http://pastebin.com/YdZyt4Bc
[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> http://pastebin.com/CTRt9JaJ
[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> http://pastebin.com/rZFGZ4RP
[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 https://github.com/AsyncHttpClient/async-http-client 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.