[
https://issues.apache.org/jira/browse/LOG4J2-3047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17305965#comment-17305965
]
Andreas Sewe commented on LOG4J2-3047:
--------------------------------------
FYI, IntelliJ changed its behavior; a {{jar:}}-URL now also yields a
{{JarURLConnection}} (and a warning):
[https://github.com/JetBrains/intellij-community/commit/595c926f34ceb77d6382151121c69273476f601c#diff-f1b0073f652e551957fdf077f74f753f8e86ca3f05c1a9bc90397d0d59e7c173R305]
> 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
> Priority: Major
>
> 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)
