[slf4j-dev] [JIRA] Updates for SLF4J-592: Mechanism for indicating provider to use for unit tests.

[slf4j developers list]

SLF4J / SLF4J-592 [Open]
Mechanism for indicating provider to use for unit tests.

==============================

Here's what changed in this issue in the last few minutes.


There is 1 comment.


View or comment on issue using this link
https://jira.qos.ch/browse/SLF4J-592

==============================
 1 comment
------------------------------

Garret Wilson on 21/Jun/23 22:31

Note also that the general idea of "how to choose among service providers" is not new. (SLF4J currently sidesteps the issue by not allowing any decision in the choice at all.) I think the providers are supposed to publish enough information about their capabilities to make a decision, and the requestor will indicate which capabilities they need.

For example with an XML parser, the requester would say whether they need namespace handling, schema validation, and the like; in theory, many XML parsers could be registered, and Java would use the one that best matched the capabilities that were requested. This idea of a "profile" is conceptually the same thing.

The success in this area has been spotty in real life. Saxon is one example of how it hasn't succeeded: because Saxon is about the only library that supports the latest XSLT and XPath, Saxonica decided to skip the JAXP provider mechanism altogether, as described in [Selecting the XPath implementation|https://www.saxonica.com/documentation12/#!xpath-api/jaxp-xpath/factory]:

{quote}The JAXP API is designed on the basis that when your application invokes {{XPathFactory.newInstance()}}, an XPath engine is selected by examining the values of system properties and searching the classpath. If you rely on this mechanism, then your application may end up running with an XPath engine on which it has never been tested. Since different XPath engines can differ in many significant respects (most notably, the version of XPath that they support), this can easily lead to application failures. Saxon therefore no longer identifies itself (in the JAR file manifest) as a JAXP XPath supplier. If you want to load Saxon as your XPath engine, you need to select it explicitly; it's not enough to just put it on the classpath.{quote}

I think this is a shame and a failure at interoperability. I'm sure SLF4J can do better. Since currently SLF4J doesn't have _any_ algorithm for determining an implementation, I would recommend thinking hard about the concept of capability publishing in general. I would rather see some sort of decision made based upon capability and/or profile requested. "Priority" is a coarse technique with a deficit in semantics—we don't know _why_ one is prioritized over the other, and the reasons may be comparing apples to oranges—and less-than-surgical results. It may work as brute-force in some circumstances, but overall it feels like it would have the same downsides as CSS {{!important}}. Read [CSS !important: Don’t Use It. Do This Instead|https://uxengineer.com/css-specificity-avoid-important-css/] and a hundred other similar articles.


==============================
 This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)