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
