June 2023 - slf4j-dev - mailman3.qos.ch

[JIRA] Updates for SLF4J-593: Overhaul of certification mechanism
by slf4j developers list 29 Jun '23

29 Jun '23

SLF4J / SLF4J-593 [Open] Overhaul of certification mechanism ============================== Here's what changed in this issue in the last few minutes. This issue has been created View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-593 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 29/Jun/23 14:39 Summary: Overhaul of certification mechanism Issue Type: Improvement Assignee: Ceki Gülcü Components: Unspecified Created: 29/Jun/23 14:39 Priority: Major Reporter: Ceki Gülcü Description: Certification renewal needs a testing mechanism. Tests should cover multi-dns multi-server hosting as well as site names with and without preceding www, such as [www.slf4j.org|http://www.slf4j.org/] and slf4j.org. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-592: Mechanism for indicating provider to use for unit tests.
by slf4j developers list 22 Jun '23

22 Jun '23

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 22/Jun/23 18:17 I've filed a [ticket|https://github.com/eclipse-jdt/eclipse.jdt.core/issues/1183] for the Eclipse platform to add a facility to allow m2e to inform them of system properties derived from the POM (because apparently [this works in IntelliJ|https://youtrack.jetbrains.com/issue/IDEA-101185] but that probably wouldn't be done for months/years, if every. Here's another idea, inspired by [this comment|https://github.com/eclipse-m2e/m2e-core/issues/174#issuecomment-160…] following the [fundamental theorem|https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engin…] SLF4J could add a {{ServiceProviderNegociator}}, which is another layer of indirection in determining the provider. If a {{ServiceProviderNegociator}} is registered on the classpath (using the same service provider registration mechanism), then {{LoggerFactory.bind()}} would delegate to the {{ServiceProviderNegociator.chooseServiceProvider()}} method; otherwise it would call {{LoggerFactory.findServiceProviders()}} and use the current logic as normal. To address the test logger use case then, one would add both {{org.slf4j:slf4j-simple}} and {{org.example:provider-negociator-only-slf4j-simple}} to the parent POM, both with scope {{test}}, and things would just work. This approach allows for priorities, etc. as well, by pushing off the negotiation decision to {{ServiceProviderNegociator}}. Third parties could provide their own {{ServiceProviderNegociator}} to lookup based upon priorities or whatever. (Of course then there is the issue of choosing among multiple {{ServiceProviderNegociator}} s. 😅 Maybe you could prohibit multiple {{ServiceProviderNegociator}} s.) Adding another provider interface and an additional layer of indirection is not to be done lightly. I present it here as brainstorming if nothing else. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-592: Mechanism for indicating provider to use for unit tests.
by slf4j developers list 22 Jun '23

22 Jun '23

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 22/Jun/23 17:20 {quote}If we are taking the route of system properties, we could simply let the developer tell us the preferred provider.{quote} Ceki this is an exciting idea. (I guess brainstorming works!) Before walking through the pros and cons of that approach, I decided to test it. It works fine with the Maven Surefire Plugin (e.g. {{mvn test}} on the command line). Unfortunately it doesn't work in Eclipse, because it turns out that the Eclipse IDE test subsystem is not connected to m2e at all; see my [comment|https://github.com/eclipse-m2e/m2e-core/issues/174#issuecomment-160…] at [m2e Issue #174|https://github.com/eclipse-m2e/m2e-core/issues/174]. Using this in an IDE was one of the main motivations of this request. This holds a lot of promise, but I'm going to pause and think more about the ecosystem for a bit. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-592: Mechanism for indicating provider to use for unit tests.
by slf4j developers list 22 Jun '23

22 Jun '23

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 ------------------------------ Ceki Gülcü on 22/Jun/23 11:04 If we are taking the route of system properties, we could simply let the developer tell us the preferred provider. For example: {{java -Dslf4j.provider=org.slf4j.simple.SimpleServiceProvider ...}} Even if multiple providers are available, slf4j would pick up {{SimpleServiceProvider}}. Seems easy enough. Would this work for you? ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-592: Mechanism for indicating provider to use for unit tests.
by slf4j developers list 21 Jun '23

21 Jun '23

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 ------------------------------ Ceki Gülcü on 21/Jun/23 23:26 [~garretwilson] I agree that priority might not be appropriate concept here and that profile would fit much better. Thank you for sharing your insights! ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-592: Mechanism for indicating provider to use for unit tests.
by slf4j developers list 21 Jun '23

21 Jun '23

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-xp…] {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)

1 0

[JIRA] Updates for SLF4J-592: Mechanism for indicating provider to use for unit tests.
by slf4j developers list 21 Jun '23

