I believe it would be a great proof of the whole concept if the DI system could be plugged into the new commons plugin system using the SPI commons plugin provides for plugins.
On Thu, Apr 14, 2022 at 8:00 PM Matt Sicker <boa...@gmail.com> wrote: > 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 > > -- Peter Verhas pe...@verhas.com t: +41791542095 skype: verhas
