If you look at Log4j, we parse the configuration and convert it to a Node hierarchy. Variable interpolation occurs as the Nodes are constructed.
But again, Nothing says a Commons Plugins implementation has to work the same way. Ralph > On Apr 3, 2022, at 7:12 PM, Gary Gregory <[email protected]> wrote: > > Nice thread :-) > > Where does the parsing of configuration files mix in such a stack? > > Where does variable interpolation come into play? > > Gary > > On Sun, Apr 3, 2022, 20:50 Ralph Goers <[email protected]> wrote: > >> 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 <[email protected]> >> 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 <[email protected]> >> wrote: >>>> >>>> Should this be in Commons Configuration? >>>> >>>> Gary >>>> >>>> On Sat, Apr 2, 2022, 15:33 Matt Sicker <[email protected]> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
