- logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1474) GEventEvaluator not working in logback 1.3.0-alpha4 (due to groovy issue)
by QOS.CH (JIRA) 01 Jul '19

01 Jul '19

1 0

[JIRA] (LOGBACK-1474) GEventEvaluator not working in logback 1.3.0-alpha4 (due to groovy issue)
by QOS.CH (JIRA) 01 Jul '19

01 Jul '19

Dean Hiller created LOGBACK-1474: ------------------------------------ Summary: GEventEvaluator not working in logback 1.3.0-alpha4 (due to groovy issue) Key: LOGBACK-1474 URL: https://jira.qos.ch/browse/LOGBACK-1474 Project: logback Issue Type: Bug Components: logback-classic Affects Versions: 1.3.0-alpha4, 1.3.0-alpha3, 1.3.0-alpha1 Environment: any Reporter: Dean Hiller Assignee: Logback dev list Due to a groovy issue(I need to create or find one and link here), GEventEvaluator is not supported. To reproduce, you can follow these steps * git clone [https://github.com/deanhiller/webpieces.git] * cd webpieces * git checkout logbackBugs * import into Intellij OR Eclipse via gradle (both are tested often and work) * Open DevelopmentServer.java and run it You will see this exception 09:21:00,636 |-ERROR in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Could not create component [evaluator] of type [ch.qos.logback.classic.boolex.GEventEvaluator] java.lang.ClassNotFoundException: ch.qos.logback.classic.boolex.GEventEvaluator at java.lang.ClassNotFoundException: ch.qos.logback.classic.boolex.GEventEvaluator at at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) at at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) at at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) at at ch.qos.logback.core.util.Loader.loadClass(Loader.java:120) at at ch.qos.logback.core.joran.action.NestedComplexPropertyIA.begin(NestedComplexPropertyIA.java:102) at at ch.qos.logback.core.joran.spi.Interpreter.callBeginAction(Interpreter.java:269) at at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:145) at at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:128) at at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:50) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:165) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:152) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:110) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:53) at at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:82) at at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:157) at at ch.qos.logback.classic.spi.LogbackServiceProvider.initializeLoggerContext(LogbackServiceProvider.java:49) at at ch.qos.logback.classic.spi.LogbackServiceProvider.initialize(LogbackServiceProvider.java:40) at at org.slf4j.LoggerFactory.bind(LoggerFactory.java:151) at at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:139) at at org.slf4j.LoggerFactory.getProvider(LoggerFactory.java:417) at at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:403) at at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:352) at at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:378) at at WEBPIECESxPACKAGE.DevelopmentServer.<clinit>(DevelopmentServer.java:8) -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1473) %caller broken for lambdas in latest alpha release
by QOS.CH (JIRA) 01 Jul '19

01 Jul '19

Dean Hiller created LOGBACK-1473: ------------------------------------ Summary: %caller broken for lambdas in latest alpha release Key: LOGBACK-1473 URL: https://jira.qos.ch/browse/LOGBACK-1473 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.3.0-alpha4, 1.3.0-alpha3, 1.3.0-alpha1, 1.3.0-alpha0 Environment: Any, easy to reproduce Reporter: Dean Hiller Assignee: Logback dev list %caller is an amazing feature!!! We install logback/slf4j as the defacto standard in [https://github.com/deanhiller/webpieces] AND more importantly, on the DevelopmentServer (recompiles code live as the server is running), we use the pattern %caller such that Developers can 'click' on any log statement and it takes them in their IDE right to that class file and log line. This works in intellij and in Eclipse wonderfully. So, off the branch logbackBugs, we have this class with line numbers [https://github.com/deanhiller/webpieces/blob/logbackBugs/webserver/webpiece…] We have the following pattern [https://github.com/deanhiller/webpieces/blob/logbackBugs/webserver/webpiece…] which is %date\{ISO8601} [%thread][%X\{socket}] [%X\{txId}-%X\{user}] *%caller\{1}* %-4level: %message%n The output of running that program is 2019-07-01 09:21:00,716 [main][] [-] Caller+0 at WEBPIECESxPACKAGE.DevelopmentServer.main(DevelopmentServer.java:17) INFO: Starting Development Server under java version=11.0.3 2019-07-01 09:21:00,720 [main][] [-] Caller+0 at org.slf4j.spi.DefaultLoggingEventBuilder.logViaPublicLoggerAPI(DefaultLoggingEventBuilder.java:120) INFO: testing out %caller\{1} 2019-07-01 09:21:00,721 [main][] [-] Caller+0 at org.slf4j.spi.DefaultLoggingEventBuilder.logViaPublicLoggerAPI(DefaultLoggingEventBuilder.java:120) NOTICE that the first log line is correct. Our log is from line 17 in DevelopmentServer.java. The second line is logging incorrectly(ie. I personally think logback should adjust for this as it can tell if the lambda method was called or not as it already is looking at the stack trace). We would love to upgrade to slf4j2 but this was a huge feature in using our DevelopmentServer. It works like ruby where you just keep coding and never restart the server and COMBINED with this amazing caller feature, you can click any logs to go right to the log statement which has been amazing. NOTES: If you like, it is very easy to run the above program yourself like so * git clone [https://github.com/deanhiller/webpieces.git] * cd webpieces * git checkout logbackBugs * import into Intellij OR Eclipse via gradle (both are tested often and work) * Open DevelopmentServer.java and run it -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1472) RollingFileAppender unable to keep appending to current file when rollover failed
by QOS.CH (JIRA) 29 Jun '19

