Hi Ralph, Upon further investigation the application is setting a URLClassLoader. Not using standard class loader that is normally used. I have to try and reproduce it. This happens only in this setup. Maybe the best thing is to just not rely on finding log4j config from jar any more and use absolute file path instead.
Thank you On Tue, Dec 28, 2021 at 3:44 PM Ralph Goers <ralph.go...@dslextreme.com> wrote: > > Yes. It would be best if you could provide a sample that fails. I am assuming > from your message that this happens on windows. > > Ralph > > > On Dec 28, 2021, at 1:29 PM, Leon Finker <leon...@gmail.com> wrote: > > > > Hi, > > > > In one of our applications we're hitting the following issue in the > > latest log4j2 versions. We specify a config file, and it's found and > > loaded from the class loader by log4j2. Unfortunately, it seems like > > there was a breaking change some time ago. It can no longer handle > > white spaces in the URI path. I've tracked it down to this line that > > throws: > > https://github.com/apache/logging-log4j2/commit/82dd809b94142078ee2ed1396a6054821120b41a#diff-ab4255c11b7414e8167314c787cb3ac7925e30bf212d5c1dd8bf06c93f9717aeR379 > > > > url.toURI() > > > > Assuming the url that is auto resolved from resource is like so (note > > the space in path - in real world it actually fails from C:\Program > > FIles\...): > > "jar:file:/C:/test/client test/.jar!/startup-log4j2.xml" > > > > The exception is: > > java.net.URISyntaxException: Illegal character in opaque part at index 24: > > ... > > > > I think what happened before is the code ended up in > > return new ConfigurationSource(urlConnection.getInputStream(), url, > > urlConnection.getLastModified()); > > And configuration file was loaded no problem from the resource jar? > > > > Should I open bug report? > > > > Thank you > > >
