[
https://issues.apache.org/jira/browse/LOG4J2-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker resolved LOG4J2-2932.
---------------------------------
Fix Version/s: 3.0.0
Assignee: Piotr Karwasz
Resolution: Fixed
This was fixed back in September by Piotr when we added BND to our build and
rely on SPI Fly for service loading. The service loader approach is portable to
both OSGi and Java modules while avoiding any need for scanning all available
ClassLoaders. The ClassLoader scanning is otherwise being fixed by
[https://github.com/apache/logging-log4j2/issues/1977] where the need for
loading classes by name will be generally eliminated.
> Under OSGi Log4j uses brute force to scan for plugins causing multiple issues
> ------------------------------------------------------------------------------
>
> Key: LOG4J2-2932
> URL: https://issues.apache.org/jira/browse/LOG4J2-2932
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Reporter: Todor Boev
> Assignee: Piotr Karwasz
> Priority: Major
> Fix For: 3.0.0
>
>
> The log4j 2 core bundle once started searches all existing bundles for plugin
> cache files in /META-INF. It does so by obtaining the ClassLoaders of all
> active bundles and calling ClassLoader.getResources() on each. This approach
> forces the creation of ClassLoaders without need causing substantial startup
> time overhead. This also causes arbitrary issues in other library bundles
> that use ClassLoader based techniques to load their plugins and makes the use
> of OSGi start levels pointless when explicit startup ordering is needed.
> This issue can be fixed by using standard OSGi patterns/practices:
> - Use bundle requirements/capabilities to point log4j core to the exact set
> of bundles that host plugins rather than to blindly scan everything.
> - Use the standard, core, battle tested BundleTracker utility to keep a
> dynamic list of bundle to scan.
> - Optionally load the plugin cache files without causing the creation of a
> ClassLoader using the Bundle.getEntries() method, which reads directly from
> the jar file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
