-
-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
odd behavior with latest tower/slf4j-timbre #181
Comments
Hi Dmitri, sorry for the delay replying - have been travelling. This sounds like a dependency conflict, could you try |
yeah sure thing, here's the full tree (a bit long sorry :) [bouncer "0.3.3"]
[clj-time "0.9.0"]
[com.andrewmcveigh/cljs-time "0.3.0"]
[com.cemerick/austin "0.1.5"]
[com.cemerick/piggieback "0.1.3"]
[cljs-ajax "0.5.1"]
[com.cognitect/transit-cljs "0.8.225"]
[com.cognitect/transit-js "0.8.755"]
[net.colourcoding/poppea "0.2.1"]
[org.apache.httpcomponents/httpasyncclient "4.1"]
[commons-logging "1.2"]
[org.apache.httpcomponents/httpclient "4.4.1"]
[org.apache.httpcomponents/httpcore-nio "4.4.1"]
[org.apache.httpcomponents/httpcore "4.4.3"]
[org.clojure/core.async "0.1.346.0-17112a-alpha"]
[org.clojure/tools.analyzer.jvm "0.1.0-beta12"]
[org.clojure/tools.analyzer "0.1.0-beta12"]
[org.ow2.asm/asm-all "4.1"]
[cljsjs/react "0.13.3-1"]
[clojure-complete "0.2.3" :exclusions [[org.clojure/clojure]]]
[com.fzakaria/slf4j-timbre "0.2.1"]
[junit "4.12"]
[org.hamcrest/hamcrest-core "1.3"]
[org.slf4j/slf4j-api "1.7.12"]
[com.h2database/h2 "1.4.188"]
[com.taoensso/sente "1.7.0-RC1"]
[com.taoensso/timbre "4.1.4"]
[io.aviso/pretty "0.1.17"]
[com.taoensso/tower "3.0.2"]
[com.taoensso/encore "1.10.2"]
[compojure "1.4.0"]
[clout "2.1.2"]
[instaparse "1.4.0" :exclusions [[org.clojure/clojure]]]
[medley "0.6.0"]
[org.clojure/tools.macro "0.1.5"]
[ring/ring-codec "1.0.0"]
[conman "0.2.7"]
[com.carouselapps/to-jdbc-uri "0.4.1"]
[com.zaxxer/HikariCP "2.4.2"]
[yesql "0.5.1"]
[environ "1.0.1"]
[markdown-clj "0.9.82"]
[metosin/ring-http-response "0.6.5"]
[potemkin "0.4.1"]
[clj-tuple "0.2.2"]
[riddley "0.1.10"]
[ring/ring-core "1.4.0"]
[commons-fileupload "1.3.1"]
[commons-io "2.4"]
[crypto-equality "1.0.0"]
[crypto-random "1.2.0"]
[slingshot "0.12.2"]
[metosin/ring-middleware-format "0.6.0"]
[clj-yaml "0.4.0"]
[org.yaml/snakeyaml "1.5"]
[com.cognitect/transit-clj "0.8.269"]
[com.cognitect/transit-java "0.8.276"]
[com.fasterxml.jackson.datatype/jackson-datatype-json-org "2.3.2"]
[org.json/json "20090211"]
[org.apache.directory.studio/org.apache.commons.codec "1.8"]
[org.msgpack/msgpack "0.6.10"]
[com.googlecode.json-simple/json-simple "1.1.1" :exclusions [[junit]]]
[org.javassist/javassist "3.18.1-GA"]
[com.ibm.icu/icu4j "54.1.1"]
[org.clojure/core.memoize "0.5.7"]
[org.clojure/core.cache "0.6.4"]
[org.clojure/data.priority-map "0.0.4"]
[org.clojure/tools.reader "0.8.15"]
[migratus "0.8.7"]
[camel-snake-kebab "0.3.2"]
[org.clojure/java.classpath "0.2.2"]
[org.clojure/java.jdbc "0.3.7"]
[robert/bruce "0.7.1"]
[mount "0.1.3" :exclusions [[ch.qos.logback/logback-classic]]]
[org.clojure/tools.logging "0.3.1"]
[org.clojure/tools.namespace "0.2.11"]
[mvxcvi/puget "1.0.0"]
[fipp "0.6.3"]
[org.clojure/core.rrb-vector "0.0.11"]
[mvxcvi/arrangement "1.0.0"]
[org.clojure/clojure "1.7.0"]
[org.clojure/clojurescript "1.7.170" :scope "provided"]
[com.google.javascript/closure-compiler "v20151015" :scope "provided"]
[org.clojure/data.json "0.2.6" :scope "provided"]
[org.clojure/google-closure-library "0.0-20151016-61277aea" :scope "provided"]
[org.clojure/google-closure-library-third-party "0.0-20151016-61277aea" :scope "provided"]
[org.mozilla/rhino "1.7R5" :scope "provided"]
[org.clojure/tools.nrepl "0.2.12"]
[org.immutant/web "2.1.1" :exclusions [[ch.qos.logback/logback-classic]]]
[org.immutant/core "2.1.1"]
[org.projectodd.wunderboss/wunderboss-clojure "0.10.0"]
[org.projectodd.wunderboss/wunderboss-web-undertow "0.10.0"]
[io.undertow/undertow-core "1.3.0.Beta9"]
[org.jboss.xnio/xnio-api "3.4.0.Beta1"]
[org.wildfly.common/wildfly-common "1.0.0.Alpha2"]
[org.wildfly.security/wildfly-security-manager "1.1.2.Final"]
[org.jboss.xnio/xnio-nio "3.4.0.Beta1" :scope "runtime"]
[io.undertow/undertow-servlet "1.3.0.Beta9"]
[org.jboss.spec.javax.annotation/jboss-annotations-api_1.2_spec "1.0.0.Final"]
[io.undertow/undertow-websockets-jsr "1.3.0.Beta9"]
[org.projectodd.wunderboss/wunderboss-core "0.10.0"]
[org.jboss.logging/jboss-logging "3.1.4.GA"]
[org.projectodd.wunderboss/wunderboss-web "0.10.0"]
[org.jboss.spec.javax.servlet/jboss-servlet-api_3.1_spec "1.0.0.Final"]
[org.jboss.spec.javax.websocket/jboss-websocket-api_1.1_spec "1.1.0.Final"]
[org.webjars/bootstrap "3.3.5"]
[org.webjars/jquery "2.1.4"]
[pjstadig/humane-test-output "0.7.0"]
[prone "0.8.2"]
[reagent "0.5.0"]
[ring-webjars "0.1.1"]
[org.webjars/webjars-locator "0.27"]
[com.fasterxml.jackson.core/jackson-databind "2.3.3"]
[com.fasterxml.jackson.core/jackson-annotations "2.3.0"]
[org.apache.commons/commons-lang3 "3.4"]
[org.webjars/webjars-locator-core "0.27"]
[org.apache.commons/commons-compress "1.9"]
[ring/ring-defaults "0.1.5"]
[javax.servlet/servlet-api "2.5"]
[ring/ring-anti-forgery "1.0.0"]
[ring/ring-headers "0.1.3"]
[ring/ring-ssl "0.2.1"]
[ring/ring-devel "1.4.0"]
[clj-stacktrace "0.2.8"]
[hiccup "1.0.5"]
[ns-tracker "0.3.0"]
[ring/ring-mock "0.3.0"]
[ring "1.4.0" :exclusions [[ring/ring-jetty-adapter]]]
[ring/ring-servlet "1.4.0"]
[selmer "0.9.5"]
[cheshire "5.5.0"]
[com.fasterxml.jackson.core/jackson-core "2.5.3"]
[com.fasterxml.jackson.dataformat/jackson-dataformat-cbor "2.5.3"]
[com.fasterxml.jackson.dataformat/jackson-dataformat-smile "2.5.3"]
[tigris "0.1.1"]
[commons-codec "1.10"]
[joda-time "2.8.2"]
[json-html "0.3.5"]
[hiccups "0.3.0"] |
Okay, that's a confirmation: problem is that you've got Tower pulling in an old Encore dependency. You can find resolution instructions here. Current latest version is |
Hmm, unfortunately I get different errors when I try to use the latest
but when I add the latest stable
Which I think means it conflicts with another dependency that relies on the older API. The |
actually just using exclusions seems to address the issue with tower: [com.taoensso/tower "3.0.2" :exclusions [com.taoensso/encore]] However, whenever WARN [taoensso.sente] - Bad ev-msg: {:ch-recv #object[clojure.core.async.impl.channels.ManyToManyChannel 0x1b5d8e85 "clojure.core.async.impl.channels.ManyToManyChannel@1b5d8e85"], :send-fn #object[taoensso.sente$make_channel_socket_BANG_$send_fn__14337 0x3280c1a7 "taoensso.sente$make_channel_socket_BANG_$send_fn__14337@3280c1a7"], :connected-uids #object[clojure.lang.Atom 0x81fe94d {:status :ready, :val {:ws #{"c04b3029-ae46-4149-8a98-a873ee86ac16"}, :ajax #{}, :any #{"c04b3029-ae46-4149-8a98-a873ee86ac16"}}}], :client-id "c04b3029-ae46-4149-8a98-a873ee86ac16", :ring-req {:ssl-client-cert nil, :cookies {"treeForm_tree-hi" {:value "treeForm:tree:applications"}, "ring-session" {:value "cfab55f3-5cb9-4a99-94bd-c6d169d5799e"}, "JSESSIONID" {:value "9C-lPAJ7FX8IYAxfQuSHB6rh"}}, :remote-addr "0:0:0:0:0:0:0:1", :params {:client-id "c04b3029-ae46-4149-8a98-a873ee86ac16"}, :flash nil, :handler-type :undertow, :route-params {}, :headers {"origin" "http://localhost:3000", "host" "localhost:3000", "upgrade" "websocket", "user-agent" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36", "cookie" "treeForm_tree-hi=treeForm%3Atree%3Aapplications; ring-session=cfab55f3-5cb9-4a99-94bd-c6d169d5799e; JSESSIONID=9C-lPAJ7FX8IYAxfQuSHB6rh", "connection" "Upgrade", "pragma" "no-cache", "sec-websocket-key" "fVJyjCPtsfiQtEDDZGnypQ==", "accept-language" "en-US,en;q=0.8,ru;q=0.6", "sec-websocket-version" "13", "accept-encoding" "gzip, deflate, sdch", "sec-websocket-extensions" "permessage-deflate; client_max_window_bits", "dnt" "1", "cache-control" "no-cache"}, :server-port 3000, :content-length -1, :form-params {}, :compojure/route [:get "/ws"], :websocket? true, :server-exchange #object[io.undertow.server.HttpServerExchange 0x3c268c10 "HttpServerExchange{ GET /ws request {Accept-Language=[en-US,en;q=0.8,ru;q=0.6], Cache-Control=[no-cache], Sec-WebSocket-Version=[13], Accept-Encoding=[gzip, deflate, sdch], Sec-WebSocket-Key=[fVJyjCPtsfiQtEDDZGnypQ==], DNT=[1], Pragma=[no-cache], Upgrade=[websocket], Origin=[http://localhost:3000], User-Agent=[Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36], Sec-WebSocket-Extensions=[permessage-deflate; client_max_window_bits], Connection=[Upgrade], Cookie=[treeForm_tree-hi=treeForm%3Atree%3Aapplications; ring-session=cfab55f3-5cb9-4a99-94bd-c6d169d5799e; JSESSIONID=9C-lPAJ7FX8IYAxfQuSHB6rh], Host=[localhost:3000]} response {Server=[undertow], X-XSS-Protection=[1; mode=block], Upgrade=[WebSocket], Origin=[http://localhost:3000], X-Frame-Options=[SAMEORIGIN], Sec-WebSocket-Accept=[j1IQJRZFOggbWpD141I/XhIch9I=], Date=[Mon, 30 Nov 2015 05:34:31 GMT], Connection=[Upgrade], Sec-WebSocket-Location=[ws://localhost:3000/ws?client-id=c04b3029-ae46-4149-8a98-a873ee86ac16], X-Content-Type-Options=[nosniff], Content-Type=[application/octet-stream]}}"], :query-params {"client-id" "c04b3029-ae46-4149-8a98-a873ee86ac16"}, :content-type nil, :path-info "/ws", :character-encoding nil, :context "", :uri "/ws", :server-name "localhost", :query-string "client-id=c04b3029-ae46-4149-8a98-a873ee86ac16", :body nil, :multipart-params {}, :scheme :http, :request-method :get, :session {:ring.middleware.anti-forgery/anti-forgery-token "pGvuzkOHCZwveWDulAQhPXfYkzDZVJR21AjQS+ffYZ+GE7qt9DcOFvMePuJk7bKat0VBEugnD0a5NBH0"}}, :event [:guestbook/add-message {:name "foo", :message "bar baz"}], :?reply-fn nil, :uid "c04b3029-ae46-4149-8a98-a873ee86ac16"} And the messages never make it to the router at that point. With the dependency removed everything works as expected. Any thoughts? |
So this is after confirming with I'm not too familiar with If you've tried |
Yeah I find it bizarre that it should affect it in any way. Let me try make a minimal sample project where this issue occurs and I'll put it up. |
I wonder if you're getting affected by technomancy/leiningen#2032? Leiningen uberjars an older version of tools.reader through clj-http. It won't show up in |
Assuming this is resolved but please feel free to reopen if you're still experiencing trouble. |
Oh sorry, I just been a bit busy with work here. I was going to put together a bit more minimal example, but hopefully this will do. If you run However, this doesn't happen and there's the The relevant server-side code is found in the Perhaps it's a case of another dependency conflict of some sort here, I'm really not sure. Let me know if there's anything I missed in the example or it's unclear. |
Hi Dmitri, no problem. Have you tried the Reference example project with+without slf4j-timbre? |
I got the reference project to run, and it actually works in both cases which makes things a bit more confusing now. :) I did notice one thing. When slf4j-timbre is included then the [[org.clojure/clojure "1.7.0"]
[com.taoensso/timbre "4.1.4"]
[org.slf4j/slf4j-api "1.7.12"]] The version of timbre it includes is the same as already included in the reference project. I had to add these dependencies for the project to run with slf4j-timbre [com.fzakaria/slf4j-timbre "0.2.2"]
[com.taoensso/encore "2.26.1"]
[org.clojure/tools.reader "0.9.2"] However, with the same dependencies in my project the socket connection doesn't appear to work, while taking out slf4j-timbre fixes everything. |
Definitely looks like a dependency conflict related to tools.reader. Just to clarify: the reference example project works whether or not you include
The tools.reader dependency there shouldn't be necessary. In fact, it shouldn't have any effect at all since Only way you can debug this is with To resolve that, you'll need to do one of the following:
Leiningen will always use the dependency version it encounters first (not the highest version it encounters as some people expect). Does that help / make sense? |
Yeah, so it does work in the example project both ways. Just my project where this is failing. I'm surprised with the tools reader issue as well, but to get the example project working I had to add tools.reader However, the example project does work with tools.reader I've tried adding the same dependencies at the top for my project, but that doesn't seem to have any effect. The only constant is the slf4j-timbre dependency, but given what it's doing and its dependencies it makes absolutely no sense that it should affect sente behavior in any way. |
@yogthos I wonder if you're being affected by #181 (comment). You could try building and running the latest leiningen from master, it may resolve your issues. |
@danielcompton if you happen to have the latest master lein installed would you mind trying the example project to see if you get the same results? |
I tried that project with lein 2.5.3 calling |
Have you tried posting the messages from the web ui? The project compiles fine and it runs, (you have to compile cljs with |
So I was looking at this some more, and as I mentioned earlier there's nothing in dependencies for slf4j-timbre that should be causing problems. I noticed that it forces timbre to be compiled since it uses a Since it's compiled against timbre |
Hi Dmitri,
You might be onto something there, thanks for doing all this digging. Don't have time atm to figure out if this is actually expected behaviour (seems like the aot should be compiling with the updated deps?) - but have just pushed Let me know if that solves your issue and I'll try push a stable release later today. |
Unfortunately, that still doesn't seem to solve the original problem, but it definitely seems to be related to whatever classes timbre related are packaged with slf4j-timbre as removing it solves the issue. I'm not sure why the original example project doesn't behave the same way, only other thing I haven't tested is running it against immutant. I just noticed that my project is setup with immutant and the example project uses http-kit. I'll have to try this tomorrow. |
thanks for pushing out the new version quickly, I'll try see if I can pin down what's happening exactly. I think we're getting close though. :) |
@yogthos Safe to close this as resolved by fzakaria/slf4j-timbre#8? |
@ptaoussanis I think so yeah 👍 |
Awesome, thanks! |
Thanks for taking a deep dive with me on this. It was a tricky one to figure out. :) |
No problem, you did all the figuring ;-) |
I just wanted to drop by and thank you @ptaoussanis for writing the above linked guide which helped me resolve an entirely unrelated dependency issue between ring and sente where ring wanted |
You're very welcome Rovanion, thanks for saying so :-) |
I noticed that when I have the latest Tower releases
3.0.2/3.1.0-beta3
included in the project then I get errors regarding encore compilation:When slf4j-timbre is included then the project compiles but sente starts giving errors, such as:
Everything works fine without tower/slf4j-timbre though.
The text was updated successfully, but these errors were encountered: