- slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-369) Make slf4j-ext usage of CAL10N as optional depedency
by QOS.CH (JIRA) 23 Feb '17

23 Feb '17

[ https://jira.qos.ch/browse/SLF4J-369?page=com.atlassian.jira.plugin.system.… ] Jeremy Landis commented on SLF4J-369: ------------------------------------- Can you explain more? Is this getting a stack trace such as class not found if you don't include it? If so, then it's not optional. I've never ran into any issue with this so I'd like to understand it a bit. I've got slf4j & logback in 100+ applications so trying to grasp how this is an issue. I have slf4j-ext in all those too. > Make slf4j-ext usage of CAL10N as optional depedency > ---------------------------------------------------- > > Key: SLF4J-369 > URL: https://jira.qos.ch/browse/SLF4J-369 > Project: SLF4J > Issue Type: Bug > Components: slf4j-ext > Reporter: Matej Spiller-Muys > Assignee: SLF4J developers list > Priority: Critical > Fix For: 1.7.24 > > > I came across this issue because there is bug in CAL10N code (filled separately) that is crashing the compiler. But the reason for this issue is different. Slf4j-ext contains different extensions. In my case we are not even using features from cal10n, but because of slf4j-ext it is now scanning and checking my code regardless (from 0.8). Make slf4j-ext usage of CAL10N as optional dependency. > from manual: > In order to use CAL10N in a project, all you need is to add cal10n-api-0.8.1.jar onto your project's class path. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-373) SLF4J: Class path contains multiple SLF4J bindings
by QOS.CH (JIRA) 23 Feb '17

23 Feb '17

[ https://jira.qos.ch/browse/SLF4J-373?page=com.atlassian.jira.plugin.system.… ] Jeremy Landis commented on SLF4J-373: ------------------------------------- I would close this too. It's not a bug. Do you want to log to log4j 1.2 or jdk 1.4? You have to pick one and the link tells you why. So in your case, exclude one of them. If this is due to some classloading issue in EAR where those are in different WARs, while I cannot help much I would ask why are you still using EARs to start with? Almost every EAR I've ran into in my development career has been incorrectly used and completely unnecessary and with microservices all the rage, there is really no compelling reason to use them. But if you must, there are ways to fix the issue you see without having a fix to this library. > SLF4J: Class path contains multiple SLF4J bindings > -------------------------------------------------- > > Key: SLF4J-373 > URL: https://jira.qos.ch/browse/SLF4J-373 > Project: SLF4J > Issue Type: Bug > Components: Unspecified > Affects Versions: 1.7.x > Reporter: Pu Yi He > Assignee: SLF4J developers list > > In our project, there is one warning message as below when to use slf4j-1.7.5, how to resolve this issue? > - project dependency: > <dependency name="slf4j-1.7.5" type="jar" version="1.7.5"/> > this will include slf4j-api-1.7.5.jar and slf4j-log4j12-1.7.5.jar > <dependency name="hystrix" type="jar" /> > this will include slf4j-api-1.7.5.jar and slf4j-jdk14-1.7.5.jar > - warning message: > WARNING: Couldn't load build resource bundle. Build timestamp will be inaccurate *** > SLF4J: Class path contains multiple SLF4J bindings. > SLF4J: Found binding in [wsjar:file:/xxx.ear/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class] > SLF4J: Found binding in [wsjar:file:/xxx.ear/slf4j-jdk14-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]* > SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-374) while updation of application from java 6 to java 7 i found exception in SLF4j
by QOS.CH (JIRA) 23 Feb '17

23 Feb '17

[ https://jira.qos.ch/browse/SLF4J-374?page=com.atlassian.jira.plugin.system.… ] Jeremy Landis commented on SLF4J-374: ------------------------------------- I"d close this issue. If that did exist it might have been on earlier version. Netbeans isn't a logging environment so that is a pointless setting. Java 6, 7, 8 all work. Tomcat 6, 7, 8, 9 all work. This is fairly old but if user happens to see, please try latest release. It should work just fine. Also make sure where you have slf4j is in same classloader or higher than where the listener you have is. > while updation of application from java 6 to java 7 i found exception in SLF4j > ------------------------------------------------------------------------------ > > Key: SLF4J-374 > URL: https://jira.qos.ch/browse/SLF4J-374 > Project: SLF4J > Issue Type: Bug > Environment: Netbeans 7.2, jdk1.7.0_45,Apache Tomcat 7.0.27 > Reporter: abhijit > Assignee: SLF4J developers list > > I use slf4j-api-1.7.5.jar it is showing below when i run project > SEVERE: Exception sending context initialized event to listener instance of class zschedular.SchedularListener > java.lang.NoClassDefFoundError: org/slf4j/impl/StaticLoggerBinder -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-383) Support for JCL 1.2
by QOS.CH (JIRA) 23 Feb '17

23 Feb '17

[ https://jira.qos.ch/browse/SLF4J-383?page=com.atlassian.jira.plugin.system.… ] Jeremy Landis commented on SLF4J-383: ------------------------------------- I think there is a persistent need for some reason to keep slf4j on java 5. Slf4j was just reverted 8 days ago to java 1.5. I'm clueless as to why. Anyone still using java 5 certainly isn't updating any product so it's pretty pointless in my opinion. Commons logging 1.2 requires java 1.6 so doesn't really help the situation in this case. I have raised a concern with that issue but would suggest that you raise a pull request for this issue if you want this to happen. > Support for JCL 1.2 > ------------------- > > Key: SLF4J-383 > URL: https://jira.qos.ch/browse/SLF4J-383 > Project: SLF4J > Issue Type: Bug > Components: jcl-over-slf4j > Affects Versions: 1.7.21 > Environment: OSGI > Reporter: Florian Kolbe > Assignee: SLF4J developers list > > Similar to SLF4J-298, support for JCL 1.2 (which exists since 2014) > See https://commons.apache.org/proper/commons-logging/changes-report.html#a1.2 > As an example, commons-vfs2 2.1 imports commons-logging 1.2 > see http://repo1.maven.org/maven2/org/apache/commons/commons-vfs2/2.1/commons-v… > Example for a failing tycho build > {noformat} > [ERROR] Internal error: java.lang.RuntimeException: No solution found because the problem is unsatisfiable.: [Unable to satisfy dependency from org.apache.commons.vfs 2.1.0 to package org.apache.commons.logging [1.2.0,2.0.0).; No solution found because the problem is unsatisfiable.] -> [Help 1] > org.apache.maven.InternalErrorException: Internal error: java.lang.RuntimeException: No solution found because the problem is unsatisfiable.: [Unable to satisfy dependency from org.apache.commons.vfs 2.1.0 to package org.apache.commons.logging [1.2.0,2.0.0).; No solution found because the problem is unsatisfiable.] > {noformat} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-384) Implement slf4j to log4j2 bridge/adapter/impl
by QOS.CH (JIRA) 23 Feb '17

23 Feb '17

[ https://jira.qos.ch/browse/SLF4J-384?page=com.atlassian.jira.plugin.system.… ] Jeremy Landis commented on SLF4J-384: ------------------------------------- This issue should be closed. If anything maybe mention in slf4j document what to use from log4j2 team to integrate well if that isn't there already. I do find this to be a trival issue and user should have did a bit more research before opening a ticket. > Implement slf4j to log4j2 bridge/adapter/impl > --------------------------------------------- > > Key: SLF4J-384 > URL: https://jira.qos.ch/browse/SLF4J-384 > Project: SLF4J > Issue Type: New Feature > Reporter: John Tal > Assignee: SLF4J developers list > Priority: Minor > > Sorry if this is a dumb question. But I cannot find how slf4j would integrate on top of log4j2. > I have tried using slf4j 1.7.21 with log4j 2.7 and keep running into this: Failed to instantiate SLF4J LoggerFactory Reported exception: java.lang.NoClassDefFoundError: org/apache/log4j/Level at org.slf4j.LoggerFactory.bind(LoggerFactory.java:150) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124) > From what I can see, LoggerFactory is bound to log4j pre 2.0 as there is no .logging. in the package names: package org.slf4j.impl; import org.apache.log4j.Level; import org.slf4j.ILoggerFactory; import org.slf4j.LoggerFactory; import org.slf4j.helpers.Util; import org.slf4j.spi.LoggerFactoryBinder; /** * The binding of {@link LoggerFactory} class with an actual instance of * {@link ILoggerFactory} is performed using information returned by this class. * * @author Ceki Gülcü */ public class StaticLoggerBinder implements LoggerFactoryBinder { > If I want log4j2, and don't want to be locked into API, I can't use slf4j. I have to go back to commons-logging (JCL). Seems like a waste because JCL and it's class loader / config confusion is what led to creation of slf4j. I'd rather keep on using slf4j and plug into whatever is the fastest logging framework at the time. From all the stats I see today, that is log4j2. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[qos-ch/slf4j] e0120c: make m2eclipse happy
by Ceki Gulcu 21 Feb '17

21 Feb '17

Branch: refs/heads/master Home: https://github.com/qos-ch/slf4j Commit: e0120c1473b5c2d3888443738493cf635ce275be https://github.com/qos-ch/slf4j/commit/e0120c1473b5c2d3888443738493cf635ce2… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2017-02-21 (Tue, 21 Feb 2017) Changed paths: M slf4j-api/pom.xml Log Message: ----------- make m2eclipse happy

1 0

Several improvements in MessageFormatter
by Николай Федоровских 20 Feb '17

20 Feb '17

Hi All, I made some optimizations in MessageFormatter such as: avoid redundant instantiations, replace HashMap to IdentityHashMap, reduce checks for arrays args, etc. PR: https://github.com/qos-ch/slf4j/pull/171 Can you look at this, please? Thanks! ---- Regards, Nikolay Fedorovskikh.

2 4

Support for structured logging in SLF4J 2.0
by João Cabrita 19 Feb '17

19 Feb '17

Hi, I've been looking through the issue tracker and I've found that there is a 2.0 release planned which would include some API changes. I've been working a lot with Graylog lately, and am of the opinion that SLF4J's API doesn't really cover that use case in a way that feels natural, so I'd like to know if such structured logging approaches could be covered in the new release. For example, besides the regular message, Graylog supports adding custom fields to logs. Although this is supported by SLF4J through MDC, sometimes you only need the one log statement with a given field, in which case MDC is inconvenient because you'd need to: 1. Add the value to the MDC 2. Log 3. Remove the value One way I can think of doing this is replacing the formatted approach, i.e.: log.info("This is a message with {}", "some value"); with log.info("This is a message", singletonMap("value", "some value")); I think this fits the structured logging model more naturally but is also suited for logging to file/stdout if you add a fields marker to formatters (similar to the one in MDC). Any opinions on this? João Cabrita

1 0

[JIRA] (SLF4J-389) SimpleLogger caches System.err and System.out
by QOS.CH (JIRA) 16 Feb '17

16 Feb '17

[ https://jira.qos.ch/browse/SLF4J-389?page=com.atlassian.jira.plugin.system.… ] Michael Osipov commented on SLF4J-389: -------------------------------------- Thanks Ceki, I will let you know. > SimpleLogger caches System.err and System.out > --------------------------------------------- > > Key: SLF4J-389 > URL: https://jira.qos.ch/browse/SLF4J-389 > Project: SLF4J > Issue Type: Bug > Affects Versions: 1.7.x > Reporter: Igor Polevoy > Assignee: Ceki Gülcü > Fix For: 1.7.23 > > > We usually use SimpleLogger in tests, and some other binding when running in production. > In some cases, our tests depend on log values logged through the logger during a test. > Unfortunately between version 1.7.0 and 1.7.1 this ability has been removed, since the SimpleLogger now caches the system stream in a static initialiser. > Here is the code that broke this approach: > https://github.com/qos-ch/slf4j/commit/996ccc7ca507994465c069554954ecb01890… > Basically, we would write a test: > {quote}PrintStream err = System.err; > PrintStream temp = new PrintStream(some buffer here); > System.err = temp; > // run tests > System.err = err; > // here we assert that the temp stream contains values we expect{quote} > Unfortunately SimpleLogger now caches the system stream and never releases it, meaning swapping the streams to catch the output is not possible. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (SLF4J-389) SimpleLogger caches System.err and System.out
by QOS.CH (JIRA) 16 Feb '17

16 Feb '17

[ https://jira.qos.ch/browse/SLF4J-389?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-389: ---------------------------------- Thank you for looking into this. Please let me know if you determine that Maven is affected in which case the old behavior can be re-introduced as a configuration option. > SimpleLogger caches System.err and System.out > --------------------------------------------- > > Key: SLF4J-389 > URL: https://jira.qos.ch/browse/SLF4J-389 > Project: SLF4J > Issue Type: Bug > Affects Versions: 1.7.x > Reporter: Igor Polevoy > Assignee: Ceki Gülcü > Fix For: 1.7.23 > > > We usually use SimpleLogger in tests, and some other binding when running in production. > In some cases, our tests depend on log values logged through the logger during a test. > Unfortunately between version 1.7.0 and 1.7.1 this ability has been removed, since the SimpleLogger now caches the system stream in a static initialiser. > Here is the code that broke this approach: > https://github.com/qos-ch/slf4j/commit/996ccc7ca507994465c069554954ecb01890… > Basically, we would write a test: > {quote}PrintStream err = System.err; > PrintStream temp = new PrintStream(some buffer here); > System.err = temp; > // run tests > System.err = err; > // here we assert that the temp stream contains values we expect{quote} > Unfortunately SimpleLogger now caches the system stream and never releases it, meaning swapping the streams to catch the output is not possible. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0