This isn't detailed enough?

Looking at the numbers, they add up to more that the total respondents so it must be a multiple-response question.

To be honest, it gives me enough of an idea in practice. I was just hoping to have a more definitive answer to "how many people use non-LTS versions"

Yeah, I was a bit surprised nearly 60% are still using 8.

I have no impetus to upgrade.

Just feels like risk, java 8 is great.

We were originally on Oracle's JDK 8 so we had a good incentive to switch to OpenJDK 8 (we went with AdoptOpenJDK's build), and once we had decided to stop running on an Oracle "official" build, it just made sense for us to start testing on newer JDKs and there were enough differences between 8 and 11 to be a worthwhile upgrade (memory management, GC reporting, etc). We dev/test against 14 and 15 but haven't felt the need to roll it out to QA/production at this point (although 15 has some nice GC enhancements).

https://www.mail-archive.com/[email protected]/msg106499.html - I found someone else has this issue too

@U04V70XH6 I guess you are the one who can know the answer. It touch topic around https://github.com/seancorfield/depstar

hmm I updated to new ver of depstar and I have different errors

1) option 1

:exec-args {             :aot true
                                 :main-class api.core}

Exception in thread "main" java.lang.IllegalArgumentException: No implementation of method: :get-logger of protocol: #'clojure.tools.logging.impl/LoggerFactory found for class: nil
	at clojure.core$_cache_protocol_fn.invokeStatic(core_deftype.clj:583)
	at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:575)
	at clojure.tools.logging.impl$fn__881$G__865__888.invoke(impl.clj:25)
	at api.core$_main.invokeStatic(core.clj:43)
	at api.core$_main.invoke(core.clj:42)
	at clojure.lang.AFn.applyToHelper(AFn.java:152)
	at clojure.lang.AFn.applyTo(AFn.java:144)
	at api.core.main(Unknown Source)

:main-opts ["-m" "hf.depstar.uberjar" "api.jar" "-C" "-m" "api.core"]

2020-12-17 13:17:06,472 main ERROR Unable to locate plugin type for JsonTemplateLayout
2020-12-17 13:17:06,473 main ERROR Unable to locate plugin type for JsonTemplateLayout
2020-12-17 13:17:06,497 main ERROR Unable to locate plugin for JsonTemplateLayout
2020-12-17 13:17:06,508 main ERROR Could not create plugin of type class org.apache.logging.log4j.core.appender.ConsoleAppender for element Console: java.lang.NullPointerException java.lang.NullPointerException
	at org.apache.logging.log4j.core.config.plugins.visitors.PluginElementVisitor.findNamedNode(PluginElementVisitor.java:104)
	at org.apache.logging.log4j.core.config.plugins.visitors.PluginElementVisitor.visit(PluginElementVisitor.java:88)
	at org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.injectFields(PluginBuilder.java:185)
	at org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:121)
	at org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:1002)
	at org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:942)
	at org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:934)
	at org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:552)
	at org.apache.logging.log4j.core.config.AbstractConfiguration.initialize(AbstractConfiguration.java:241)
	at org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:288)
	at org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:622)
	at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:695)
	at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:712)
	at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:267)
	at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:245)
	at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
	at org.apache.logging.log4j.LogManager.getContext(LogManager.java:174)
	at clojure.tools.logging$eval136.invokeStatic(NO_SOURCE_FILE:0)
	at clojure.tools.logging$eval136.invoke(NO_SOURCE_FILE)
	at clojure.lang.Compiler.eval(Compiler.java:7177)
	at clojure.lang.Compiler.eval(Compiler.java:7132)
	at clojure.core$eval.invokeStatic(core.clj:3214)
	at clojure.core$eval.invoke(core.clj:3210)
	at clojure.tools.logging.impl$log4j2_factory.invokeStatic(impl.clj:183)
	at clojure.tools.logging.impl$log4j2_factory.invoke(impl.clj:178)
	at clojure.lang.Var.invoke(Var.java:380)
	at clojure.tools.logging$call_str.invokeStatic(logging.clj:316)

all the time work in REPL

I ended with

2020-12-17 22:45:53,526 main ERROR Unable to locate plugin type for JsonTemplateLayout
2020-12-17 22:45:53,527 main ERROR Unable to locate plugin type for JsonTemplateLayout
2020-12-17 22:45:53,550 main ERROR Unable to locate plugin for JsonTemplateLayout
2020-12-17 22:45:53,560 main ERROR Could not create plugin of type class org.apache.logging.log4j.core.appender.ConsoleAppender for element Console: java.lang.NullPointerException java.lang.NullPointerException
	at org.apache.logging.log4j.core.config.plugins.visitors.PluginElementVisito

But I see this in verbose mode /Users/kwladyka/.m2/repository/org/apache/logging/log4j/log4j-layout-template-json/2.14.0/log4j-layout-template-json-2.14.0.jar so it should be there

and this Found META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat in multiple dependencies, selecting the largest maybe this is the reason

@U0WL6FA77 That message is expected, when multiple Log4j2Plugins.dat files are provided in dependencies. Selecting the largest is usually the correct strategy but perhaps you have an unusual library on your classpath that is pulling in a larger version that does not include the default plugins cache. If your project is on GitHub, I can take a look. If not, I can't debug it so I can't help you.

https://github.com/arctype-co/log4j2-plugins-cache Do you know how to use this in deps.edn ?

This is a design problem with log4j2 that people have complained about for years and the maintainers have agreed it's a design problem and said they would change how it works in 3.0 but we have no idea when that will be release.

That's a Leiningen plugin. It cannot be used with deps.edn.

yes… just thinking if not log4j2 and choose something else. I am trying whole week to make a simple JSON log output in custom format…

for google cloud jsonPayload logging

When I write depstar 2.0, I will be able to have external dependencies and I can address the log4j2 problem using similar code. But for now depstar cannot have external dependencies.

Is any way to choose Log4j2Plugins.dat source?

Nope.

ok, this already help with decision 🙂

thank you

As I said, if your project is on GitHub, I can take a look at it and see what might improve the log4j2 file selection.

it is not

As you can see, logging in Java is a giant mess.

yes, I really hate logging in Java.

Java is the worst part of Clojure 😉

I assume you'll be switching to a different logging library now?

I guess logback as blind choice 🙂

I will see the difference with log4j2. I have never do so deep logging things.

hmm maybe I can also try to copy Log4j2Plugins.dat to jar as an extra command somehow form the right place if this will even work. I use only 1 plugin at once, so in this specific case it should.

oh logback is not supported by clojure.tools.logging, I have bad luck today

I had hope to add :exclude ["META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat"] and add this file into resources but it doesn’t work with the same exception

Because it would have to be at that exact same relative path in resources and your :exclude would still exclude it.

yes… so I don’t have more ideas

FYI I found java.util.logging is the best for me to generate custom JSON and in general doing custom things with logs. This is the easiest and simplest way which I found. Here is my solution. Maybe you will find it useful one day :)

(ns api.logs.google-jsonPayload
  (:require [jsonista.core :as json]
            [clojure.stacktrace :as stacktrace])
  (:import (java.util.logging LogManager ConsoleHandler Level SimpleFormatter LogRecord)
           ( StringWriter PrintWriter)))

(def cloud-run? (some? (System/getenv "K_REVISION")))

(def line-separator (System/getProperty "line.separator"))

(def ANSI-colours {:reset "\u001B[0m"
                   :black "\u001B[30m"
                   :red "\u001B[31m"
                   :green "\u001B[32m"
                   :yellow "\u001B[33m"
                   :blue "\u001B[34m"
                   :purple "\u001B[35m"
                   :cyan "\u001B[36m"
                   :white "\u001B[37m"})

