Right, Provider is a ServiceLoader class, but the same concept can apply within plugin categories regarding version compatibility or capability negotiation. Most plugins (besides the "Core" category in Log4j) are for creating components that can be referenced by name, and some plugins have their own syntax for usage (like the pattern conversion keys using a printf-style syntax). Plugins that take configuration data to instantiate would require a configuration tree.
I just looked at commons-configuration briefly, and while it sounds fairly useful in theory, I'm not so sure about some of the APIs in use. Maybe it's adaptable, though I'd have to look more closely. I see that its expression language uses commons-jexl, for example, while we have a fairly minimal string substitution engine (via the StrLookup plugins) which can be used here without depending on JavaEE APIs. Similarly, the bean-related config stuff uses commons-beanutils, something we didn't really need to use here (though some of that is thanks to lambdas making Java less verbose these days). For JSON configuration, we can support that without a dependency by including a minimal JSON parser (like in Log4j), though different formats could easily use different libraries for the implementation. The commons-vfs integration looks interesting (we have something supported for JBoss-style VFS URLs at least). On Mon, Apr 4, 2022 at 10:51 AM Ralph Goers <ralph.go...@dslextreme.com> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
