>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
