gharris1727 opened a new pull request, #13771: URL: https://github.com/apache/kafka/pull/13771
The DelegatingClassLoader has a large number of fields and methods for keeping track of known PluginDesc objects. It has this in common with the PluginScanResult data object, which has a similar set of fields and methods. On trunk, the PluginScanResult is only used as a return value of one internal function, before it's results are accumulated by the DCL and discarded. To simplify the DCL, we should use the PluginScanResult object as a container to store and accumulate PluginDesc objects, and return it to the caller to allow them to inspect the scanned plugins without interacting with the DCL. Using the PluginScanResult as an accumulator, we can delay writing scan results to the pluginLoaders and aliases fields until after all scanning has taken place. This is done via the new installDiscoveredPlugins method. This prevents plugins being scanned from having an inconsistent delegation path: Previously, because the accumulators were updated as scanning proceeded, plugins may or may not be able to see one another via the DelegatingClassLoader::loadClass method. Now, plugins will _not_ be able to see one another before installDiscoveredPlugins is applied and scanning is finished. This is a first-pass refactor, before pulling the scanning logic out of the DCL to further simplify it. Once external scanning is complete, the caller will call installDiscoveredPlugins to finish initialization of the DCL. In the trunk implementation, there is some order-sensitivity to the scanning process because of the accumulator fields. In particular: 1. Because the classpath is scanned last, plugins on the classpath automatically take precedence over isolated plugins. In order to replicate this effect, PluginDesc objects now explicitly compare their isolated/non-isolated nature, and order classpath plugins first. 2. The alias mechanism attempts to determine if aliases are unique, but allows the _first_ usage of an alias to be applied before denying later ones. The new mechanism still chooses an arbitrary plugin to get the alias, while denying others. I've left a TODO in case we want to discard all conflicted aliases instead of allowing an arbitrary choice. ### Committer Checklist (excluded from commit message) - [ ] Verify design and implementation - [ ] Verify test coverage and CI build status - [ ] Verify documentation (including upgrade notes) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
