- slf4j-dev - mailman3.qos.ch

[JIRA] (SLF4J-124) Add ability to log at a dynamic level
by QOS.CH (JIRA) 23 Jan '17

23 Jan '17

[ https://jira.qos.ch/browse/SLF4J-124?page=com.atlassian.jira.plugin.system.… ] Anders Kreinøe commented on SLF4J-124: -------------------------------------- Are there other places where java 8 would be helpfull? If this is the main reason for Java 8, then I still think is a bad idea, as there is a fine way to implement it, working from java 5 and up. Looking at the backends, newest version of log4j (2.7) requires only java 7, and not long ago (version 2.3) it only required java 6. Logback seems to still support java 6. I cannot say anything about how big a part of new project is based on older java versions, but I now they are not uncommon. It pretty typical for enterprise organazations (or at leas i know of some) to hang on to older versions of java, both by practical but also political reasons. So overall I would think its a bad idea to make slf4j require java 8 at this time. Also breaking the Logger interface would break end user code for some users, as there is end users that has implemented there own Logger classes for different reasons. > Add ability to log at a dynamic level > ------------------------------------- > > Key: SLF4J-124 > URL: https://jira.qos.ch/browse/SLF4J-124 > Project: SLF4J > Issue Type: Sub-task > Components: Core API > Affects Versions: 1.5.x > Environment: Operating System: All > Platform: All > URL: http://stackoverflow.com/questions/2621701/setting-log-level-of-message-at-… > Reporter: Robert Elliot > Assignee: SLF4J developers list > Attachments: Util.java.patch > > > It is occasionally useful to have a log method that takes a level as a parameter. The necessary methods can be added to the Util class without any compatibility issues as far as I can see - see attached patch. -- This message was sent by Atlassian JIRA (v6.4.12#64027)

1 0

[JIRA] (SLF4J-124) Add ability to log at a dynamic level
by QOS.CH (JIRA) 20 Jan '17

20 Jan '17

[ https://jira.qos.ch/browse/SLF4J-124?page=com.atlassian.jira.plugin.system.… ] Ceki Gulcu commented on SLF4J-124: ---------------------------------- I'd like to move to JDK 8 for SLF4J 2.0. However, AFAIK 50% of the Java users are still on JDK 7 or older. Default methods in interfaces are really awesome. My primary concern is to avoid breaking end-user code. Implementors of the Logger interface is less of a concern. The latter are just a handful whereas the former are in the millions. Having said this, I don't think adding methods to the Logger interface will break client code. Nevertheless, I agree that keeping backward compatibility for implementors is nice (but not crucial). You can have lamda support without requiring Java 8. See my email with the subject [Lambda support in SLF4J|http://mailman.qos.ch/pipermail/slf4j-dev/2016-December/004593.html]. As for end of public updates for JDK 7, as mentioned above, there are many projects still using JDK 7. I guess new projects are on JDK 8 though. > Add ability to log at a dynamic level > ------------------------------------- > > Key: SLF4J-124 > URL: https://jira.qos.ch/browse/SLF4J-124 > Project: SLF4J > Issue Type: Sub-task > Components: Core API > Affects Versions: 1.5.x > Environment: Operating System: All > Platform: All > URL: http://stackoverflow.com/questions/2621701/setting-log-level-of-message-at-… > Reporter: Robert Elliot > Assignee: SLF4J developers list > Attachments: Util.java.patch > > > It is occasionally useful to have a log method that takes a level as a parameter. The necessary methods can be added to the Util class without any compatibility issues as far as I can see - see attached patch. -- This message was sent by Atlassian JIRA (v6.4.12#64027)

1 0

[JIRA] (SLF4J-124) Add ability to log at a dynamic level
by QOS.CH (JIRA) 20 Jan '17

20 Jan '17

[ https://jira.qos.ch/browse/SLF4J-124?page=com.atlassian.jira.plugin.system.… ] Anders Kreinøe commented on SLF4J-124: -------------------------------------- Agreed. If its acceptable to require at least java 8, then default methods on the logger interface is the best solution. But java 8 is for me a pretty high requirement, for a library that try to be so widely usable as slf4j. The current version seems to require only JDK 1.5, so bumping it to require java 8 is a big change. > Add ability to log at a dynamic level > ------------------------------------- > > Key: SLF4J-124 > URL: https://jira.qos.ch/browse/SLF4J-124 > Project: SLF4J > Issue Type: Sub-task > Components: Core API > Affects Versions: 1.5.x > Environment: Operating System: All > Platform: All > URL: http://stackoverflow.com/questions/2621701/setting-log-level-of-message-at-… > Reporter: Robert Elliot > Assignee: SLF4J developers list > Attachments: Util.java.patch > > > It is occasionally useful to have a log method that takes a level as a parameter. The necessary methods can be added to the Util class without any compatibility issues as far as I can see - see attached patch. -- This message was sent by Atlassian JIRA (v6.4.12#64027)

1 0

[JIRA] (SLF4J-124) Add ability to log at a dynamic level
by QOS.CH (JIRA) 20 Jan '17

20 Jan '17

[ https://jira.qos.ch/browse/SLF4J-124?page=com.atlassian.jira.plugin.system.… ] Joern Huxhorn commented on SLF4J-124: ------------------------------------- This issue is now nearly 8 years old. If we wait just a little longer, we could use Java 8 default methods implemented on the {{Logger}} interface itself to fix it. That way it would "just work" for existing {{Logger}} implementations but they could still opt-in to override with different functionality. I don't know the scope of slf4j 2.0 but if it would include lazy message generation using lambdas then that would require Java 8 anyway. [End of Public Updates for Oracle JDK 7|http://www.oracle.com/technetwork/java/eol-135779.html] was reached 2015-04. Updates via paid Oracle Premier Support are still available, though. > Add ability to log at a dynamic level > ------------------------------------- > > Key: SLF4J-124 > URL: https://jira.qos.ch/browse/SLF4J-124 > Project: SLF4J > Issue Type: Sub-task > Components: Core API > Affects Versions: 1.5.x > Environment: Operating System: All > Platform: All > URL: http://stackoverflow.com/questions/2621701/setting-log-level-of-message-at-… > Reporter: Robert Elliot > Assignee: SLF4J developers list > Attachments: Util.java.patch > > > It is occasionally useful to have a log method that takes a level as a parameter. The necessary methods can be added to the Util class without any compatibility issues as far as I can see - see attached patch. -- This message was sent by Atlassian JIRA (v6.4.12#64027)

1 0

[JIRA] (SLF4J-124) Add ability to log at a dynamic level
by QOS.CH (JIRA) 20 Jan '17

20 Jan '17

[ https://jira.qos.ch/browse/SLF4J-124?page=com.atlassian.jira.plugin.system.… ] Ceki Gulcu commented on SLF4J-124: ---------------------------------- [~anderskreinoee] [~jhuxhorn] I am attaching the present to SLF4J-391 as a sub-task. > Add ability to log at a dynamic level > ------------------------------------- > > Key: SLF4J-124 > URL: https://jira.qos.ch/browse/SLF4J-124 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.5.x > Environment: Operating System: All > Platform: All > URL: http://stackoverflow.com/questions/2621701/setting-log-level-of-message-at-… > Reporter: Robert Elliot > Assignee: SLF4J developers list > Attachments: Util.java.patch > > > It is occasionally useful to have a log method that takes a level as a parameter. The necessary methods can be added to the Util class without any compatibility issues as far as I can see - see attached patch. -- This message was sent by Atlassian JIRA (v6.4.12#64027)

1 0

[JIRA] (SLF4J-391) Overhaul of SLF4J core API
by QOS.CH (JIRA) 20 Jan '17

20 Jan '17

Ceki Gulcu created SLF4J-391: -------------------------------- Summary: Overhaul of SLF4J core API Key: SLF4J-391 URL: https://jira.qos.ch/browse/SLF4J-391 Project: SLF4J Issue Type: Task Components: Core API Reporter: Ceki Gulcu Assignee: SLF4J developers list This issue serves as an umbrella for the overhaul and modernization SLF4J core API. -- This message was sent by Atlassian JIRA (v6.4.12#64027)

1 0

[JIRA] (SLF4J-124) Add ability to log at a dynamic level
by QOS.CH (JIRA) 20 Jan '17

20 Jan '17

[ https://jira.qos.ch/browse/SLF4J-124?page=com.atlassian.jira.plugin.system.… ] Anders Kreinøe commented on SLF4J-124: -------------------------------------- Correct each of these method would have to be implemented on each instance of the Level enum. But as I see it the alternative (adding the methods to the logger interface), will push the trouble down at the Logger implementations. This includes severel classes from slf4j, but also other backends like Log4j and Logback. Some of them may be able to handle it in a pretty way, but properly at least one of them will need to implement each of the methods with a switch case, doing something different for each level. In total this would properly give more code, and involve more people (all external backends would have to implement it). Even though the Level enum will grow big, I still think its a better alternative doing it in a way that only requires changes in one place. Doing it in the enum would make it work on all backends, no matter if that backends supports it natively or not. > Add ability to log at a dynamic level > ------------------------------------- > > Key: SLF4J-124 > URL: https://jira.qos.ch/browse/SLF4J-124 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.5.x > Environment: Operating System: All > Platform: All > URL: http://stackoverflow.com/questions/2621701/setting-log-level-of-message-at-… > Reporter: Robert Elliot > Assignee: SLF4J developers list > Attachments: Util.java.patch > > > It is occasionally useful to have a log method that takes a level as a parameter. The necessary methods can be added to the Util class without any compatibility issues as far as I can see - see attached patch. -- This message was sent by Atlassian JIRA (v6.4.12#64027)

1 0

[JIRA] (SLF4J-124) Add ability to log at a dynamic level
by QOS.CH (JIRA) 19 Jan '17

19 Jan '17

[ https://jira.qos.ch/browse/SLF4J-124?page=com.atlassian.jira.plugin.system.… ] Joern Huxhorn commented on SLF4J-124: ------------------------------------- The problem is that you would still need to implement all of these methods for each and every enum value: {code} boolean isEnabled(Logger logger); void log(Logger logger, String msg); void log(Logger logger, String format, Object arg); void log(Logger logger, String format, Object arg1, Object arg2); void log(Logger logger, String format, Object... arguments); void log(Logger logger, String msg, Throwable t); boolean isEnabled(Logger logger, Marker marker); void log(Logger logger, Marker marker, String msg); void log(Logger logger, Marker marker, String format, Object arg); void log(Logger logger, Marker marker, String format, Object arg1, Object arg2); void log(Logger logger, Marker marker, String format, Object... argArray); void log(Logger logger, Marker marker, String msg, Throwable t); {code} I don't think that this would be a good idea. But that's just me. I'm not the owner of the project. > Add ability to log at a dynamic level > ------------------------------------- > > Key: SLF4J-124 > URL: https://jira.qos.ch/browse/SLF4J-124 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.5.x > Environment: Operating System: All > Platform: All > URL: http://stackoverflow.com/questions/2621701/setting-log-level-of-message-at-… > Reporter: Robert Elliot > Assignee: SLF4J developers list > Attachments: Util.java.patch > > > It is occasionally useful to have a log method that takes a level as a parameter. The necessary methods can be added to the Util class without any compatibility issues as far as I can see - see attached patch. -- This message was sent by Atlassian JIRA (v6.4.12#64027)

1 0

[JIRA] (SLF4J-124) Add ability to log at a dynamic level
by QOS.CH (JIRA) 19 Jan '17

19 Jan '17

[ https://jira.qos.ch/browse/SLF4J-124?page=com.atlassian.jira.plugin.system.… ] Anders Kreinøe commented on SLF4J-124: -------------------------------------- Now where slf4j actually has an Level enum, what about adding a log(Logger logger, String msg) method to the enum, instead of a generic log(Level level, String msg) method to Logger. It could look something like this: {code:java} public enum Level { ERROR(ERROR_INT, "ERROR") { @Override public void log(Logger logger, String msg) { logger.error(msg); } }, WARN(WARN_INT, "WARN") { @Override public void log(Logger logger, String msg) { logger.warn(msg); } }, INFO(INFO_INT, "INFO") { @Override public void log(Logger logger, String msg) { logger.info(msg); } }, DEBUG(DEBUG_INT, "DEBUG") { @Override public void log(Logger logger, String msg) { logger.debug(msg); } }, TRACE(TRACE_INT, "TRACE") { @Override public void log(Logger logger, String msg) { logger.trace(msg); } }; private int levelInt; private String levelStr; Level(int i, String s) { levelInt = i; levelStr = s; } public int toInt() { return levelInt; } /** * Returns the string representation of this Level. */ public String toString() { return levelStr; } public abstract void log(Logger logger, String msg); } {code} Then you can define a method taking a Level instance, and just call log on that. No need to know what level it actually is: {code:java} public static void doSomethind(Level logAtLevel) { // perform some logic logAtLevel.log(loggerToLogTo, "The caller of this method has decided " + "what level this is logged at."); } {code} This is only an example, a lot more methods would have to be difined on the level class, to support markers, and arguments for {} replacements. I see the following advantages when doing it this way: # Adding a new method to Logger interface would breack the backward compability, as it would force all implementations to implement these methods. However adding a log method to level, is fully backward compatibly. # I think this would give a cleaner implementation, without the need for matching (either in a switch or with if/else statements) on the level in the log methods. # More typesafe. There will be no switch or if statements matching on the level, to decide what method to call on the Logger instance. Thus adding an new Level, will result in a compile error, until the needed log methods has been implemented in that Level instance. # It still possibly to add generic log.(Level level ...) methods in the Logger interface if wanted (would still break backward compatibility), and the implementation for these would be pretty easy, just call the corresponding method on the supplied Level instance. It would be possibly to create an abstract class implementing Logger, that provide the implementation for these, that could be used by Logger implementations that do not need to extend an other class. I would be willing to work on this, and provide patches, but I will like to know if its something that would surely be rejected, before doing any work. > Add ability to log at a dynamic level > ------------------------------------- > > Key: SLF4J-124 > URL: https://jira.qos.ch/browse/SLF4J-124 > Project: SLF4J > Issue Type: Improvement > Components: Core API > Affects Versions: 1.5.x > Environment: Operating System: All > Platform: All > URL: http://stackoverflow.com/questions/2621701/setting-log-level-of-message-at-… > Reporter: Robert Elliot > Assignee: SLF4J developers list > Attachments: Util.java.patch > > > It is occasionally useful to have a log method that takes a level as a parameter. The necessary methods can be added to the Util class without any compatibility issues as far as I can see - see attached patch. -- This message was sent by Atlassian JIRA (v6.4.12#64027)

1 0

[JIRA] (SLF4J-390) FAILED_INITIALIZATION case in LoggerFactory.getILoggerFactory swallows root exception
by QOS.CH (JIRA) 16 Jan '17

16 Jan '17

Andreas Sewe created SLF4J-390: ---------------------------------- Summary: FAILED_INITIALIZATION case in LoggerFactory.getILoggerFactory swallows root exception Key: SLF4J-390 URL: http://jira.qos.ch/browse/SLF4J-390 Project: SLF4J Issue Type: Bug Affects Versions: 1.7.22 Reporter: Andreas Sewe Assignee: SLF4J developers list Priority: Minor I have a hard time triaging an {{IllegalStateException}} thrown by {{LoggerFactory.getILoggerFactory}} that has been reported by a user ([Eclipse Bug 510487|https://bugs.eclipse.org/bugs/show_bug.cgi?id=510487] as the root exception is not wrapped by the {{IllegalStateException}}: [https://github.com/qos-ch/slf4j/blob/v_1.7.22/slf4j-api/src/main/java/org/s…] AFAICT, that exception is only logged to the console ([https://github.com/qos-ch/slf4j/blob/v_1.7.22/slf4j-api/src/main/java/org/s…] This makes error reports sent by an automatic error reporting system (like the one employed for the Eclipse IDE) less useful, as the crucial information won't be included automatically. Hence, it would be great if SLF4J could hold onto the {{Throwable}} for a bit and than wrap it in the final {{IllegalStateException}}. -- This message was sent by Atlassian JIRA (v6.4.12#64027)

1 0