Matt, I don’t see commons-plugins needing a configuration. Remember, there are several components in Log4j that don’t use a configuration file. Namely, Lookups, PatternConverters, KeyProviders, and Watchers, I view the plugin system as an API that a configuration system would use to instantiate the objects referenced in the configuration.
Ralph > On Apr 4, 2022, at 8:30 AM, Matt Sicker <boa...@gmail.com> wrote: > > From the Log4j side of things, I didn't exactly overhaul the > configuration parsing or representation of it, so it would depend on > how different that looks in this proposed component. Ideally, though, > a commons-plugins component would replace log4j-plugins and > log4j-plugin-processor along with some of the plugin types we have > like type converters and config variable substitution. > > From a high level point of view, the inputs would be a configuration > source (e.g., a reloadable file or HTTPS link or whatever), and the > output would be a graph of instantiated plugins from the > configuration. > > On Mon, Apr 4, 2022 at 8:12 AM Gary Gregory <garydgreg...@gmail.com> wrote: >> >> I am trying to figure out the input and output of a Commons Plugins >> that Log4j would use. >> >> Gary >> >> On Sun, Apr 3, 2022 at 10:51 PM Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >>> >>> It has been too long since I looked at Commons Configuration for me to >>> answer that. >>> >>> Ralph >>> >>>> On Apr 3, 2022, at 7:25 PM, Gary Gregory <garydgreg...@gmail.com> wrote: >>>> >>>> So in a Commons centric fantasy, Log4j Nodes could be Commons Configuration >>>> objects? >>>> >>>> G >>>> >>>> On Sun, Apr 3, 2022, 22:18 Ralph Goers <ralph.go...@dslextreme.com> wrote: >>>> >>>>> 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 <garydgreg...@gmail.com> 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 <ralph.go...@dslextreme.com> >>>>> 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 <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 >>>>>>> >>>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>> >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
