You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Andreas Sewe (Jira)" <ji...@apache.org> on 2021/03/19 16:05:00 UTC
[jira] [Created] (LOG4J2-3047) Don't assume that jar:-URL yield
JarURLConnections
Andreas Sewe created LOG4J2-3047:
------------------------------------
Summary: Don't assume that jar:-URL yield JarURLConnections
Key: LOG4J2-3047
URL: https://issues.apache.org/jira/browse/LOG4J2-3047
Project: Log4j 2
Issue Type: Improvement
Components: Configuration
Affects Versions: 2.13.1
Reporter: Andreas Sewe
Hi, I am currently investigating a bug in an *IntelliJ* plug-in which uses Log4J2 internally for its logging needs and the uses an {{Appender}} to reroute log messages to IntelliJ's debug log. This approach works fine.
Unfortunately, with IntelliJ 2021.1, its developers have decided to swap the default {{JarURLConnection}} for their own implementation, [for "performance reasons"|https://youtrack.jetbrains.com/issue/IDEA-264777#focus=Comments-27-4777159.0-0], as they claim. This leads to the unfortunate situation that a straight-forward {{jar:[file:/some/file.jar!some/package|file:///some/file.jar!some/package]}} URL no longer yields a {{JarURLConnection}} but merely a plain {{URLConnection}}.
Now I am not 100%-sure whether the rule "{{jar:}}-URL yields {{JarURLConnection}}" is part of the Java API; AFAICT, that is only stipulated in a code example in the Javadoc of {{JarURLConnection}}, not on {{URL}} or {{URLConnection}} themselves:
{code:java}
* <p>Users should cast the generic URLConnection to a
* JarURLConnection when they know that the URL they created is a JAR
* URL, and they need JAR-specific functionality. For example:
*
* <pre>
* URL url = new URL("jar:file:/home/duke/duke.jar!/");
* JarURLConnection jarConnection = (JarURLConnection)url.openConnection();
* Manifest manifest = jarConnection.getManifest();
* </pre>
{code}
But regardless of who is to blame, I think Log4J's {{ResolverUtil}} can safely drop that assumption:
In {{ResolverUtil.findInPackage}}, {{extractPath}} has already extracted the path to the JAR file in question, so the call to {{loadImplementationsInJar(Test, String, URL}} could IMHO safely be replaced by {{loadImplementationsInJar(Test, String, File)}}, thereby
# removing one of the {{else if}} cases in {{findInPackage}}
# removing the only use of {{loadImplementationsInJar(Test, String, URL)}}
# getting rid of the "{{jar:}}-URL yield {{JarURLConnection}}" assumption, which is at least somewhat contested/implicit in the Java API.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)