Fork me on GitHub
#off-topic
<
2021-03-27
>
slipset07:03:17

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.

Dimitar Uzunov08:03:22

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.

Dimitar Uzunov08:03:43

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

slipset08:03:49

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

👍 1
Dimitar Uzunov12:03:58

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) .

seancorfield07:03:20

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

seancorfield07:03:22

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 🙂

phronmophobic22:03:20

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.

seancorfield22:03:15

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

phronmophobic22:03:38

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

seancorfield22:03:50

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

seancorfield22:03:09

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

seancorfield22:03:35

And maybe some layers of clojure.core etc?

phronmophobic22:03:14

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

phronmophobic22:03:25

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

phronmophobic22:03:07

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) ")")))

andy.fingerhut22:03:44

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?

phronmophobic22:03:58

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

phronmophobic22:03:00

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

walterl23:03:52

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

walterl23:03:42

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

walterl23:03:19

It parses stack traces from text, though

phronmophobic23:03:52

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

phronmophobic19:03:24

For completeness, here's what I came up with to find the source based on the info in a StackTraceElement, https://github.com/phronmophobic/reveal-exception/blob/main/src/com/phronemophobic/reveal_plugin/reveal_exception.clj#L83

seancorfield22:03:59

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

phronmophobic22:03:56

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