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 > >
