There’s certainly an interesting use case here that seems to have uncovered a CL bug. The deferred plugin loading thing is an idea, though the precedence rules described seem like a good starting point for a potential bug?
On Tue, Jan 28, 2020 at 08:01 Sebastián Zaffarano <[email protected]> wrote: > Hi there! > I'm having a problem with an application (an app container) that manages > different ClassLoaders for different apps that it has deployed. We built a > custom ContextSelector that manages different contexts based on > classloaders to isolate different configurations for many apps running in > this container. One of these applications uses the builtin log4j Kafka > plugin that has external dependencies. Because this plugin is loaded > statically by PluginRegistry, it's using a different classloader and not > the one that has the external dependency (the jar file with the Kafka > client). The error we get is a ClassNotFoundException when the plugin is > built (at method PluginBuilder.buld). > One possible solution could be to override the plugin, for example by > specifying the package in the log4j configuration of the application that > needs it so that the plugin is loaded with the correct ClassLoader (I > already made this with a patched log4j version, and the application works > fine). This implies to change the precedence of the plugin lookup, > according to the docs > <https://logging.apache.org/log4j/2.x/manual/configuration.html>: > > 1. Serialized plugin listing files on the classpath. These files are > generated automatically during the build (more details below). > 2. (OSGi only) Serialized plugin listing files in each active OSGi > bundle. A BundleListener is added on activation to continue checking new > bundles after log4j-core has started. > 3. A comma-separated list of packages specified by the > log4j.plugin.packages system property. > 4. Packages passed to the static PluginManager.addPackages method > (before Log4j configuration occurs). > 5. The packages declared in your log4j2 configuration file. > > In my case, I would need that #5 overrides #1. > > Another possibility could be to add some configuration in order to disable > the eager loading of a specific builtin plugin and load it just when it is > needed. > > Any ideas? > > Thanks in advance! > > -- > <http://www.mulesoft.com/> > *Sebastián Zaffarano*, *Software Engineering PMTS* > > Juana Manso 999 6th Floor, Buenos Aires > <https://www.google.com/maps/search/Juana+Manso+999+6th+Floor,+Buenos+Aires?entry=gmail&source=g>, > C1107CBS, Argentina > > > > <https://www.linkedin.com/company/www.mulesoft.com> > <https://twitter.com/mulesoft> <https://www.facebook.com/MuleSoft> > <https://www.youtube.com/user/mulesoftvids> > > [image: Build a thriving API ecosystem for developers and partners] > <http://smart.mulesoft.com/v2/a/product_2019/5e303ec3e68c9166ef255608-zYaMz/httpslibrary.mulesoft.comproduct-2019> > [image: .] > -- Matt Sicker <[email protected]>
