Log4j2 integration classloading woes

49 views
Skip to first unread message

Dimitrios Piliouras

unread,
Jan 18, 2021, 4:22:33 AM1/18/21
to Clojure Mailing List
Hi folks,

I'm trying to integrate log4j2 (and its `MapMessage`) with tools.logging. Everything was going great until the moment I had to depend on this little library, from another project. Everything would work on the REPL, but `lein check` was failing with the most bizarre IOException (Stream closed) during compilation! I reported/asked about this to `duct-core` initially [1] (as it was a duct-based project), but it turns out that this doesn't really relate to duct. James (@weavejester) was kind enough to  attempt to explain this, and he basically concluded that (quoting straight from the ticket):

  1. The Clojure classloader opens a stream to read com.elcom.tools.logging.structured from the jar.
  2. The clojure.tools.logging namespace is then required and loaded.
  3. Log4j is triggered from clojure.tools.logging, which then tries to read from the elcom-tools jar again, probably to load in your custom logging class or properties file.
  4. This second read appears to close the first stream to com.elcom.tools.logging.structured, causing an IO error from the still-open reader.

Note that this only occurs when the classloader is trying to load from a jar. The moment the files are cached in the target directory, everything works fine.

Reproducing this requires that you download the two zips from the link below, install `elcom-tools` locally, and then doing `lein check` on `elcom-auth`.

I do have a workaround at this point, but at the same time, I'd love to understand what exactly is happening here. Many thanks in advance for any insights... 

Kind regards,
Dimitris


Eugen Stan

unread,
Jan 19, 2021, 12:26:12 PM1/19/21
to clo...@googlegroups.com, jimpi...@gmail.com
Hello Dimitris,

I think I have encountered the same issue and I found a solution for it
while working on OFBiz.

See this if it helps: https://issues.apache.org/jira/browse/OFBIZ-12118

And the solution:

URLConnection connection = url.openConnection();
// https://issues.apache.org/jira/browse/OFBIZ-12118
connection.setUseCaches(false);
try (InputStream is = connection.getInputStream();){
return readXmlDocument(is, validate, url.toString());
}


The idea is to disable caching from the url connection (the
JarURLConection).

I hope it helps.

Regards,
Eugen

On 18.01.2021 11:22, Dimitrios Piliouras wrote:
> Hi folks,
>
> I'm trying to integrate log4j2 (and its `MapMessage`) with
> tools.logging. Everything was going great until the moment I had to
> depend on this little library, from another project. Everything would
> work on the REPL, but `lein check` was failing with the most bizarre
> IOException (Stream closed) during compilation! I reported/asked about
> this to `duct-core` initially [1] (as it was a duct-based project), but
> it turns out that this doesn't really relate to duct. James
> (@weavejester) was kind enough to  attempt to explain this, and he
> basically concluded that (quoting straight from the ticket):
>
> 1. The Clojure classloader opens a stream to read
> |com.elcom.tools.logging.structured| from the jar.
> 2. The |clojure.tools.logging| namespace is then required and loaded.
> 3. Log4j is triggered from |clojure.tools.logging|, which then tries to
> read from the elcom-tools jar again, probably to load in your custom
> logging class or properties file.
> 4. This second read appears to close the first stream to
> |com.elcom.tools.logging.structured|, causing an IO error from the

Dimitrios Jim Piliouras

unread,
Jan 23, 2021, 4:38:35 AM1/23/21
to clo...@googlegroups.com
Hi Eugen,

Many thanks for your response, and apologies for the late reply. I followed the JIRA conversation and the various links, and ended up here [1] which seems to be the exact problem I am facing. The thing is that this seems to have resolved on Java side many years ago. I believe I was using Java 15 (through leiningen) when I was trying all of this last week, but I am not actually sure. I’ll investigate a bit more next week…

Thanks again :)
Dimitris


[1]: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8155607
Reply all
Reply to author
Forward
0 new messages