Perhaps? I’d have to investigate how commons configuration works to be sure. And thanks, Ralph, for answering the questions here. I’ll write up a more detailed proposal we can discuss.
— Matt Sicker > On Apr 3, 2022, at 21:25, 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 >> >>
