Clojurians Log v2

I guess one of the “selling points” of eg wildfly is that devs can focus on the code whereas your wildfly-admin can tune the runtime performance of it, and do so uniformly across a bunch of deployments. A related example. I’m currently throwing out our xml-config-based logging and replacing it with timbre. As a dev this is wonderful, as my logging config is for the first time understandable. But from an ops perspective, with the xml based stuff, they could tune the logging at their will, now they’re at the mercy of what ever home grown env-variable passing scheme I come up with.

@slipset We switched away from Timbre for exactly that reason (and went to log4j2).

We tried tools.logging first, switched to Timbre for the flexibility, then decided it wasn’t worth the mess of non-standard code and the dependencies that Timbre dragged in, and went back to tools.logging 🙂

As far as I've seen Java application servers are not liked by unix admins, although people who have received corporate training seem to like them. So wildfly/websphere/etc admin seems to a category that exists.

I wouldn't bet on a corporate admin in a bank for example being willing to spent time tweaking an application server - more likely they will require it from the vendor/consultants

I’m not saying that ops will do not love it. I’m just saying it’s a feature/selling point.

You are right and it probably was probably how things were approached around 2000 when these conventions were first set (before the mass adoption of virtualisation and containerisation, Ruby on rails and so on) .

Does anyone have a recommendation for inspecting stacktraces? The main info I'm interested in is determining the filename, line no, and column for a given stack trace element. I found https://github.com/mmcgrana/clj-stacktrace, but wanted to check what other options might be a good fit.

@smith.adriane Throwable->map in clojure.core?

(with demunge calls, I guess, to turn the class/function name back into Clojure “source”?)

yea. afaict, it seems the raw output needs some coercing which is why I was looking at clj-stacktrace

My plan is to build a reveal plugin that makes it easier to inspect exceptions and then open the corresponding file in my editor

dev=> (->> (ex-info "Boom!" {}) (Throwable->map) :trace (map (fn [[cl meth file line]] [(demunge (str cl)) (keyword meth) file line])) (remove (comp #{:invokeStatic} second)))

Not sure whether invoke or invokeStatic is the thing to filter out.

And maybe some layers of clojure.core etc?

clj-stacktrace will first try to determine if a stacktrace element corresponds to clojure code and then use a different mechanism to figure out the filename and line number

I looked at the source code for cider and it seems like it's doing the same thing

Ah, cool.

I might also be able to get away with a modified version of clojure.repl/stacktrace-element-str

(defn stack-element-str
  "Returns a (possibly unmunged) string representation of a StackTraceElement"
  {:added "1.3"}
  [^StackTraceElement el]
  (let [file (.getFileName el)
        clojure-fn? (and file (or (.endsWith file ".clj")
                                  (.endsWith file ".cljc")
                                  (= file "NO_SOURCE_FILE")))]
    (str (if clojure-fn?
           (demunge (.getClassName el))
           (str (.getClassName el) "." (.getMethodName el)))
         " (" (.getFileName el) ":" (.getLineNumber el) ")")))

The stack trace doesn't contain the entire path name to the source file, does it? I thought it only contained the last part of the path, e.g. core.clj Also no column numbers?

Yes, that's correct. Line numbers are good enough for my use case.

using the above, I can also get the qualified symbol for the function calls which means I can usually find the source

I wrote a neovim plugin to populate the (nvim) quickfix list with the locations from a stack trace. It queries a connected nREPL for the ns-path of an ns

It's not published anywhere (still early stages), but I'll share if you're interested

It parses stack traces from text, though

Using a modified version of clojure.repl/stack-element-str along with modified version of clojure.repl/source-fn seems to work for me.