Baffling IOException in :duct/compiler #37
Comments
|
I can't diagnose issues in custom code without being able to see that code. |
|
There is no particular piece of code that I can isolate in order to show you. That is why I tried to explain the problem at a high-level. I would have to create two dummy projects, and you would have to install one of them locally, in order to reproduce the issue. I'll try to do that this morning and get back to you... Out of curiosity, where does the code for the |
|
After spending a few hours on this, I have officially hit a dead-end :(. The new (duct-based) dummy project doesn't exhibit the same issue, regardless of whether it depends on the original library, or a (newly installed) stripped down version, so i have nothing to share with you (at this point). Would you be able to explain to me the order in which the namespaces are loaded? On the new dummy project I can see the following (notice the On my original project that I'm trying to debug, I don't see the Many thanks in advance... |
The You can see in your :prep-tasks ["javac" "compile" ["run" ":duct/compiler"]]This will initiate all keys deriving from The prep tasks are the same as doing: However, note that the Leiningen profile may be different. I believe that it may just use the You can find the keys that are used in this step by using Integrant's user=> (dev)
:loaded
dev=> (prep)
:prepped
dev=> (ig/find-derived config :duct/compiler) |
|
Hi again, and thanks for the prompt response yesterday. There are no keys deriving from I am attaching two zip files below. The Now open the second one called I've been doing Clojure for close to 10 years now, and this is probably the most bizarre issue I've ever encountered. I am beyond baffled at this point :(. Many thanks in advance... elcom-tools.zip ps: I should also say that a bare (non-duct) project requiring (ns sanity-check.core
(:require [com.elcom.tools.logging.structured :as l]))
(defn foo
"I don't do a whole lot."
[x]
(l/infom "hi" :a "1" :b "2"))produces |
|
This is an interesting problem. I cleaned up the two project zips you provided, cutting out anything that wasn't related to the error: The cause appears to be an interaction between your log4j setup and the Clojure class loader. I can't be sure, but my guess is that something like this happens:
Note that this only occurs when the classloader is trying to load from a jar. The moment the files are cached in the Feel free to post those files up to the Clojure Google group or somewhere like that. They may have more insight as to the interactions between log4j and the Clojure classloader, as they relate to loading from jars in particular. As a workaround, you can force a load of (ns dev
(:refer-clojure :exclude [test])
(:require [clojure.repl :refer :all]
...
[clojure.tools.logging]
[com.elcom.tools.logging.structured]))This ensures that the |
|
WOW - first of all, the workaround does work, and for that I'm very grateful. I will post a message to the Clojure mailing list (first thing Monday morning), with a link back here, if that's ok. Thanks again - have a great weekend 馃憤 |
|
That's fine. Have a good weekend! |
Hi there and thanks once again for your work on the various Clojure libs - hugely appreciated 馃憤
Now, I'm trying to debug a rather baffling
IOExceptionin a duct-based project, and the reason I am asking here is because I tried to reproduce the error in a bare project and it doesn't show up. I should warn you this is confusing stuff, so be prepared.I have a library full of utilities at hand - let's call it
foo-tools. In there one can find afoo.tools.logging.structured.clj, which integratesclojure.tools.loggingwithlog4j2, and in particular leveragingMapMessage(for structured logging). So basically you will find the usual suspects - a couple of(System/setProperty ... )expressions, a couple ofalter-var-rootexpressions (for#'ctl/*force*and#'ctl/log*), and logging-macro variants (infom,debugm,errormetc). All good so far, this library compiles just fine and logging works as expected. The same is true when I depend on this library from a bare project - no issues whatsoever.However, when I depend on this library from a duct-based project, confusion begins...I will first paste the DEBUG output of
lein check, and then I will paste the actual stack-trace which is not actually very helpful because it points to namespace loading issues.I can see that something went wrong in
:duct/compilertask. but I'm not sure where that code is :(. Here are the contents of theclojure-15911932431814012512.ednfile:As you can see, the stack-trace is kind of misleading...it points the finger at
structured.clj, but I know for a fact that there is nothing syntactically wrong with that namespace - I can AOT compile it and everything.To make matters even more confusing, the duct-based project that throws the above on
lein check, works just fine through the regular REPL workflow (dev,goetc), including logging! Do you have any idea or clues about what could happening here? Many thanks in advance...As always, keep up the good work (and stay healthy) 馃憤
The text was updated successfully, but these errors were encountered: