Le mar. 12 avr. 2022 à 21:31, Ralph Goers <ralph.go...@dslextreme.com> a écrit :
> > > > On Apr 12, 2022, at 6:56 PM, Thomas <t...@online.de> wrote: > > > > > > On 11.04.2022 00:00, Ralph Goers wrote: > >> See below > >> > >>> On Apr 8, 2022, at 9:23 AM, Peter Verhas<pe...@verhas.com> wrote: > >>> > >>> Thanks Ralph for the detailed explanation. I appreciate it and now I > see > >>> the points. > >> I’ve removed the parts that I don’t think need any more discussion. > >> > >>> - How will it be a “plugin" project and not another dependency > injection > >>> framework? > >> This is a great question. I think the main difference is with examples > like Log4j > >> and Apache Flume, and even Apache Maven. All wire components together > via > >> user provided configuration, not code. Dependency injection could > certainly be > >> part of the plugin framework but that would be for implementors of > plugins, > >> not the users using them. Users of Maven don’t know that Plexus is used > under > >> the covers and neither should users of a commons-plugins implementation. > >> > >>> - What will distinguish it from module systems, like OSGi and what will > >>> stop it from becoming another OSGi by the years as new features get > added > >>> to the library. > >> OSGi is complicated. Implementing plugins should not be. Just as I > described > >> using ServiceLoader to locate plugins, plugins should also be > accessible in > >> OSGi bundles. 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? It would if it would be all IoC natively integrated as all plugin systems but log4j created its own in parallel - for good and bad reasons, not discussing it there. So overall log4j just does like other IoC as of today ;). > > Ralph > > >