29 Jun '19

Bertrand Renuart created LOGBACK-1472: ----------------------------------------- Summary: RollingFileAppender unable to keep appending to current file when rollover failed Key: LOGBACK-1472 URL: https://jira.qos.ch/browse/LOGBACK-1472 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.3 Reporter: Bertrand Renuart Assignee: Logback dev list It may happen the {{RollingFileAppender}} becomes unable to keep appending events into the current file when {{rollover()}} failed. The {{RollingFileAppender#rollover()}} method looks as follows: {code:java} public void rollover() { lock.lock(); try { this.closeOutputStream(); attemptRollover(); attemptOpenFile(); } finally { lock.unlock(); } }{code} The method starts by closing the current output stream which sets the {{outputStream}} protected field to {{null}} until the file is reopened again. It then tries to rotate and reopen the file before exiting. However, if one of these two methods throw an unexpected exception, the {{outputStream}} field is left to {{null}}. This field is also left to {{null}} if the {{attemptOpenFile()}} method fails to reopen the new current file as returned by the rolling policy. This can happen if, for instance, the file system is not available (remote fs?), or if the policy returns a file located somewhere we don't have enough permissions, etc... The next time an event is received, the {{writeBytes}} method will throw a {{NullPointerException}}. *Unfortunately, this case is not expected and there is nothing to attempt to recover from it. The appender now starts dropping all events until the triggeringPolicy asks for a new rollover.* Comments in the {{attemptRollover}} method say that in case of exception, it should keep the same file but in append mode since it is safer to keep appending in an _outdated_ file instead of dropping events. Unfortunately, as mentioned above, the file output stream as been closed already, and an attempt is made to reopen it under the _new_ filename instead. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1471) ResilientFileOutputStream looses buffer size setting when reopened
by QOS.CH (JIRA) 28 Jun '19

28 Jun '19

Bertrand Renuart created LOGBACK-1471: ----------------------------------------- Summary: ResilientFileOutputStream looses buffer size setting when reopened Key: LOGBACK-1471 URL: https://jira.qos.ch/browse/LOGBACK-1471 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.3 Reporter: Bertrand Renuart Assignee: Logback dev list Method {{ResilientFileOutputStream#openNewOutputStream()}} does not take {{bufferSize}} into account when creating a new buffered output stream. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1470) Logback scan not work when springProperty changes
by QOS.CH (JIRA) 27 Jun '19

27 Jun '19

elliot created LOGBACK-1470: ------------------------------- Summary: Logback scan not work when springProperty changes Key: LOGBACK-1470 URL: https://jira.qos.ch/browse/LOGBACK-1470 Project: logback Issue Type: Bug Components: logback-classic Affects Versions: 1.1.11 Environment: <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-logging</artifactId> <version>1.5.9.RELEASE</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> <version>1.2.3</version> </dependency> Reporter: elliot Assignee: Logback dev list Priority: Minor Scan not working and did not reload logback-spring.xml when the value of springProperty in cofig files changes in runtime. It seems like the scan function only compare the last modified timestamp. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1279) Async appenders do not scale well across multiple threads
by QOS.CH (JIRA) 21 Jun '19

21 Jun '19

1 0

JDK 13 enters Rampdown Phase One
by Rory O'Donnell 16 Jun '19

16 Jun '19

