Matt, The Logging Provider is not a plugin as it is required way before plugins are available.
That said, the plugin system certainly could have a way of performing version checking. But keep in mind, the versions would be defined by the “owner” of each plugin category and not tied to the plugin system. Ralph > On Apr 4, 2022, at 8:39 AM, Matt Sicker <boa...@gmail.com> wrote: > > I used to work on the Jenkins project for a few years, so yes, I'm > fairly familiar with those difficulties. I've also used OSGi in the > past, and I like their approach to semantic versioning and dynamic > "plugin" (well, bundle/component/etc.) lifecycles. I currently work on > the Spinnaker project where we have a less sophisticated plugin system > based on pf4j, and we've already found that to be incredibly > burdensome to work with so far. > > For version compatibility, I'd like to maintain the usual Commons > standards of strict compatibility along semantic versioning. The > existing Log4j plugin system already has some basic version check > support (at least for the logging provider), and a more generic plugin > system would definitely need the more sophisticated version check > support. I'd also like a way for plugins to declare data compatibility > related metadata for easier upgrades and such, but those are merely > details. > > On Mon, Apr 4, 2022 at 10:33 AM Xeno Amess <xenoam...@gmail.com> wrote: >> >> If you really want to start this, it would be useful. >> However it would be complicated, very very complicated. >> For example, version management. >> The plugins have their versions. >> And the base program has its version. >> And the plugin registration mechanism has its own version. >> How to make it work would be a big challenge. >> If we wanna make a useful plugin management system, maybe a good way is >> first to learn about some existing usage of these things(although developed >> in different groups/repos), like eclipse, jetbrains idea, even OSGI... >> >> Gary Gregory <garydgreg...@gmail.com> 于2022年4月4日周一 21:11写道： >> >>> 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
