[08:30:16] <kuwv> How do I use the readFile method fluently?

[08:30:51] <kuwv> http://vertx.io/docs/apidocs/io/vertx/core/file/FileSystem.html#readFile-java.lang.String-io.vertx.core.Handler-

[16:32:54] <LostCoder> Hello, anyone here?

[16:33:47] <cescoffier> Hi

[16:33:50] <LostCoder> I found some sort of bug in the DeploymentManager.java

[16:34:00] <LostCoder> its very obscure.

[16:34:29] <LostCoder> I posted on the forums about the fat jar not working with -cp

[16:34:52] <LostCoder> I used a step through debugger to try figure out what is going on.

[16:35:15] <LostCoder> So the cluster.xml file IS added to the context classloader

[16:35:32] <LostCoder> but during the

[16:35:34] <LostCoder> private void loadVerticleFactories() {

[16:35:39] <LostCoder> call

[16:35:43] <LostCoder> in deployment manager

[16:36:10] <LostCoder> the url for cluster.xml is “popped” off the stack

[16:36:27] <LostCoder> so when hazelcast clustering loads it is no longer in the classloader

[16:36:35] <LostCoder> so it loads the default.

[16:37:01] <LostCoder> its specifically the iterator for this line

[16:37:07] <LostCoder> for (VerticleFactory factory: factories) {

[16:37:13] <cescoffier> how do you see it's popped ?

[16:37:21] <LostCoder> step through debugging

[16:37:45] <LostCoder> can I paste screen shots here?

[16:37:58] <LostCoder> ill paste a screen shot before that line and after that line

[16:38:26] <cescoffier> upload the screenshot on a temporary image service and paste the link

[16:38:40] <LostCoder> will do.

[16:38:53] <cescoffier> it's weird, you can't remove entries from a classloader, exception by specifically call some magic method on url classloader

[16:38:53] <cescoffier> and we are not doing that

[16:41:06] * ChanServ sets mode: +o temporalfox [16:45:34] <LostCoder> http://pasteboard.co/12AVJQQN.tiff ⇐= before [16:45:47] <LostCoder> http://pasteboard.co/12AZejQT.tiff ⇐= after [16:47:04] <LostCoder> its specifically the iterator for the serviceloader [16:47:38] <LostCoder> it eventually calls this function on URLClasspath [16:47:44] <LostCoder> private synchronized URLClassPath.Loader getLoader(int var1) { (decompiled) [16:47:54] <LostCoder> and that then gets to [16:47:56] <LostCoder> “ var2 = (URL)this.urls.pop();” [16:48:23] <LostCoder> is this a bug in java? Im download the latest jdk (92) to test it [16:48:30] <LostCoder> I was on 60 [16:48:35] <cescoffier> I can't see the images (image not found) [16:49:21] <LostCoder> let me try another sharing site [16:49:28] <cescoffier> but it acts on a copy of the url classloader [16:51:14] <LostCoder> http://imgur.com/a/odQLi [16:51:17] <LostCoder> does that work? [16:59:17] <LostCoder> I just tried jdk 1.8.0_92 same issue. [17:14:08] <cescoffier> well, wait a sec [17:14:16] <cescoffier> the classpath must not contain a file [17:14:21] <cescoffier> it contains directory or jar files [17:14:54] <LostCoder> but this is specifically to load cluster.xml [17:15:13] <LostCoder> but ill try that [17:16:03] <LostCoder> this is not the java -cp its the vertx -cp [17:17:40] <LostCoder> same issue even with the directory [17:18:32] <LostCoder> this was the forum post that I was refering too [17:18:34] <LostCoder> https://groups.google.com/forum/#!topic/vertx/WSa6NDmdXjw [17:19:11] <LostCoder> and that post references this post [17:19:15] <LostCoder> https://groups.google.com/forum/?fromgroups#!searchin/vertx/classpath$20cluster.xml$20fatjar/vertx/YN6E7jxmNwU/ORAeXuA3BQAJ [17:19:20] <LostCoder> where you specify the file [17:31:12] <cescoffier> even with `vertx`, if you cluster.xml is in the `foo` directory, it's vertx -cp foo [17:31:23] <cescoffier> not vertx -cp foo/cluster.xml [17:31:32] <cescoffier> this is how classloader works when searching for a file [17:35:00] <cescoffier> are you using the Launcher ? [17:35:19] <LostCoder> yes [17:35:36] <LostCoder> java -jar fat.jar -cp cluster.xml -cluster [17:37:48] <cescoffier> no again [17:37:58] <cescoffier> it's not -cp cluster.xml, but -cp . [17:38:12] <cescoffier> (see the . (dot)) [17:38:27] <LostCoder> yes you are right [17:38:36] <cescoffier> url classloaders (as here we are speaking about urlclassloaders) works like that [17:38:40] <LostCoder> java -jar vertx-jpos-1.0.0-fat.jar -cluster -cp ../ [17:38:44] <LostCoder> worked for me [17:38:48] <LostCoder> guess im the idiot. [17:39:02] <cescoffier> if you search for a resources (file), it iterates over all directories you pass, and search for a file in this directory [17:39:13] <cescoffier> we should improve the doc [17:39:17] <cescoffier> it's pretty unclear [17:39:30] <cescoffier> and for us it's natural because, well, because we have developed this code [17:39:48] <cescoffier> and we know how the classloader works there [17:39:57] <cescoffier> but from the external point of view, it is confusing [17:40:13] <LostCoder> the docs says add cluster.xml to the classpath… which would be fine, but I was using java -jar… which does not work with -cp [17:40:28] <LostCoder> in normal java that is. [17:40:35] <LostCoder> but with the launcher it does [17:41:23] <cescoffier> it's regular java: https://github.com/vert-x3/vertx-hazelcast/blob/master/src/main/java/io/vertx/spi/cluster/hazelcast/HazelcastClusterManager.java#L266 [17:41:53] <cescoffier> even with a regular java classpath, you can't have file items that are not jars [17:41:58] <LostCoder> nope the java spec says -jar and -cp don't work together [17:42:24] <cescoffier> actually, you could make it works, but yes it's not intended to be used like that [17:42:53] <cescoffier> when you have your cluster.xml at the root of a jar [17:42:56] <cescoffier> and the classloader is looking for this file [17:43:38] <cescoffier> it gets all the root of the jars from the classloader and search inside each jar if the file exist (actually if it contains a JarEntry with the right name)) [17:44:01] <cescoffier> (obviously it's kind of optimized, so a bit more complicated than this, but that's the big picture) [17:44:26] <LostCoder> that was the issue I was having… it all started because I did the normal class loading [17:44:42] <LostCoder> the first thing I did… like 8 hours ago was this [17:44:52] <LostCoder> java -cp . -jar vertx-jpos-1.0.0-fat.jar -cluster [17:45:06] <LostCoder> and that does not work, then I went down the rabbit hole…. [17:45:14] <LostCoder> but a “tiny” change [17:45:23] <LostCoder> java -jar vertx-jpos-1.0.0-fat.jar -cp . -cluster [17:45:25] <LostCoder> and it works [17:46:33] <LostCoder> I think if that could be documented, it would save alot of headaches (i'm sure half the forum post about loading cluster.xml are because the -cp is before the -jar [17:47:33] <cescoffier> I definitely agree [17:47:47] <cescoffier> I'm going to update the HZ cluster manager documentation right now [17:48:25] <cescoffier> unfortunately, we discovery where our documentation is bad with such kind of issues [17:48:58] <LostCoder> i'm just glad its working , thanks for the help. [17:53:03] <cescoffier> * If you want to override this configuration you can provide a file called `cluster.xml` on your classpath and this [17:53:04] <cescoffier> * will be used instead. If you want to embed the `cluster.xml` file in a fat jar, it must be located at the root of the [17:53:05] <cescoffier> * fat jar . If it's an external file, the directory containing the file must be added to the classpath. For [17:53:05] <cescoffier> * example, if you are using the _launcher_ class from vert.x, the classpath enhancement can be done as follows: [17:53:07] <cescoffier> * [17:53:07] <cescoffier> * [source] [17:53:09] <cescoffier> * —- [17:53:09] <cescoffier> * # If the cluster.xml is in the current directory: [17:53:11] <cescoffier> * java -jar … -cp . -cluster [17:53:11] <cescoffier> * vertx run MyVerticle -cp . -cluster [17:53:13] <cescoffier> * [17:53:13] <cescoffier> * # If the cluster.xml is in the conf directory [17:53:15] <cescoffier> * java -jar … -cp conf -cluster [17:53:15] <cescoffier> * —- [18:56:36] <ChicagoJohn> in java, how do you chain client requests without ending up in callback hell? [18:57:10] <ChicagoJohn> i really dont want to bring in an additional promise library unless i HAVE to [19:14:01] <temporalfox> ChicagoJohn if that's the same kind of request you put the call in a method and then have the method call itself until a criteria is met [19:14:11] <temporalfox> ChicagoJohn or you can use the RxJava version [19:14:15] <temporalfox> that already exists [19:16:04] <ChicagoJohn> my intention: login().then(loginResult → getFromAnotherEndpoint(loginResult).then(result → (doSomething)); [19:17:28] <ChicagoJohn> is this an RxJava kind of thing? i am not terribly interested in a bunch of progressively nested 'callbacks on callbacks on callbacks' [19:17:55] <ChicagoJohn> visually, i would like my code to be 'flattened' out if you get my drift [19:22:01] * ChanServ sets mode: +o temporalfox

[19:31:16] <ChicagoJohn> anyone have any thoughts on vertx-util vs vertx-when?

[19:34:57] <cescoffier> ChicagoJohn : I did a class that does this, it's named Chain: https://github.com/cescoffier/vertx-microservices-workshop/blob/master/vertx-workshop-common/src/main/java/io/vertx/workshop/common/Chain.java

[20:18:31] <AlexLehm> kuwv: what do you mean by fluent in this case? readFile is an async operation, that probably doesn't work in another way

[21:00:23] *** ChanServ sets mode: +o temporalfox