21 Jun '23

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:11 Here are some extra thoughts for brainstorming. While I believe a facility to set the priority will address this use case, I think it's a bit of misuse of a priority system (although it may be the only practical solution). Normally we would use a priority system to say, "OK, I can live with that, but hey, I'd really like this other thing better." In this case, it's not that we like one or the other better, but it's that we want two different providers to be used _in different contexts_! Another approach would be to have each provider publish one or more "profile" identifiers (e.g. {{Set<String>}}). (I almost called it "context" but I don't want to confuse the concept with an in-application context, e.g. LOGBACK-1196.) Existing providers wouldn't have to change; SLF4J would consider them to be indicating no profile. If multiple providers were present on the classpath, SLF4J would no longer produce a warning; it would by default choose the one that did not indicate a profile (again providing backwards compatibility). And the existing SLF4J API would work the same when calling {{LoggerFactory.getILoggerFactory()}} and the like—it would return the provider that didn't indicate a profile. But here's the interesting part: SLF4J would provide some external method of indicating the "profile". Maybe it would be a system property. It would work conceptually similar to [Spring Boot {{spring.profiles.active}}|https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto.properties-and-configuration.set-active-spring-profiles]. {{LoggerFactory.bind()}} would look for this system property and if found, it would try to find and give priority to a logging provider that published its support of that profile. Again this would fall back to providers that publish support of no profiles, so existing providers would work just the same. It turns out the Maven Surefire Plugin provides a way to [set a system property for all unit tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/syst…] So with this technique, I could publish a provider that indicates it prefers the {{test}} profile. Then in the Maven Surefire Plugin I simply set the system profile to {{slf4j.profile=test}}. Suddenly all my tests will be using the provider designated for test. I'm just brainstorming here. The concept is very similar to Spring Boot active profiles, and I think it better captures what's trying to be done here. Priority sorting is a separate but complementary thing, but could be made to work. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-592: Mechanism for indicating provider to use for unit tests.
by slf4j developers list 21 Jun '23

21 Jun '23

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 are 2 comments. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-592 ============================== 2 comments ------------------------------ Ceki Gülcü on 21/Jun/23 21:48 [~garretwilson] The provider ordering mechanism would be part of SLF4J. I only mentioned logback configurators as an example for inspiration. In logback 1.4.9 (experimental/unreleased), Configurator implementations declare their priority via an annotation. This annotation is part of the configurator class and cannot be altered without altering the compiled class. This approach might be more rigid than what you may have had in mind but should work assuming you create your own SLF4J providers... A custom provider can potentially consist of only a single class implementing SLF4JServiceProvider having the right order annotation and delegating to an existing implementation such as slf4j-simple. ------------------------------ Garret Wilson on 21/Jun/23 21:53 {quote}The provider ordering mechanism would be part of SLF4J. … This approach might be more rigid than what you may have had in mind but should work assuming you create your own SLF4J providers.{quote} OK that sounds workable. I don't mind publishing a simple {{stdout}} logging provider (or a version of {{slf4j-simple}}) with its priority set high. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-592: Mechanism for indicating provider to use for unit tests.
by slf4j developers list 21 Jun '23

21 Jun '23

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 19:30 I updated the title to better reflect the use case we're trying to address here to keep from potentially getting sidetracked focusing on one particular approach until we know it's the best solution. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-592: Programmatically specify fallback provider for unit tests.
by slf4j developers list 21 Jun '23

21 Jun '23

SLF4J / SLF4J-592 [Open] Programmatically specify fallback provider for unit tests. ============================== Here's what changed in this issue in the last few minutes. There are 2 comments. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-592 ============================== 2 comments ------------------------------ Garret Wilson on 21/Jun/23 19:01 {quote}Logback version 1.4.9 (unreleased as of yet) introduces a sorting mechanism for configurators.{quote} Conceptually (ignoring the configuration for the moment), that would address the use case: * The parent POM would declare {{slf4j-simple}} with a high priority, but only for {{test}} scope. * If a child project specifies a compile-time provider, it would be used normally. * If a child project specifies a compile-time provider, when running the tests {{slf4j-simple}} would be used instead because of its higher priority, but not interfere with the normal provider when not running tests. * If a child project does not specify compile-time provider, there would be no provider at all except when tests were running, in which case {{slf4j-simple}} would run That is the behavior I'm looking for (and I would imagine most users would be looking for). The snag is with configuration. I would need to configure {{slf4j-simple}} as a high priority _merely by including it in the pom with {{test}} scope_. There parent POM has no mechanism to muck with provider configuration inside {{META-INF}}. I guess the way around this is for you or me to release a {{slf4j-simple-high-priority}} artifact that already has the priority set to high, and include that artifact as {{test}} scope. But I'm still not understanding, if this sorting mechanism is specific to Logback, how it would work out if I include {{slf4j-simple-high-priority}} in the parent POM with {{test}} scope, and the child project is using Log4j as its provider. (And in fact this is exactly the scenario I'm working with; the AWS Lambda logging libraries are hard-coded to use Log4J, even though some of us are [prodding them to switch fully to SLF4J|https://github.com/aws-powertools/powertools-lambda-java/issues/965] and I'm [cajoling them to upgrade dependencies to SLF4J 2.x|https://github.com/aws-powertools/powertools-lambda-java/issues/1180] .) When I run the tests, wouldn't SLF4 still give me a warning because I have two providers on the classpath: Log4J in the main classpath, and {{slf4j-simple-high-priority}} on the test classpath? It seems to me there is no way Logback's new feature can resolve this. The sort of resolution I'm talking about has to be a part of the SLF4J provider mechanism. ------------------------------ Garret Wilson on 21/Jun/23 19:07 {quote}A test provider can have higher priority than the production provider.{quote} Yes that's basically the gist of it, with the understanding that the production provider and test provider may be different logging implementations altogether. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0