- slf4j-dev - mailman3.qos.ch

Re: [slf4j-dev] "URI is not absolute" error in tests
by Toolforger 07 May '18

07 May '18

Sure. Would you like a PR that extends README.md with a paragraph? Am 06.05.2018 um 17:45 schrieb Ceki: > Can you please document the steps in getting the build running for the > benefit of the followers? > > On 06.05.2018 11:56, Toolforger wrote: >> Hi all, >> >> Now that I finally got the build running, I still see "URI is not >> absolute" errors in various tests in the "SLF4J Extensions Module". >> Should I worry? >> >> Regards >> Jo >> _______________________________________________ >> slf4j-dev mailing list >> slf4j-dev(a)qos.ch >> http://mailman.qos.ch/mailman/listinfo/slf4j-dev >

2 2

"URI is not absolute" error in tests
by Toolforger 06 May '18

06 May '18

Hi all, Now that I finally got the build running, I still see "URI is not absolute" errors in various tests in the "SLF4J Extensions Module". Should I worry? Regards Jo

2 1

[JIRA] (SLF4J-436) Logger name mismatch when using Spock
by QOS.CH (JIRA) 02 May '18

02 May '18

[ https://jira.qos.ch/browse/SLF4J-436?page=com.atlassian.jira.plugin.system.… ] Tobias Gruetzmacher commented on SLF4J-436: ------------------------------------------- Here is the (truncated) content of *trace* in *Util.getCallingClass()*: {noformat} org.slf4j.helpers.Util$ClassContextSecurityManager org.slf4j.helpers.Util org.slf4j.LoggerFactory x x org.slf4j.LoggerFactory$getLogger org.codehaus.groovy.runtime.callsite.CallSiteArray org.codehaus.groovy.runtime.callsite.AbstractCallSite org.codehaus.groovy.runtime.callsite.AbstractCallSite org.example.MismatchTest sun.reflect.NativeConstructorAccessorImpl sun.reflect.DelegatingConstructorAccessorImpl java.lang.reflect.Constructor org.junit.runners.BlockJUnit4ClassRunner{noformat} First column marks the entry which is selected by *getCallingClass()*, second column is the flag *isSynthetic* of that *Class<?>* object, this might be used to implement a workaround in *getCallingClass()* ... Would it be a viable solution to skip synthetic classes in this method? I wonder if it would be a good idea to also skip all those groovy frames somehow?!? > Logger name mismatch when using Spock > ------------------------------------- > > Key: SLF4J-436 > URL: https://jira.qos.ch/browse/SLF4J-436 > Project: SLF4J > Issue Type: Bug > Components: Core API > Affects Versions: 1.7.25, 1.8.0-beta2 > Reporter: Tobias Gruetzmacher > Assignee: SLF4J developers list > Priority: Minor > > When using the Spock Framework ([http://spockframework.org/) in combination with *slf4j.detectLoggerNameMismatch* you get logger mismatch messages like this: > {noformat} > SLF4J: Detected logger name mismatch. Given name: "org.example.MismatchTest"; computed name: "org.slf4j.LoggerFactory$getLogger". > SLF4J: See http://www.slf4j.org/codes.html#loggerNameMismatch for an explanation{noformat} > It seems that Spock does some magic with its test classes... > Sample maven project attached. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-436) Logger name mismatch when using Spock
by QOS.CH (JIRA) 01 May '18

01 May '18

[ https://jira.qos.ch/browse/SLF4J-436?page=com.atlassian.jira.plugin.system.… ] Tobias Gruetzmacher commented on SLF4J-436: ------------------------------------------- After some more prodding, the culprit here isn't even spock, but in Groovy: Whenever you use Groovy's metaObject, the call to getLogger goes through some internal Groovy classes... > Logger name mismatch when using Spock > ------------------------------------- > > Key: SLF4J-436 > URL: https://jira.qos.ch/browse/SLF4J-436 > Project: SLF4J > Issue Type: Bug > Components: Core API > Affects Versions: 1.7.25, 1.8.0-beta2 > Reporter: Tobias Gruetzmacher > Assignee: SLF4J developers list > Priority: Minor > Attachments: slf4j-spock-name-mismatch.zip > > > When using the Spock Framework ([http://spockframework.org/) in combination with *slf4j.detectLoggerNameMismatch* you get logger mismatch messages like this: > {noformat} > SLF4J: Detected logger name mismatch. Given name: "org.example.MismatchTest"; computed name: "org.slf4j.LoggerFactory$getLogger". > SLF4J: See http://www.slf4j.org/codes.html#loggerNameMismatch for an explanation{noformat} > It seems that Spock does some magic with its test classes... > Sample maven project attached. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-436) Logger name mismatch when using Spock
by QOS.CH (JIRA) 30 Apr '18

30 Apr '18

Tobias Gruetzmacher created SLF4J-436: ----------------------------------------- Summary: Logger name mismatch when using Spock Key: SLF4J-436 URL: https://jira.qos.ch/browse/SLF4J-436 Project: SLF4J Issue Type: Bug Components: Core API Affects Versions: 1.8.0-beta2, 1.7.25 Reporter: Tobias Gruetzmacher Assignee: SLF4J developers list Priority: Minor When using the Spock Framework ([http://spockframework.org/) in combination with *slf4j.detectLoggerNameMismatch* you get logger mismatch messages like this: {noformat} SLF4J: Detected logger name mismatch. Given name: "org.example.MismatchTest"; computed name: "org.slf4j.LoggerFactory$getLogger". SLF4J: See http://www.slf4j.org/codes.html#loggerNameMismatch for an explanation{noformat} It seems that Spock does some magic with its test classes... -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 25 Apr '18

25 Apr '18

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Gordon commented on SLF4J-371: ------------------------------ I like @Mezītis idea. Just have logLevel(Supplier) and logLevel(Supplier, ex). Seems it would be much simpler API-wise and less confusing not having to remember that if one parameter is a Supplier they all have to be. > Support the lambda expression in the Logger > ------------------------------------------- > > Key: SLF4J-371 > URL: https://jira.qos.ch/browse/SLF4J-371 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.7.22 > Reporter: MiNG > Assignee: SLF4J developers list > > In some cases, we don't want to calculate the expression for logging eagerly cause the performance reason. Then, we would write the code like the following: > {code:java} > if (LOGGER.isWarnEnabled()) > { > LOGGER.warn("some message: {}", Json.serialize(obj)); > }{code} > Before JDK8, there is no way to encapsulate the above code, because the expression is always calculated before passed as an argument. So, many "if"s appear in the code and smell badly. > Now, the lambda expression is supported by JDK8, the above could be simplified like following: > {code:java} > LOGGER.warn(formatter -> formatter.format("some message: {}", Json.serialize(obj)));{code} > With the default method definition in the org.slf4j.Logger: > {code:java} > public interface Logger > { > default void warn(Function<MessageFormatter, String> messageSupplier) > { > if (this.isWarnEnabled()) > { > /* Calculate the expression only if the WARN level logging is enabled. */ > this.warn(messageSupplier.apply(this.getFormatter())); > } > } > }{code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-371) Support the lambda expression in the Logger
by QOS.CH (JIRA) 25 Apr '18

25 Apr '18

[ https://jira.qos.ch/browse/SLF4J-371?page=com.atlassian.jira.plugin.system.… ] Michael Bürkle commented on SLF4J-371: -------------------------------------- Please consider implementing this earlier. I imagine it would be rather easy to implement and it would help a great deal with cleanliness of client code. > Support the lambda expression in the Logger > ------------------------------------------- > > Key: SLF4J-371 > URL: https://jira.qos.ch/browse/SLF4J-371 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.7.22 > Reporter: MiNG > Assignee: SLF4J developers list > > In some cases, we don't want to calculate the expression for logging eagerly cause the performance reason. Then, we would write the code like the following: > {code:java} > if (LOGGER.isWarnEnabled()) > { > LOGGER.warn("some message: {}", Json.serialize(obj)); > }{code} > Before JDK8, there is no way to encapsulate the above code, because the expression is always calculated before passed as an argument. So, many "if"s appear in the code and smell badly. > Now, the lambda expression is supported by JDK8, the above could be simplified like following: > {code:java} > LOGGER.warn(formatter -> formatter.format("some message: {}", Json.serialize(obj)));{code} > With the default method definition in the org.slf4j.Logger: > {code:java} > public interface Logger > { > default void warn(Function<MessageFormatter, String> messageSupplier) > { > if (this.isWarnEnabled()) > { > /* Calculate the expression only if the WARN level logging is enabled. */ > this.warn(messageSupplier.apply(this.getFormatter())); > } > } > }{code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-435) Minor typo in FAQ
by QOS.CH (JIRA) 23 Apr '18

23 Apr '18

Sam Mefford created SLF4J-435: --------------------------------- Summary: Minor typo in FAQ Key: SLF4J-435 URL: https://jira.qos.ch/browse/SLF4J-435 Project: SLF4J Issue Type: Bug Components: Unspecified Environment: https://www.slf4j.org/faq.html Reporter: Sam Mefford Assignee: SLF4J developers list Priority: Trivial The last character in this paragraph appears to be incorrect: {quote}SLF4J only cares about the _formatting anchor_, that is the '\{' character immediately followed by '}'. Thus, in case your message contains the '\{' or the '}' character, you do not have to do anything special unless the '}' character immediately follows '}'. {quote} Shouldn't it end with "immediately follows '\{'."? -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-154) Copy & paste of LoggerFactory.getLogger
by QOS.CH (JIRA) 23 Apr '18

23 Apr '18

[ https://jira.qos.ch/browse/SLF4J-154?page=com.atlassian.jira.plugin.system.… ] Joachim Durchholz commented on SLF4J-154: ----------------------------------------- Oh. It just occurred to me that there should not be much code bloat from LoggerFactory.getClassLogger() if the code to extract the class name is already in place for detectLoggerNameMismatch. > Copy & paste of LoggerFactory.getLogger > --------------------------------------- > > Key: SLF4J-154 > URL: https://jira.qos.ch/browse/SLF4J-154 > Project: SLF4J > Issue Type: Bug > Components: Core API > Environment: Operating System: All > Platform: All > Reporter: Thomas Mueller > Assignee: SLF4J developers list > Attachments: clipboard.png > > > This is a feature request. > Currently, when I create a new logger in a class, I copy & paste the following line from another class: > private static Logger log = LoggerFactory.getLogger(AcmeImpl.class); > Sometimes I forget to change the class name. SLF4J could help me here. I suggest to add a new method, so the class name is not required, so that I can copy & paste the line without having to remember that I have to change the class name. Also, it's a bit shorter: > private static Logger log = LoggerFactory.getCallerClassLogger(); > This is copy & paste friendly. The implementation is tricky, but trivial once you understand it: > getCallerClassLogger() { > return getLogger(new Error().getStackTrace()[1].getClassName()); > } > There is a project that tries to solve the copy & paste problem: http://code.google.com/p/morbok/ -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-154) Copy & paste of LoggerFactory.getLogger
by QOS.CH (JIRA) 23 Apr '18

23 Apr '18

[ https://jira.qos.ch/browse/SLF4J-154?page=com.atlassian.jira.plugin.system.… ] Joachim Durchholz commented on SLF4J-154: ----------------------------------------- The selling point of having a copy&paste-capable logger setup line without having to think, so you can concentrate on your class logic. The MethodHandles method sort-of achieves that (it does for a colleague who is good at remembering things, I am not so it does not work very well for me). Spotting incorrectly named loggers after the fact sort-of achieves that, too, depending on wether that error message comes as a distraction from more serious problems, or as the only, quickly-fixed problem. It's still more overhead than necessary (to be weighed against code bloat in SLF4J, but in this case I think it's worth it since SLF4J is about making logging a no-brainer). > Copy & paste of LoggerFactory.getLogger > --------------------------------------- > > Key: SLF4J-154 > URL: https://jira.qos.ch/browse/SLF4J-154 > Project: SLF4J > Issue Type: Bug > Components: Core API > Environment: Operating System: All > Platform: All > Reporter: Thomas Mueller > Assignee: SLF4J developers list > Attachments: clipboard.png > > > This is a feature request. > Currently, when I create a new logger in a class, I copy & paste the following line from another class: > private static Logger log = LoggerFactory.getLogger(AcmeImpl.class); > Sometimes I forget to change the class name. SLF4J could help me here. I suggest to add a new method, so the class name is not required, so that I can copy & paste the line without having to remember that I have to change the class name. Also, it's a bit shorter: > private static Logger log = LoggerFactory.getCallerClassLogger(); > This is copy & paste friendly. The implementation is tricky, but trivial once you understand it: > getCallerClassLogger() { > return getLogger(new Error().getStackTrace()[1].getClassName()); > } > There is a project that tries to solve the copy & paste problem: http://code.google.com/p/morbok/ -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0