Clojurians Log v2

Does anyone have an example of jsonPayload for cloud run (or something else) in google cloud https://cloud.google.com/run/docs/logging#writing_structured_logs to share with org.clojure/tools.logging? With log4j maybe? I am a little confuse how to do it in Clojure and in general 🙂

I swear I tried really hard to find the answer on google but no luck: How do I suppress warnings in runtime? E.g.

WARNING: seqable? already refers to: #'clojure.core/seqable? in namespace: clostache.parser, being replaced by: #'clojure.core.incubator/seqable?

You can, in fact, exclude seqable? in particular: https://clojuredocs.org/clojure.core/refer-clojure

I do not recommend doing this, but here: https://gist.github.com/RutledgePaulV/2cf1ccf6e561937206ac61f41041112d

If you're the developer of the library then exclude with :refer-clojure. If you're not, then you can either monkey patch it locally or contribute to the library to resolve the warning

As someone without any substantial Java experience, what JDK is the standard one most people use nowadays? Still Oracle?

And does the local install of whatever JDK I choose actually affect anything in my writing of Clojure?

I use AdoptOpenJDK ones and GraalVM

I use OpenJDK 11. Both it and AdoptOpenJDK are good choices

The choice of JDK will often not affect your writing of Clojure at all. The primary cases where you care about which JDK version you are using is if you are writing code, or using a Clojure or Java library, that uses Java API calls that were only added in a particular version of the JDK, and thus you will need that version or later, or if some library or code you are writing makes assumptions that were changed in later versions of the JDK (e.g. the module system in JDK 9 changed some things, and is probably the main reason why many people have stayed on JDK 8 for as long as they have).

It's interesting you mention the module system. As someone who has used Java from 1.1 onwards, I found absolutely zero issues when moving from Java 8 to Java 11 (and now Java 15). I wonder what problems people experienced.

I think it's a huge testiment to the engineering team behind the JVM that it's so well engineered and backwards compatible.

Oracle changed their license model about 1-2 years ago, so many people avoid using it unless they already plan to pay Oracle for a commercial support license.

I am not a heavy JDK user myself except as a hobbyist, so can't give you good answers there. I would not be surprised if the main things convincing some people to continue using JDK 8 are that they rely upon some Java library that does not work well with JDK 9 or later, deep in its guts.

Perhaps yes.

Most of the issues, moving from 8 to 9 or above, were about reflection and access to parts of what became other modules. We got stuck on Java 8 for a while because some of the libraries we used did not run properly on 9+. We actually switched one library out for an alternative because it was so slow to properly support 9, and that allowed us to move to 11 which is what we're on in production right now.

It's been pretty smooth from 9 onward. I used 14 on my dev systems for a while, and I'm on 15 right now on my Mac (still on 14 on this Windows laptop, well, on Ubuntu). We've talked about upgrading our servers at work but there's nothing really compelling at the moment so we haven't decided which version we would upgrade to yet...

The main actual "breakage" when we upgraded from 8 to 11, was around JVM options which changed/went away. But that was easy to fix, albeit a bit annoying to roll out.

For us I think it's just there's no reason to move up from 8. And even if the friction won't be too hard, you'll still need to be upgrading dependencies and all, so it seems like a all pain no gain deal

Until 8 is no longer supported, then we'll have a reason to upgrade

It looks like 8 will stay supported past the end of 11's support period, at this point. 14 is already past the end of its support. 17 is still nearly a year away from release.

(let [logger (LogManager/getLogger)]
    (.info logger "foo bar"))

(clojure.tools.logging/info "foo")

(System/getProperty "clojure.tools.logging.factory")
=> "clojure.tools.logging.impl/log4j2-factory"

(binding [l/*logger-factory* (clojure.tools.logging.impl/log4j2-factory)]
    (l/info "foo"))

@kwladyka How are you setting that property for your code?

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="INFO">
    <Appenders>
        <Console name="ConsoleJSONAppender" target="SYSTEM_OUT">
            <JsonLayout complete="false" compact="false">
                <KeyValuePair key="myCustomField" value="myCustomValue"/>
            </JsonLayout>
        </Console>
    </Appenders>

    <Loggers>
        <Root level="all">
            <AppenderRef ref="ConsoleJSONAppender"/>
        </Root>
    </Loggers>
</Configuration>

How are you setting that property? I'm not asking about XML.

:aliases {:dev {:extra-paths ["dev"]
                 :jvm-opts ["-Dclojure.tools.logging.factory=clojure.tools.logging.impl/log4j2-factory"]

"-Dclojure.tools.logging.factory=clojure.tools.logging.impl/log4j2-factory" looks right. And you're starting things up with the :dev alias?

yes

PS Did you see my “edit” in my message?

https://clojurians.slack.com/archives/C03S1KBA2/p1607896174474900

I can't understand what you're saying here.

Likely the issue is tools.logging has a specific order it chooses logging backends in, and any reasonable sized project ends up including all the logging backends

Yes, but the JVM property tells it to select the specified one. It's what we do at work.

I am saying it didn’t work, but now it works. I don’t know how and when I fixed it 🙂

You shouldn't need that binding if you're setting the JVM property.

yes, now it works without

Ah I found the issue… for some reason when using clojure.tools.logging it doesn’t react for log4j2.xml file changes and reload configuration.

Which gave me false assumptions

Hmm, we use a .properties file for it and it does reload changes (after a period of time) and I think it's something you have to configure in log4j2... let me see if I can remember what we did...

monitorInterval = 30

You should be able to set that in the XML file as well. Then it will monitor the XML file and pick up changes automatically.

Nothing to do with clojure.tools.logging

Is it not default?

(let [logger (LogManager/getLogger)]
    (.info logger "foo bar"))

  (binding [l/*logger-factory* (clojure.tools.logging.impl/log4j2-factory)]
    (l/info "foo"))

ok this is my luck of experience with loggers then 🙂

I don't understand what you're asking, but this has nothing to do with clojure.tools.logging. This is about configuring log4j2.

See https://logging.apache.org/log4j/2.x/manual/configuration.html

I mean the code above always work with fresh configuration file while (l/info ...) use old one. So it looks like https://clojurians.slack.com/archives/C03S1KBA2/p1607899141479800?thread_ts=1607897509.475500&cid=C03S1KBA2 load fresh file always

My mistake, I though reload if by default

Those pieces of code are not equivalent.

But reloading the XML file when you make changes is a configuration option in the XML file.

Thanks, now I know 🙂

Java logging is a giant mess.

BTW Do you have example which work in google cloud (exactly cloud run) as jsonPayload? I can’t make it work as expected 😕

Nope, never used any of the Google Cloud stuff.

ok, thank you for help

Does anyone know of a Clojure/Java library that might layout a graph in x,y coordinate space? I'm just looking to call a function that for each vertex will return an x,y place to put it.

do you need some amount of custom graphics, or just an XY scatterplot?