February 2017 - slf4j-dev - mailman3.qos.ch

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

23 Feb '17

[ https://jira.qos.ch/browse/SLF4J-389?page=com.atlassian.jira.plugin.system.… ] Michael Osipov commented on SLF4J-389: -------------------------------------- Hi Ceki, thanks for the information. I have forwarded this to Hervé Boutemy who wrote the patched provider. He will join the conversation shortly and share his opinion. > 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) 23 Feb '17

23 Feb '17

[ https://jira.qos.ch/browse/SLF4J-389?page=com.atlassian.jira.plugin.system.… ] Ceki Gülcü commented on SLF4J-389: ---------------------------------- Hi [~michael-o] Just had a look at [monkey patched slf4j-simple provider|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=94b…] Wouldn't be easier of the renderThrowable and renderLevel method were already available in SimpleLogger? It's seems like a trivial change on this end. > 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-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.… ] Ceki Gülcü commented on SLF4J-383: ---------------------------------- [~hazendaz] Only a SNAPSHOT version of SLF4J was JDK 1.6 for a couple of days. > 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: Ceki Gülcü > Fix For: 1.7.24 > > > 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-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.… ] Matej Spiller-Muys commented on SLF4J-369: ------------------------------------------ Separate issue was reported inside cal10n: CAL-48. Problem is because cal10n (and slf4j-ext) is doing something in addition during compile process on EVERY project that has dependency on it. If everything goes well, you don't see any issue. And you don't get any error. Well perhaps just a bit longer compilation phases. But due to CAL-48 bug you got busted jar and successful build!!! If you want cal10n compiler phase in you project, well then you should include it in your application yourself (like documentation states). I want to have build process under full control and don't want logger library to be more that it is supposed to (like checking translation in MY project). > 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.… ] Ceki Gülcü resolved SLF4J-373. ------------------------------ Resolution: Not a bug Please read https://www.slf4j.org/codes.html#multiple_bindings > 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-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