Differences

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

Link to this comparison view

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