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

[Bug 295] New: Persistent error while integrating Spring project with many JAR dependencies
by bugzilla-daemon＠qos.ch 20 Feb '13

20 Feb '13

http://bugzilla.slf4j.org/show_bug.cgi?id=295 Summary: Persistent error while integrating Spring project with many JAR dependencies Product: SLF4J Version: unspecified Platform: PC OS/Version: Windows NT Status: NEW Severity: blocker Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: colbert.philippe(a)ROGERS.com I wrote an application using Spring Framework and several other JAR dependencies using slf4j. However, I get this error from your library: SEVERE: Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V at org.apache.commons.logging.impl.SLF4JLocationAwareLog.info(SLF4JLocationAwareLog.java:159) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:272) This error is difficult to resolve. I haven't found a solution yet. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1

[Bug 294] New: slf4j-api-1.7.2-tests.jar and slf4j-api-1.7.2.jar use same Bundle-SymbolicName in MANIFEST.MF
by bugzilla-daemon＠qos.ch 20 Feb '13

20 Feb '13

http://bugzilla.slf4j.org/show_bug.cgi?id=294 Summary: slf4j-api-1.7.2-tests.jar and slf4j-api-1.7.2.jar use same Bundle-SymbolicName in MANIFEST.MF Product: SLF4J Version: 1.7.x Platform: PC OS/Version: All Status: NEW Severity: major Priority: P1 Component: Core API AssignedTo: slf4j-dev(a)qos.ch ReportedBy: peter.hermsdorf(a)godyo.com since both jars use the same bundle Id it can come to clashes when both are used in osgi environments. We are using sonar nexus repository server with p2 plugin which generates p2 metadata from all jar files that contain a valid osgi'fied MANIFEST.MF file. So we can import thirdparty libraries to an eclipse target platform with a .target file like that: <location includeAllPlatforms="false" includeConfigurePhase="false" includeMode="slicer" includeSource="true" type="InstallableUnit"> <unit id="slf4j.api" version="1.7.2"/> <repository location="http://build.godyo.int:8081/nexus/content/repositories/central/.meta/p2/"/> </location> The odd thing was that we got MD5 errors when setting the target platform, but only on some machines. In the end it showed that the nexus server hat the slf4j.api and it corresponding test jar. Both with the same Bundle Id and so something got mixed up. the test jar should have a Bundle Id like slf4g.api.test -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 292] New: Custom JUL-LogManager to support multiple configurations (Logback).
by bugzilla-daemon＠qos.ch 19 Feb '13

19 Feb '13

http://bugzilla.slf4j.org/show_bug.cgi?id=292 Summary: Custom JUL-LogManager to support multiple configurations (Logback). Product: SLF4J Version: 1.7.x Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P1 Component: jul-to-slf4j AssignedTo: slf4j-dev(a)qos.ch ReportedBy: thomas.moeller(a)continentale.de I suppose to implement a custom JUL-LogManager that switches off the JUL configuration completely: public class Slf4jLogManager extends LogManager { public Slf4jLogManager() { } @Override public void readConfiguration() throws IOException, SecurityException { } @Override public void readConfiguration(InputStream ins) throws IOException, SecurityException { } @Override public synchronized boolean addLogger(Logger logger) { return super.addLogger(new Slf4jLogger(logger.getName(), logger .getResourceBundleName())); } } public class Slf4jLoggerAdapter { private final String name; private volatile Logger logger; public Slf4jLoggerAdapter(String name) { this.name = name; } private Logger resolve() { Logger logger = this.logger; if (logger == null) { logger = demandLogger(); this.logger = logger; } return logger; } private Logger demandLogger() { return LoggerFactory.getLogger(name); } public Level getLevel() { org.slf4j.Logger logger = resolve(); Level level; if (logger.isTraceEnabled()) { level = Level.FINEST; } else if (logger.isDebugEnabled()) { level = Level.FINER; } else if (logger.isInfoEnabled()) { level = Level.INFO; } else if (logger.isWarnEnabled()) { level = Level.WARNING; } else if (logger.isErrorEnabled()) { level = Level.SEVERE; } else { level = Level.OFF; } return level; } public boolean isLoggable(Level level) { return getLevel().intValue() <= level.intValue(); } public boolean isSevereEnabled() { return resolve().isErrorEnabled(); } // ... } public class Slf4jLogger extends Logger { private static final Handler BRIDGE_HANDLER = new SLF4JBridgeHandler(); private final Slf4jLoggerAdapter adapter; public Slf4jLogger(String name, String resourceBundleName) { super(name, resourceBundleName); adapter = new Slf4jLoggerAdapter(name); super.setLevel(Level.ALL); super.addHandler(BRIDGE_HANDLER); super.setUseParentHandlers(false); } @Override public Level getLevel() { return adapter.getLevel(); } @Override public boolean isLoggable(Level level) { return adapter.isLoggable(level); } @Override public void severe(String msg) { if (adapter.isSevereEnabled()) { super.severe(msg); } } // ... } -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

[Bug 133] Add ability to log at a dynamic level
by bugzilla-daemon＠qos.ch 08 Feb '13

08 Feb '13

http://bugzilla.slf4j.org/show_bug.cgi?id=133 --- Comment #8 from Matthew Hall <mhall(a)mhcomputing.net> 2013-02-08 04:01:55 CET --- Yes, that's what I'm praying for, an enum! :) -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 133] Add ability to log at a dynamic level
by bugzilla-daemon＠qos.ch 07 Feb '13

07 Feb '13

http://bugzilla.slf4j.org/show_bug.cgi?id=133 Joern Huxhorn <joern(a)huxhorn.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joern(a)huxhorn.de --- Comment #7 from Joern Huxhorn <joern(a)huxhorn.de> 2013-02-07 20:19:25 CET --- Just wanted to add that we have similar points in our application where subsystems are logging in their own way (e.g. an XSLT processor) and need to be mapped into SLF4J. That feature would come in quite handy. Given that SLF4J is now requiring Java 5 we could/should even use an Enum as LogLevel. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 133] Add ability to log at a dynamic level
by bugzilla-daemon＠qos.ch 06 Feb '13

06 Feb '13

http://bugzilla.slf4j.org/show_bug.cgi?id=133 Matthew Hall <mhall(a)mhcomputing.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mhall(a)mhcomputing.net --- Comment #6 from Matthew Hall <mhall(a)mhcomputing.net> 2013-02-06 04:46:53 CET --- Hello gentlemen, I have a MUCH simpler use case for this feature that is important in an application and not just in libraries. I have many cases where I am writing code which performs security validation of input data. 99% of the time the messages coming in will be valid, thus boring, and should be logged at a very low level such as TRACE so you can enable viewing them in the production code to see what's being validated in case there is a problem somewhere. But 1% of the time you find something bad in the input, because some hacker or user has tried entering something crazy to find an exploit. It would be very nice if the exact same message can be logged as before, but at a lot higher severity so you know that something bad happened, without having duplicated calls for everything which could be good or could be bad at runtime, which is silly. Example of how I've done this before in many lines of code I've written using JDK and Log4J instead of SLF4J. boolean isOk = isXFieldValid && isYFieldValid && isZFieldValid; log.dynamic(isOk? TRACE : WARN, "isXFieldValid {} isYFieldValid {} isZFieldValid", isXFieldValid, isYFieldValid, isZFieldValid); Could we please reconsider this and think of a good solution? Thanks, Matthew. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0