(defn getCause [^Throwable thrown]
  (when-let [cause ^Throwable (.getCause thrown)]
    {:class (.getClass cause)
     :message (.getMessage cause)
     :print-thrownable (with-out-str (clojure.stacktrace/print-throwable cause))
     :print-stack-trace (with-out-str (stacktrace/print-stack-trace cause))
     :print-cause-trace (with-out-str (clojure.stacktrace/print-cause-trace cause))}))

(defn getThrown [^LogRecord record]
  (when-let [thrown ^Throwable (.getThrown record)]
    (let [cause (getCause thrown)]
      (cond->
        {:class (.getClass thrown)
         :message (.getMessage thrown)
         :print-thrownable (with-out-str (clojure.stacktrace/print-throwable thrown))
         :print-stack-trace (with-out-str (stacktrace/print-stack-trace thrown))
         :print-cause-trace (with-out-str (clojure.stacktrace/print-cause-trace thrown))}
        cause (assoc :cause cause)))))

(defn record->jsonPayload [^LogRecord record]
  (let [thrown ^Throwable (.getThrown record)
        thrown-map (getThrown record)
        level (.getLevel record)
        ex-info? (= clojure.lang.ExceptionInfo (class thrown))]
    (cond->
      {:severity (.getName level)
       :logger-name (.getLoggerName record)
       :message (if thrown
                  (let [w (StringWriter.)]
                    (.printStackTrace thrown (PrintWriter. w))
                    (.toString w))
                  (.getMessage record))}
      ex-info? (assoc :ex-info (ex-data thrown))
      (= Level/SEVERE level) (assoc "@type" "")
      thrown (assoc :logger-message (.getMessage record))
      thrown-map (assoc :thrown thrown-map))))