Hi Ceki, *JDK 13 Early Access build **25 is now available **at : - jdk.java.net/13/* * Per the JDK 13 schedule [1], we are now in Rampdown Phase One. o For more details , see Mark Reinhold's email to jdk-dev mailing list [2] o The overall feature set is frozen, no further JEPs will be targeted to this release. * Changes in this build 25 [4] *Request for feedback on JEP 353 integrated in b24 * JEP 353: Reimplement the Legacy Socket API" has been integrated into jdk-13+24. It would be very useful if applications or libraries using java.net.Socket or java.net.ServerSocket APIs could test with this build and report any issues found. The JEP provides information on the system property that can be used to switch back to the old implementation and that may be useful to check for behavior differences between the old and new implementation. It would be very useful to get feedback via the OpenJDK net-dev mailing list, bugs via the usual channel. *Updates to Release Notes since last email* * b25 - Support Kerberos cross-realm referrals (RFC 6806)(JDK-8215032 <https://bugs.openjdk.java.net/browse/JDK-8215032>) * b25 - Add -XX:SoftMaxHeapSize flag(JDK-8222145 <https://bugs.openjdk.java.net/browse/JDK-8222145>) * b24 - Reimplement the Legacy Socket API(JDK-8221481 <https://bugs.openjdk.java.net/browse/JDK-8221481>) o see above request for feedback * b24 - Deprecated rmic tool For Removal(JDK-8217412 <https://bugs.openjdk.java.net/browse/JDK-8217412>) * b24 - New String constants for Canonical XML 1.1 URIs(JDK-8224767 <https://bugs.openjdk.java.net/browse/JDK-8224767>) * b23 - Support for Unicode 12.1 (JDK-8221431 <https://bugs.openjdk.java.net/browse/JDK-8221431>) * b21 - Upgrade CLDR to Version 35.1 (JDK-8221432 <https://bugs.openjdk.java.net/browse/JDK-8221432>) *OpenJDK 14 **Early Access build 1 **is now available **at : - jdk.java.net/14/* * These early-access, open-source builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Changes in this build [5] ** Rgds, Rory [1] http://openjdk.java.net/projects/jdk/13/#Schedule <http://openjdk.java.net/projects/jdk/12/#Schedule> [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-June/003060.html [3] http://jdk.java.net/13/release-notes [4] JDK 13 - Changes in b25 here <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B24%22%3A%3…> [5] JDK 14 - Changes in b1 here <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B0%22%3A%3A…> -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland

1 0

[JIRA] (LOGBACK-1424) high contention at ch.qos.logback.core.AsyncAppenderBase.putUninterruptibly
by QOS.CH (JIRA) 14 Jun '19

14 Jun '19

1 0

[JIRA] (LOGBACK-1469) AsycAppender defined in configuration but not used in any logger is not stopping by shutdown hook
by QOS.CH (JIRA) 14 Jun '19

14 Jun '19

Alexandr Bolbat created LOGBACK-1469: ---------------------------------------- Summary: AsycAppender defined in configuration but not used in any logger is not stopping by shutdown hook Key: LOGBACK-1469 URL: https://jira.qos.ch/browse/LOGBACK-1469 Project: logback Issue Type: Improvement Components: logback-classic, logback-core Affects Versions: 1.2.3 Environment: Any environment Reporter: Alexandr Bolbat Assignee: Logback dev list Priority: Critical If we define 3 async appenders: {code:java} <appender name="ConsoleInfoAppenderAsync" class="ch.qos.logback.classic.AsyncAppender"> <queueSize>5000</queueSize> <discardingThreshold>0</discardingThreshold> <appender-ref ref="ConsoleInfoAppender" /> <includeCallerData>true</includeCallerData> </appender> <appender name="ConsoleDebugAppenderAsync" class="ch.qos.logback.classic.AsyncAppender"> <queueSize>5000</queueSize> <discardingThreshold>0</discardingThreshold> <appender-ref ref="ConsoleDebugAppender" /> <includeCallerData>true</includeCallerData> </appender> <appender name="ConsoleTraceAppenderAsync" class="ch.qos.logback.classic.AsyncAppender"> <queueSize>5000</queueSize> <discardingThreshold>0</discardingThreshold> <appender-ref ref="ConsoleTraceAppender" /> <includeCallerData>true</includeCallerData> </appender> ...{code} Then define loggers: {code:java} <logger name="some.package" level="DEBUG" additivity="true"> <appender-ref ref="ConsoleDebugAppenderAsync" /> <appender-ref ref="ConsoleInfoAppenderAsync" /> </logger> <root level="INFO"> <appender-ref ref="ConsoleInfoAppenderAsync" /> </root> {code} And shutdown hook: {code:java} <shutdownHook class="ch.qos.logback.core.hook.DelayingShutdownHook" /> {code} On application shutdown we will have executed stop for 2 appenders: {code:java} ConsoleDebugAppenderAsync ConsoleInfoAppenderAsync {code} And related threads would be stopped. But shutdown for third appender will be ignored (or just not executed): {code:java} ConsoleTraceAppenderAsync {code} In result their thread will exist and still working: {code:java} AsyncAppender-Worker-ConsoleTraceAppenderAsync {code} In case of web application deployed to tomcat we will see warning about this: {code:java} 14-Jun-2019 18:03:43.568 WARNING [Thread-19] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [ROOT] appears to have started a thread named [AsyncAppender-Worker-ConsoleTraceAppenderAsync] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base(a)11/jdk.internal.misc.Unsafe.park(Native Method) java.base@11/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) java.base@11/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) java.base@11/java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:417) ch.qos.logback.core.AsyncAppenderBase$Worker.run(AsyncAppenderBase.java:289) {code} Would be nice to improve graceful shutdown process for this case. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0