Thank Ralph for the answer related ServiceLoader. I understand your concerns. A new commons plugin module is in place if we identify the needs unmet with modern Java. However, the shortcomings you listed are mainly related to Java 8 and older versions. Thus I would appreciate it if you could clarify the followings:
>Loading all of Log4j’s plugins via ServiceLoader would be very slow What kind of measurements and benchmarks show that? I have never had any issue with speed using ServiceLoader, as it is a standard way to load classes and get their objects which may not be there during the compile time. For example, my Jamal macro language loads all the macros and debuggers as services. SLF4J relies on ServiceLoader. > and would require every >plugin be listed in the service configuration file. I do not understand what configuration file you are talking about. You implement an interface when you develop a service to be loaded by the JDK ServiceLoader. In addition to that, you either list the full name of the class in a text file inside your library, and the name of the file is the fully qualified name of the interface (this is the old style, pre-Java-9, and Java module systems), or you declare your service in the module-info.java file. >This has several problems: >1. A service must have a constructor that accepts no parameters. You can also have a provider method in the service implementing class. There is some flexibility introduced in Java 9. >2. Manually configuring every plugin in the META-INF/services file would be painful. This is opinionated. There is no point debating opinions. Editing a text file and inserting the name of the fully qualified name of the class never felt painful significantly since editors like IntelliJ help you copy/paste the fully qualified names. If you find it cumbersome to maintain these files manually, you can also use annotation processors to generate them. I have never used it, but Spring @AutoService does something like that. In addition to that, you do not need to have the old-style META-INF/services files if you use Java 9 or newer. >3. Every plugin might have its own unique configuration. ServiceLoader provides no mechanism >for configuration. This is true, but other modules, like commons configuration, do. This is also discussed by others, so let's not focus on this one. I know that there are areas for plugins, which are not supported by the JDK service loader mechanism, but I am skeptical that these can be implemented in a library in a general way. One example is the version negotiation, which is very much application-specific. Another one is suitability negotiation, when your application may face several implementations of the service and there is room only for one: the best fitting for the purpose. These are very much application-specific and there are no widely accepted industry best practice standards. On Mon, 4 Apr 2022 at 04:51, 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 > >
