ServliceLoader is used to locate plugins but what is loaded by ServiceLoader are not plugins.
Log4j Plugins are categorized into different groupings, primarily by where and how the plugins are used. For example, PatternConverters used by the PatternLayout are separate from Appenders, Filters and other things that can appear in a Log4j configuration file. Loading all of Log4j’s plugins via ServiceLoader would be very slow and would require every plugin be listed in the service configuration file. This has several problems: 1. A service must have a constructor that accepts no parameters. 2. Manually configuring every plugin in the META-INF/services file would be painful. 3. Every plugin might have its own unique configuration. ServiceLoader provides no mechanism for configuration. Log4j solves these problems by using the Java annotation processor to detect all the plugins defined in the compilation and generates the service instance ServiceLoader will load. This service instance maintains the list of all the plugins that were defined along with other information such as their category and type. The annotation processor also generates the META-INF/services file automatically. In addition, every plugin has a Builder with annotated parameters. This allows a configuration system to easily construct all its components. For example, Log4j allows JSON, YAML, XML, and properties. All of these use the exact same code to instantiate the Log4j configuration. I hope that answers your question. Ralph > On Apr 2, 2022, at 9:57 PM, Peter Verhas <pe...@verhas.com> wrote: > > What is the feature not provided by Service Loader? > > On Sat 2. Apr 2022 at 21:33, Matt Sicker <boa...@gmail.com> wrote: > >> Hi all, I’ve got a proposal for a new Commons component that I’d like to >> get feedback on. Essentially, I’d like to propose the creation of a Commons >> Plugins component inspired by the plugin system developed for Log4j 3.x >> [0]. This library would be a lightweight dependency injection and >> configuration library where developers create pluggable classes that can be >> referenced through plugin names via the configuration file (or >> configuration source in general). In contrast with more typical dependency >> injection frameworks like Spring and Guice, this library is for >> applications where pluggable implementations of things is desired. >> Developing a plugin system on top of DI frameworks is not a very >> standardized domain, and each project ends up reinventing this from scratch >> over time. >> >> Some existing material on how the Log4j plugin and configuration system >> works that I’d adapt from to form the basis for this component include: >> - >> https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/dependencyinjection.adoc >> < >> https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/dependencyinjection.adoc >>> >> - >> https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/plugins.adoc >> < >> https://github.com/apache/logging-log4j2/blob/master/src/site/asciidoc/manual/plugins.adoc >>> >> >> The general goal of this library is to make it so that applications can >> provide better configuration DSLs for their plugin components. As both a >> developer and user, I absolutely despise configuring complex applications >> with properties files, and YAML variants of properties aren’t that much >> better. If there was a common plugin library we could reuse, then perhaps >> more applications would support a better configuration system. This could >> also provide a nice place for tooling integration similar to how JUnit is >> supported by IDEs and other tools. >> >> What do you think? Should this start in the Sandbox? Is anyone interested >> in working on or using this? >> >> [0]: https://github.com/apache/logging-log4j2/tree/master/log4j-plugins < >> https://github.com/apache/logging-log4j2/tree/master/log4j-plugins> >> >> — >> Matt Sicker >> >> -- > Peter Verhas > pe...@verhas.com > t: +41791542095 > skype: verhas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