(def root-logger (when cloud-run?
                   (let [root-logger (.getLogger (LogManager/getLogManager) "")
                         google-jsonPayload (proxy [SimpleFormatter] []
                                              (^String format [^LogRecord record]
                                                (let [color (if (= Level/SEVERE (.getLevel record))
                                                              (:red ANSI-colours)
                                                              (:white ANSI-colours))]
                                                  (str
                                                    #_color
                                                    (json/write-value-as-string (record->jsonPayload record)
                                                                                #_(json/object-mapper {:pretty true}))
                                                    #_(:reset ANSI-colours)
                                                    line-separator))))
                         console-handler (doto (ConsoleHandler.)
                                           ;(.setUseParentHandlers false)
                                           (.setFormatter google-jsonPayload))]

                     (doseq [handler (.getHandlers root-logger)]
                       (.removeHandler root-logger handler))

                     (doto root-logger
                       (.setLevel Level/INFO)
                       (.addHandler console-handler)))))

thrown-map is an addition for me for now to debug logs 😛 😉 You can remove it, so then cut code by half.

camelCase naming is not idiomatic Clojure 😛

Take a look at Throwable->map (in clojure.core) -- it would simplify your code.

yes, it is not final solution

thank you, I will that

I haven't watched it myself but it sounds like it may be of use to you: https://www.youtube.com/watch?v=iyHvwkc6Wis

I think this is possible via Java static initializers The trick that java classes are present regardless whether you :import them. So you could invoke clojure from a java class static initializer. If such class is in the classpath, mission accomplished I doubt it's a pleasant "API" though :)

https://twitter.com/borkdude/status/1339592701952442378

Is that something like emacsclient for nrepl?

not really, it's just reply but then compiled to native

@dpsutton @U04V15CAJ let’s continue here

i kinda want to recap as i don't quite have a good grasp. You need to initialize the logger with a network call. The logger's behavior before being initialized is undefined. You have seen instances of needing to log before initialization

is all of this true?

Correct. To be 100% precise: I need to initialize a logger with a map that is received from a netwok call

Is this in CLJS? Why would you do a network call to init a logger?

so what's your question? You could block awaiting the results of the network call. But fundamentally you need to handle failing network calls or slow calls. And does the app crash?

@U04V15CAJ It’ CLJ. The logger settings come from the network

if not, and you allow work to happen while its waiting, do you buffer all of these logs and then send them through once the network has (hopefully) succeeded? Do you have a fallback and log it to a file and then push that file through whatever configured logging settings eventually return?

I’m fine with blocking

then do that

What about logs that are sent before the request to the network is sent?

have (my-logger/init!) make the network call and block. i'd do this before anyone needs to log otherwise you get into weird territory

i wouldn't allow that

No!

but if you want to, then you need to figure out a way to store them and then log them in the future with the correct logging settings

but this could be a crazy hard problem. what do you do with those logs when the network request fails, or the program dies before initializing.

The way it works is

(init-logger! {})
(log "App is up")
(let [settings (read-from-network)]
    (init-logger! (:log-settings settings))
    (log "after settings are read"))
      

maybe not bring the app up before you have the required info to log

that's probably what I would do

It’s not a big issue that the logs that are sent between the two init-logger! are not using the same settings

then what's wrong with what you've posted?

Nothing

you could queue the pending logs until you have the right info, another option

It’s just that it’s cumbersome for the apps to have to call init-logger! twice

why not have the init logging do that instead?

I was thinking of calling (init-logger) in the library code

you call init and it starts immediately with an empty config and does a network call, updating the logging settings when that resolves

The logger doesn’t know about the network call. It’s an app related stuff

There are dozens of apps

that use the same logger lib

i don't think i know how to help then

My question is: is it a bad practice to call (init-logger!) inside the logger lib. @U04V15CAJ you wrote earlier that https://clojurians.slack.com/archives/C03S1KBA2/p1608223187132500 On what side of the “it depends” my use case fall?

considering that it is your own library, I wouldn't worry about it

maybe document it in the README

You mean: it’s ok or not ok?

we're just people on the internet. but he's saying its ok

up to you

Why the fact that this is my own library matters?

because this would be crazy for something the general population used. but for an internal logging library its tied to your particular usecase

this is 100% your code top to bottom. so do what you need to solve your goals

You mean that I hold both sides: the lib and the usage of the lib

yes

?

Ok. Thank you guys

I'm in a meeting now, have to drop

Enjoy your meeting @U04V15CAJ

Seems like you just have to pass it into cli/parse-opts, so something like:

(cli/parse-opts args specs :in-order true)

@U2FRKM4TW Yes, I tried it but the missing piece is how to structure the specs so that they are interpreted correctly.

The docs at https://github.com/clojure/tools.cli are very vague about that.

I don't think it has anything to do with the specs. As per the docs: "`cli/parse-opts` accepts an :in-order option that directs it to stop processing arguments at the first unrecognized token." What exactly are you trying to achieve?

So e.g. if your specs are [["-p" "--port PORT"]] then cli/parse-opts will parse only -p and --port. Anything else will become arguments.

@U2FRKM4TW I’m trying to write a CLI tool that accepts commands and subcommands as command line arguments, like eg: the git CLI

If my understanding is correct, then you have to create a global spec that does not include your subcommands and use it with :in-order true. Then, you create a spec for each subcommand and feed it to cli/parse-opts along with the arguments received from the cli/parse-opts called with the global spec.

Oh I see, that makes sense.

Thanks @U2FRKM4TW I get it now.

I would imagine it’s a combination of group-by and map but trying to avoid multiple traversals if possible

You could probably rig up a single-traversal version with reduce

it depends on if things are sorted or not

but it is some kind of join

a self join

use the specter library?

not yet

tools.build is coming...

Could you elaborate on "extension tasks?" I'm unfamiliar

they are deps that add special tasks https://github.com/clojure/tools.deps.alpha/wiki/Tools

the only one I notice right away today that compiles java is mevyn, and it does that by delegating to mvn

Oh cool, ty