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