riemann-java-client
riemann-java-client copied to clipboard
Defining IDeref can break AOT compiled clojure projects.
Use http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/Proxy.html at client initialization time to construct a proxy for promises here: https://github.com/aphyr/riemann-java-client/blob/master/src/main/java/com/aphyr/riemann/client/Promise.java
Remove IDeref from the inheritance chain of IPromise: https://github.com/aphyr/riemann-java-client/blob/master/src/main/java/com/aphyr/riemann/client/IPromise.java
Hi @aphyr,
Any plans to fix this?
I've got a project with elastic search and wanted to update it to 2.2.0 and got the jar hell error due to IBlockingDeref class you define here:
https://github.com/aphyr/riemann-java-client/blob/master/riemann-java-client/src/main/java/clojure/lang/IBlockingDeref.java
In the newest elastic, you can't disable their JarHell, so I can't move on without fixing this issue.
Thanks, Karol
P.S. I actually moved both interfaces to com.aphyr.riemann.client and everything works just fine. Please look at the https://github.com/aphyr/riemann-java-client/pull/69.
Hey,
So I spent some time on looking at this issue.
So there are two (three?) approaches I found.
-
Change
map-promisemethod inclient.clj: https://github.com/aphyr/riemann-clojure-client/compare/master...andrusieczko:map-promise-fix?expand=1So this works fine, all the tests are passing.
Advantage: it's a small, simple change
Downside: if someone wants to use
RiemannClientinstance directly, calling the java methods on it (like(.sendEvent ^IRiemannClient rc event)). Then result will beIPromisewhich won’t be subtype ofclojure.lang.IDerefanymore. -
Change the
RiemannClientconstructor methods to use proxy inclient.clj: https://github.com/aphyr/riemann-clojure-client/compare/master...andrusieczko:deref-fix?expand=1Still a couple of things to be done there (no point of finishing it now):
- all the constructor methods would need to use proxies
- not all nested method calls (that return
IPromise) still don't work
Advantage: it should work for all the cases and the user doesn't have to know anything about the implementation
Disadvantage: it's very complicated
-
Use Futures instead of Promises :)
Please let me know what you think about it and I can finish the implementation.
Regards, Karol