Yes, at this point, it would help to see what aspects of this would be useful or welcomed as a library. In the meantime, I've been asked if I could port the log4j DI system back to 2.x, so I may end up working on that in the near term and defer any work to extract code to Commons until we have a better idea of what a Commons component would look like.
I can say that a requirement from the Log4j side of things is having a dependency-free library was one important aspect. Another seemingly obvious yet rarely done requirement was that the DI library shouldn't themselves depend on Log4j or SLF4J; in log4j-plugins, I can work around this fairly simply by using StatusLogger, though the DI library I started with didn't even log anything (errors were surfaced through exceptions only). When a library wants to have plugins, you end up in a dependency loop where Spring wants to use libA, but libA wants to use Spring for its plugin system; how does this work? At an application level, though, this is less of a concern. On Thu, Apr 14, 2022 at 7:12 AM Eric Bresie <ebre...@gmail.com> wrote: > > It sounds like embedded in this discussion are some use cases / requirements. > Would quantifying these some with a high level list of features that this > plugin architecture is to provide? > > What would the basic functionality and/or interfaces be…something like: > - Register Plugin/Services > - Plugin/Service Configuration > - Lookup Plugin/Service > - Invoke Plugin/Service > - Annotation for Plugin/Services > - Service/Adapter Interface for use with External module systems (i.e. doing > generically in common-plugin to make calls to external module system)? > > What kind of test cases would be applicable to buy into acceptance? > > Would common-plugin be similar to maven where there is the basic core > functionality with addition plugin’s providing new “goal”/functionality to > provide additional compatibility (i.e. import plugin.osgi, import > plugin.spring, etc.). and/or provide a wrapper/adapter between module > systems? So assume the above would provide the core and the subsequent > “adapter” layer or plugin for each could be implemented separately (either > internal or external to the project). > > Eric Bresie > ebre...@gmail.com (mailto:ebre...@gmail.com) > > On April 12, 2022 at 5:10:25 PM CDT, Thomas <t...@online.de > > (mailto:t...@online.de)> wrote: > > > > > > > Users should be required to do as little as possible to adapt the > > > > > plugin system to the environment it is running in*but plugins > > > > > shouldn’t know or care anything about how they are located and > > > > > loaded.* Plugins are also to the > > > > > application or framework that will be using them. They essentially > > > > > define what > > > > > the valid plugin types are and where they can be used. > > > > This is impossible. The bare minimum, any system or artifact has to do, > > > > to be recognized as a plugin, is advertising itself as one. That would > > > > be true, even if your service locator is crawling through every class > > > > of the classloader it can get hold of to determine, whether it is a > > > > candidate to consider. > > > > > > > > - OSGI does this by parsing the MANIFEST and OSGI-INF > > > > > > > > - Spring uses a combination of XML and crawling annotations and packages > > > > > > > > Every other CDI framework does it similar to these two, most of them > > > > heavily reliying on XML- or property based configuration too. With one > > > > notable exception: the dreaded ServiceLoader mechanism, which fixes > > > > this during compile time in the module-info, if you use JPMS, else > > > > mapping it in META-INF/services with simple plain text files, that > > > > require no parsing other then getting the line breaks right - no > > > > reflection / premature loading required. (Which btw, I think is the > > > > slickest solution so far, as it does make service discovery very cheap > > > > for small systems, with few class path entries. Complication is > > > > inevitably the result of large classpaths, that require plugin > > > > arbitration to resolve ambiguities and filtering) > > > > > > > > So no: at the very least, a plugin has to know, by what plugin system > > > > it is going to be loaded. And - a different hyperbole: because of this, > > > > apache commons has started to introduce the attributes required by OSGi > > > > into the MANIFESTs of many of its components, just to bridge the gap, > > > > and to aleviate the need to for OSGi-Users to introduce wrappers. > > > > > > > > For me, this will be all well and fine, as long as none of the current > > > > or future apache commons artefacts will become unusable unless I also > > > > put commons-plugin or some arcane configuration parser into the class > > > > path. > > > I never said a plugin shouldn’t know it is a plugin. Providing the > > > manifest entries required to make a component usable in an OSGi > > > environment doesn’t mean the Plugin has to know it is being used in a an > > > OSGi environment. Likewise, providing a module-info.java doesn’t mean the > > > plugin will be used as part of a module on a module path. Using Log4j as > > > an example once again, its Plugins know that they are a Filter, Appender, > > > Lookup, Layout, or whatever. But they have no knowledge of how they were > > > loaded. They DO know that they are being used by Log4j for a specific > > > purpose and what contract they have to implement for that, but that is > > > exactly what plugins are for. > > > > > > So I guess Log4j is doing the impossible? > > > > > ... only if your Log4J plugins would be automagically recognised as > > regular plugins by other frameworks, ranging from OSGi, to Spring, CDI, > > Jakarta, Plexus, Avalon, Netbeans, JMeter, ANT, Gradle, ... without > > adding the required plugin descriptors these systems need to find it. It > > probably wouldn't. In IT and programming, to know generally means, to > > directly refer to it. In this case: to refer to the plugin > > infrastructure supported. So your plugin is plugin, not just because it > > has the string 'plugin', somewhere in the documentation; it's not just > > any plugin, but a Log4J plugin, and knows it. No magic there. > > > > BTW.: I can see, that there may be some need to add some convenience to > > the bare ServiceLoader mechanism, in order to standardise/support some > > version/feature/provider negotiation in certain corner cases. I would > > even see usecases for that in commons components like vfs, encoding, > > compress etc, that are meant to offer a facade to plugable > > implementations of a certain family. > > > > But I don't think, there is a need to support an other full fledged > > module or plugin framework with features like dependency injection, > > component lifecycle management, interceptor chains, not to speak of > > interpolating configuration values from sources outside of Java. Even > > less do I feel the need to have an abstraction layer that enables us to > > swap out say, CDI for Spring or OSGi. Don't tempt me to cite XKCD 927 on > > you! > > > > Cheers, Thomas > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > (mailto:dev-unsubscr...@commons.apache.org) > > For additional commands, e-mail: dev-h...@commons.apache.org > > (mailto:dev-h...@commons.apache.org) > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
