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
For additional commands, e-mail: dev-h...@commons.apache.org
