You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Todor Boev (Jira)" <ji...@apache.org> on 2020/09/21 18:31:00 UTC

[jira] [Created] (LOG4J2-2932) Under OSGi Log4j uses brute force to scan for plugins causing multiple issues

Todor Boev created LOG4J2-2932:
----------------------------------

             Summary: 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


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.3.4#803005)