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 > On 19 Jan 2021, at 17:25, Eugen Stan <stan.ieu...@gmail.com> wrote: > > 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 >> 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 -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/A4B001FE-E0A5-4621-AEB3-27222DA5EC06%40gmail.com.
