- slf4j-dev - mailman3.qos.ch

[JIRA] Updates for SLF4J-579: Export slf4j packages in version 1 and 2 in OSGi-Manifests
by slf4j developers list 07 Jul '23

07 Jul '23

SLF4J / SLF4J-579 [Resolved] Export slf4j packages in version 1 and 2 in OSGi-Manifests ============================== 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-579 ============================== 1 comment ------------------------------ Ceki Gülcü on 07/Jul/23 10:31 [~kwin] Hello, I am assuming that in your application context, migration to SLF4J 2.0 in one go is not possible because some packages in your application context are outside of your control? Am I reading this correctly? I apologize for the naive question. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-579: Export slf4j packages in version 1 and 2 in OSGi-Manifests
by slf4j developers list 07 Jul '23

07 Jul '23

SLF4J / SLF4J-579 [Resolved] Export slf4j packages in version 1 and 2 in OSGi-Manifests ============================== 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-579 ============================== 1 comment ------------------------------ Hannes Wellmann on 07/Jul/23 9:51 > Was there a specific non-backwards compatible change in 2.x which prevents exporting {{org.slf4j.helpers}} still with version 1.x? That would IMHO contradict I did a did of this package between the {{master}} and the {{1.7-maintenance}} branch and only found additions or internal changes, so it should be backwards compatible. But maybe I oversaw something. ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[JIRA] Updates for SLF4J-579: Export slf4j packages in version 1 and 2 in OSGi-Manifests
by slf4j developers list 06 Jul '23

06 Jul '23

SLF4J / SLF4J-579 [Resolved] Export slf4j packages in version 1 and 2 in OSGi-Manifests ============================== 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-579 ============================== 1 comment ------------------------------ Konrad Windszus on 06/Jul/23 8:09 At least [https://www.javadoc.io/doc/org.slf4j/slf4j-api/1.7.25/org/slf4j/helpers/Mes…] is pretty common to be used also outside logging backends (compare with https://issues.apache.org/jira/browse/SLING-11906?focusedCommentId=17732425…) Also there is no indication on [https://www.javadoc.io/doc/org.slf4j/slf4j-api/1.7.25/org/slf4j/helpers/pac…] that the package should only be used from logging implementations.... Was there a specific non-backwards compatible change in 2.x which prevents exporting that package still with version 1.x? ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)

1 0

[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