July 2017 - logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1331) Programatically Control Logger Hierarchy
by QOS.CH (JIRA) 30 Jul '17

30 Jul '17

buko created LOGBACK-1331: ----------------------------- Summary: Programatically Control Logger Hierarchy Key: LOGBACK-1331 URL: https://jira.qos.ch/browse/LOGBACK-1331 Project: logback Issue Type: New Feature Components: logback-classic Affects Versions: 1.2.3 Reporter: buko Assignee: Logback dev list We would like to be able to programatically control the hierarchy of Loggers. Logback classic allows the ability to programatically configure Loggers but it does not allow the ability to programatically control the Logger hierarchy - that is, there's no way to force one Logger object to become the parent of another Logger object. Currently the hierarchy model is essentially hardcoded in the LoggerContext.getLogger(String) method. This method parses the string out based on '.' and '$' characters to create a hierarchy of Loggers. We would like to implement our own Logger hierarchy logic. We have two loggers, Logger('node://mesh.context/') and Logger('node://mesh.context/identity') and the first should be parent of the second. There are a couple of ways this could be done: 1) Make the Logger(String,Logger,LoggerContext) constructor public. This would allow people to create Loggers using any hierarchy they want. 2) Provide a new methods: LoggerContext.getLoggerOpaque(String name); LoggerContext.getLoggerOpaque(String name, Logger parent); These methods would allow clients to create Loggers with OPAQUE names. No attempt would be made to parse the logger's name and interpret it as an hierarchy. It would also allow the user to implement her own hierarchy model by explicitly passing a parent logger. 3) Provide a Logger.setParent(Logger) method. Our preference is on #2. Note that currently we can hack around this by reflectively invoking the package-private Logger ctor using the setAccessible method. This is not a stable workaround and will probably stop working with Java 9. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1330) LogBack - ThreadStuck : Application is stopped working
by QOS.CH (JIRA) 18 Jul '17

18 Jul '17

TULSIRAM created LOGBACK-1330: --------------------------------- Summary: LogBack - ThreadStuck : Application is stopped working Key: LOGBACK-1330 URL: https://jira.qos.ch/browse/LOGBACK-1330 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.0.3 Environment: Unix Weblogic server Reporter: TULSIRAM Assignee: Logback dev list Getting below exception from Threaddump. We are not sure what is causing this thread stuck in weblogic server. "[STANDBY] ExecuteThread: '29' for queue: 'weblogic.kernel.Default (self-tuning)'" waiting for lock weblogic.work.ExecuteThread@7af044ab WAITING java.lang.Object.wait(Native Method) java.lang.Object.wait(Object.java:503) weblogic.work.ExecuteThread.waitForRequest(ExecuteThread.java:238) weblogic.work.ExecuteThread.run(ExecuteThread.java:271) "[STUCK] ExecuteThread: '28' for queue: 'weblogic.kernel.Default (self-tuning)'" @342c759b BLOCKED ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:211)waiting for lock ch.qos.logback.core.spi.LogbackLock ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:103) ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:88) ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48) ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:272) ch.qos.logback.classic.Logger.callAppenders(Logger.java:259) ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:441) ch.qos.logback.classic.Logger.filterAndLog_1(Logger.java:413) ch.qos.logback.classic.Logger.info(Logger.java:603) -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-957) Add Groovy support for SiftingAppender
by QOS.CH (JIRA) 18 Jul '17

18 Jul '17

1 0

JDK 9 EA Build 178 & JDK 8u152 b05 are available on jdk.java.net
by Rory O'Donnell 17 Jul '17

17 Jul '17

Hi Ceki, *JDK 9 Early Access* build 178 is available at : - jdk.java.net/9/ A summary of all the changes in this build are listed here <http://download.java.net/java/jdk9/changes/jdk-9+178.html>. Changes which were introduced since the last availability email that may be of interest : * b175 - Module system implementation refresh**(6/2017 update) * b175 - no longer has "-ea" in the version string and the system property "java version" is now simply "9" o *java -version* >java version "9" >Java(TM) SE Runtime Environment (build 9+175) >Java HotSpot(TM) 64-Bit Server VM (build 9+175, mixed mode) o *Bundle name changes:* e.g. jdk-9+175_linux-x86_bin.tar.gz *JDK 8u152 Early Access* build 05 is available at : - jdk.java.net/8/ <http://jdk.java.net/8/> A summary of all the changes in this build are listed here <http://download.java.net/java/jdk8u152/changes/jdk8u152-b05.html>. Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

[JIRA] (LOGBACK-1157) Provide a BOM of all logback artifacts
by QOS.CH (JIRA) 14 Jul '17

14 Jul '17

1 0

[JIRA] (LOGBACK-1325) ERROR in ch.qos.logback.classic.pattern.SyslogStartConverter@2a314cb4 - Could not determine local host name java.net.UnknownHostException: usagem: usagem: Name or service not known at java.net.UnknownHostException:
by QOS.CH (JIRA) 14 Jul '17

14 Jul '17

1 0

[JIRA] (LOGBACK-1329) ShutdownHook code inconsist with documentation
by QOS.CH (JIRA) 14 Jul '17

14 Jul '17

Constantine created LOGBACK-1329: ------------------------------------ Summary: ShutdownHook code inconsist with documentation Key: LOGBACK-1329 URL: https://jira.qos.ch/browse/LOGBACK-1329 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.3 Environment: Not relevant Reporter: Constantine Assignee: Logback dev list Priority: Minor In ch.qos.logback.core.joran.action.ShutdownHookAction classname is mandatory {code:java} String className = attributes.getValue(CLASS_ATTRIBUTE); if (OptionHelper.isEmpty(className)) { addError("Missing class name for shutdown hook. Near [" + name + "] line " + getLineNumber(ic)); inError = true; return; } {code} But on page [https://logback.qos.ch/manual/configuration.html] {code:java} <configuration debug="true">  <shutdownHook/> .... </configuration> {code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-941) The MDC properties are not set to LoggingEvent when logging over the SocketAppender
by QOS.CH (JIRA) 13 Jul '17

13 Jul '17

1 0

[JIRA] (LOGBACK-1328) Customize kafka appender error since logbac1.1.6
by QOS.CH (JIRA) 13 Jul '17

13 Jul '17

leviqian created LOGBACK-1328: --------------------------------- Summary: Customize kafka appender error since logbac1.1.6 Key: LOGBACK-1328 URL: https://jira.qos.ch/browse/LOGBACK-1328 Project: logback Issue Type: Bug Components: logback-classic, logback-core Affects Versions: 1.1.8, 1.1.7, 1.1.6 Reporter: leviqian Assignee: Logback dev list In logback1.1.6, I have customized a kafka appender. When the root level is set to ERROR in logback.xml, it will throw an exception(such as org.apache.kafka.common.errors.TimeoutException: Failed to update metadata after 60000 ms). But when set the root level to INFO or lower, it will be ok. I think this is a bug in logback, and the affected version is from 1.1.6 to 1.2.3. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1327) Translator Link 503 Service Unavailable
by QOS.CH (JIRA) 11 Jul '17

11 Jul '17

1 0