Re: Re: New component proposal: commons-plugins
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 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 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)> 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. Providi
Re: Re: New component proposal: commons-plugins
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 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 > (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
Re: Re: New component proposal: commons-plugins
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 (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
