Matt J, I fully expect that if commons-plugins came into fruition it would bear a resemblance to the Log4j plugin system but there would be differences. For example, while Log4j integrates with Spring we don’t currently support having the logging configuration in application.yml. I also suspect it would an almost impossible abstraction to have the DI system be pluggable, but I could be wrong about that.
Of the bulleted items you listed Log4j’s plugin system handles all of them except that it doesn’t deal with dependencies. Instead, if your plugin is running in an OSGi environment it would be expected that the dependent modules would be available as described by the manifest for the module the plugin is included in. The goals for the log4j-plugins are really pretty simple. * Allow applications to provide flexibility by exposing sets of pluggable component types. * Allow users to provide their own implementations of the pluggable components that are on an equal footing with the “standard” components. Just by way of example, Apache Flume allows pluggable components such as Sources, Sinks and Channels. Writing a new Sink is fairly straightforward. But it will not be on an equal footing with the Sinks provided by Flume. This is because there is code in Flume that provides an alias (such as “avro” for the AvroSink) so that the plugin class can be named without having to specify the fully qualified class name. Custom components must be configured using the FQCN. The Log4j plugin system solves this by requiring every plugin to have a “name” which is then used as the mechanism to locate it from the configuration. Non-goals would be * It is meant to load plugins, not be a full DI system for every component. * It leverages standard class loading methodologies, not a new one. i.e. it works with the standard Java class path, module path, or OSGi. Ralph > On Apr 3, 2022, at 8:49 AM, Matt Juntunen <matt.a.juntu...@gmail.com> wrote: > > Hi Matt, > > This is quite timely since I've spent the past week researching > frameworks to modularize a monolithic application at my day job into > separate components/plugins. Everything I've looked at so far is > larger and more complicated than I need (e.g. OSGi, Spring, etc) so I > was seriously considering writing my own, perhaps based on select > components from the Plexus project [1]. I would be interested in this > project if it could do the following: > - provide a standardized plugin packaging format; > - provide standardized configuration mechanisms; > - handle plugin discovery and enumeration; > - handle service discovery, enumeration, and dependency injection; > - handle class loading and resolution of plugin dependencies (e.g. a > plugin that depends on a different version of commons-lang than > another plugin); and > - provide plugin lifecycle methods. > > It would also be great if the project was compatible with different > frameworks. For example, if the dependency injection functionality > could be swapped out for Spring if needed. > > I haven't totally completed my research so I'm not sure if there is > actually an existing framework out there that satisfies the above > requirements. If not, I would be willing to help out to get this > implemented, regardless of whether it ends up in commons or not. > > One more thought: I think it would be equally important (if not more > so) to define the non-goals of this potential project as the goals. Do > you have an idea of what those would be? > > Regards, > Matt J > > [1] https://codehaus-plexus.github.io/ > > On Sun, Apr 3, 2022 at 6:24 AM Gary Gregory <garydgreg...@gmail.com> wrote: >> >> Should this be in Commons Configuration? >> >> Gary >> >> On Sat, Apr 2, 2022, 15: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 >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
