From logback-dev at qos.ch Tue May 2 09:41:00 2023 From: logback-dev at qos.ch (logback developers list) Date: Tue, 2 May 2023 09:41:00 +0200 (CEST) Subject: [logback-dev] [JIRA] Updates for LOGBACK-1737: NoSuchMethod error on Java 8 in ConsoleAppender, Jansi2-code In-Reply-To: References: Message-ID: logback / LOGBACK-1737 [Open] NoSuchMethod error on Java 8 in ConsoleAppender, Jansi2-code ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1737 ============================== Issue created ------------------------------ WFR created this issue on 02/May/23 9:29 Summary: NoSuchMethod error on Java 8 in ConsoleAppender, Jansi2-code Issue Type: Bug Affects Versions: 1.3.7 Assignee: Logback dev list Components: logback-core Created: 02/May/23 9:29 Environment: Java 8 Priority: Critical Reporter: WFR Description: Changes in https://jira.qos.ch/browse/LOGBACK-1595 (in detail [https://github.com/qos-ch/logback/blob/f93f3bbe643d3859cc18cb4ee8829d9c26e8d357/logback-core/src/main/java/ch/qos/logback/core/ConsoleAppender.java#L112]) fail on Java 8 (empty orElseThrow()-Method has only been added in Java 10 (see [https://bugs.openjdk.org/browse/JDK-8140281).|https://bugs.openjdk.org/browse/JDK-8140281)] ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From logback-dev at qos.ch Tue May 2 10:32:00 2023 From: logback-dev at qos.ch (logback developers list) Date: Tue, 2 May 2023 10:32:00 +0200 (CEST) Subject: [logback-dev] [JIRA] (LOGBACK-1737) NoSuchMethod error on Java 8 in ConsoleAppender, Jansi2-code In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 403 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 3408 bytes Desc: not available URL: From logback-dev at qos.ch Sat May 6 19:04:00 2023 From: logback-dev at qos.ch (logback developers list) Date: Sat, 6 May 2023 19:04:00 +0200 (CEST) Subject: [logback-dev] [JIRA] (LOGBACK-1711) Deadlock when using Virtual Threads In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 403 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 799 bytes Desc: not available URL: From logback-dev at qos.ch Thu May 11 19:14:00 2023 From: logback-dev at qos.ch (logback developers list) Date: Thu, 11 May 2023 19:14:00 +0200 (CEST) Subject: [logback-dev] [JIRA] (LOGBACK-212) Add a layout that produces JSON In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 375 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 3408 bytes Desc: not available URL: From logback-dev at qos.ch Fri May 12 19:56:41 2023 From: logback-dev at qos.ch (logback developers list) Date: Fri, 12 May 2023 19:56:41 +0200 Subject: [logback-dev] Announcing investment by the Sovereign Tech Fund Message-ID: Hello all, In addition to preexisting support from companies such as Google, Exolab and Spotify R&D, we are excited to announce a sustained and multi-year investment from the Sovereign Tech Fund (STF) for the maintenance and improvement of logback, SLF4J and reload4j projects [1]. In 2006, we founded the SLF4J and logback projects and continue to maintain them until this day. Cumulatively, the artifacts of these two projects are downloaded over 4 billion times per year. Given the sheer volume of users, maintaining the SLF4J and logback projects can be rather time consuming. In 2022, we started the reload4j project with the goal of fixing critical security issues in log4j 1.x. We wish to continue providing the most reliable, fast and flexible logging framework for Java developers and heartily thank the STF for choosing to invest in our projects. The Sovereign Tech Fund supports the development, improvement and maintenance of digital infrastructure. Their goal is to sustainably strengthen the open source ecosystem, with a focus on security, resilience, technological diversity, and the people behind the projects. As Cailean Osborne aptly put it [2]: “As one of the first governmental funds dedicated to OSS, the STF is spearheading a critical shift in how governments invest in the long-term viability of OSS and digital public goods." In our own experience, even the tiniest token of support counts. It goes without saying that a larger multi-year investment counts all the more. We would like to express our gratitude to the Sovereign Tech Fund for their support and for paving the way for this historical change. [1] https://tinyurl.com/stfLogback [2] https://tinyurl.com/stfCaileanOsborne -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch From logback-dev at qos.ch Fri May 12 20:12:00 2023 From: logback-dev at qos.ch (logback developers list) Date: Fri, 12 May 2023 20:12:00 +0200 (CEST) Subject: [logback-dev] [JIRA] (LOGBACK-1738) Some flaky tests In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 403 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 3408 bytes Desc: not available URL: From logback-dev at qos.ch Fri May 12 20:18:00 2023 From: logback-dev at qos.ch (logback developers list) Date: Fri, 12 May 2023 20:18:00 +0200 (CEST) Subject: [logback-dev] [JIRA] Updates for LOGBACK-1738: Some flaky tests In-Reply-To: References: Message-ID: logback / LOGBACK-1738 [Open] Some flaky tests ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1738 ============================== Issue created ------------------------------ Agor Malon created this issue on 12/May/23 20:07 Summary: Some flaky tests Issue Type: Bug Affects Versions: 1.4.7 Assignee: Logback dev list Components: logback-classic, logback-core Created: 12/May/23 20:07 Labels: Tests Priority: Major Reporter: Agor Malon Description: Hello, We tried running your project and discovered that it contains some flaky tests (i.e., tests that nondeterministically pass and fail). We found these tests to fail more frequently when running them on certain machines of ours. To prevent others from running this project and its tests in machines that may result in flaky tests, we suggest adding information to the README.md file indicating the minimum resource configuration for running the tests of this project as to prevent observation of test flakiness. If we run this project in a machine with 1cpu and 1gb ram, we observe flaky tests. We found that the tests in this project did not have any flaky tests when we ran it on machines with 2cpu and 2gb ram. Here is a list of the tests we have identified and their likelihood of failure on a system with less than the recommended 2 CPUs and 2 GB RAM. # org.apache.shardingsphere.elasticjob.error.handler.wechat.WechatJobErrorHandlerTest#assertHandleExceptionWithNotifySuccessful ( 4 out 10 ) # org.apache.shardingsphere.elasticjob.cloud.scheduler.mesos.MesosStateServiceTest#assertExecutors (1 out 10) # org.apache.shardingsphere.elasticjob.error.handler.wechat.WechatJobErrorHandlerTest#assertHandleExceptionWithWrongToken (1 out 10) # org.apache.shardingsphere.elasticjob.http.executor.HttpJobExecutorTest#assertProcessWithGet (1 out 10) # org.apache.shardingsphere.elasticjob.lite.spring.namespace.job.OneOffJobSpringNamespaceWithTypeTest#jobScriptWithJobTypeTest (1 out 10) Please let me know if you would like us to create a pull request on this matter (possibly to the readme of this project). Thank you for your attention to this matter. We hope that our recommendations will be helpful in improving the quality and performance of your project, especially for others to use h3. Reproducing Dockerfile   {code:java} FROM maven:3.5.4-jdk-11 WORKDIR /home/ RUN git clone https://github.com/apache/shardingsphere-elasticjob && \ cd shardingsphere-elasticjob && \ git checkout 2bfce1ebc39475e1b8eda456b673ab9431c0f270 WORKDIR /home/shardingsphere-elasticjob RUN mvn install -DskipTests ENTRYPOINT ["mvn", "test", "-fn"]   {code}   Build the image: {code:java} $> mkdir tmp $> cp Dockerfile tmp $> cd tmp $> docker build -t elasticjob . # estimated time of build 3m {code} Running: this configuration likely prevents flakiness (no flakiness in 10 runs) {code:java} $> docker run --rm --memory=2g --cpus=2 --memory-swap=-1 elasticjob | tee output.txt $> grep "Failures:" output.txt # checking results {code}   this other configuration -similar to the previous- can't prevent flaky tests (observation in 10 runs) {code:java} $> docker run --rm --memory=1g --cpus=1 --memory-swap=-1 elasticjob | tee output2.txt $> grep "Failures:" output2.txt # checking results{code} ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From logback-dev at qos.ch Fri May 12 20:23:00 2023 From: logback-dev at qos.ch (logback developers list) Date: Fri, 12 May 2023 20:23:00 +0200 (CEST) Subject: [logback-dev] [JIRA] (LOGBACK-1738) Some flaky tests In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 403 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 921 bytes Desc: not available URL: From logback-dev at qos.ch Fri May 12 20:37:00 2023 From: logback-dev at qos.ch (logback developers list) Date: Fri, 12 May 2023 20:37:00 +0200 (CEST) Subject: [logback-dev] [JIRA] (LOGBACK-1738) Some flaky tests In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 403 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 3408 bytes Desc: not available URL: From logback-dev at qos.ch Fri May 12 20:37:00 2023 From: logback-dev at qos.ch (logback developers list) Date: Fri, 12 May 2023 20:37:00 +0200 (CEST) Subject: [logback-dev] [JIRA] (LOGBACK-1738) Some flaky tests In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 403 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 3408 bytes Desc: not available URL: From logback-dev at qos.ch Fri May 12 20:39:00 2023 From: logback-dev at qos.ch (logback developers list) Date: Fri, 12 May 2023 20:39:00 +0200 (CEST) Subject: [logback-dev] [JIRA] Updates for LOGBACK-1739: Some Flaky Test In-Reply-To: References: Message-ID: logback / LOGBACK-1739 [Open] Some Flaky Test ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1739 ============================== Issue created ------------------------------ Agor Malon created this issue on 12/May/23 20:28 Summary: Some Flaky Test Issue Type: Bug Affects Versions: 1.4.7 Assignee: Logback dev list Components: logback-classic, logback-core Created: 12/May/23 20:28 Labels: Tests Priority: Major Reporter: Agor Malon Description: Hello, We tried running your project and discovered that it contains some flaky tests (i.e., tests that nondeterministically pass and fail). We found these tests to fail more frequently when running them on certain machines of ours. To prevent others from running this project and its tests in machines that may result in flaky tests, we suggest adding information to the README.md file indicating the minimum resource configuration for running the tests of this project as to prevent observation of test flakiness. If we run this project in a machine with 1cpu and 1gb ram, we observe flaky tests. We found that the tests in this project did not have any flaky tests when we ran it on machines with 2cpu and 4gb ram. Here is a list of the tests we have identified and their likelihood of failure on a system with less than the recommended 2 CPUs and 4 GB RAM. # ch.qos.logback.core.AsyncAppenderBaseTest#lossyAppenderShouldOnlyLoseCertainEvents (4 out 10) # ch.qos.logback.core.AsyncAppenderBaseTest#verifyInterruptionOfWorkerIsSwallowed (5 out 10) # ch.qos.logback.classic.net.SMTPAppender_GreenTest#synchronousSmoke (6 out 10) # ch.qos.logback.classic.LoggerContextConcurrentResetTest#concurrentReset (3 out 10) # ch.qos.logback.core.net.server.ServerSocketAppenderBaseFunctionalTest#testLogEventClient (4 out 10) # ch.qos.logback.core.AsyncAppenderBaseTest#stopExitsWhenMaxRuntimeReached (7 out 10)   Please let me know if you would like us to create a pull request on this matter (possibly to the readme of this project). Thank you for your attention to this matter. We hope that our recommendations will be helpful in improving the quality and performance of your project, especially for others to use.   h3. Reproducing     {code:java} FROM maven:3.5.4-jdk-11   WORKDIR /home/   RUN git clone https://github.com/qos-ch/logback/ && \   cd logback && \   git checkout 6abce2f047a58292d23f3d80f40dab2b9912aa3f    WORKDIR /home/logback   RUN mvn install -DskipTests   ENTRYPOINT ["mvn", "test", "-fn"] {code}   Build the image:   {code:java} $> mkdir tmp $> cp Dockerfile tmp $> cd tmp $> docker build -t logback . # estimated time of build 3m {code} Running: this configuration likely prevents flakiness (no flakiness in 10 runs)   {code:java} $> docker run --rm --memory=4g --cpus=2 --memory-swap=-1 logback | tee output.txt $> grep "Failures:"  output.txt # checking results {code}      this other configuration can’t prevent flaky tests (observation in 10 runs)   {code:java} $> docker run --rm --memory=1g --cpus=1 --memory-swap=-1 logback | tee output2.txt $> grep "Failures:"  output2.txt # checking results {code}         ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From logback-dev at qos.ch Tue May 16 09:54:00 2023 From: logback-dev at qos.ch (logback developers list) Date: Tue, 16 May 2023 09:54:00 +0200 (CEST) Subject: [logback-dev] [JIRA] Updates for LOGBACK-1740: Number of async tasks limited to 32 on In-Reply-To: References: Message-ID: logback / LOGBACK-1740 [Open] Number of async tasks limited to 32 on ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1740 ============================== Issue created ------------------------------ dgodmun created this issue on 16/May/23 9:43 Summary: Number of async tasks limited to 32 on Issue Type: Bug Affects Versions: 1.3.7 Assignee: Logback dev list Components: logback-core Created: 16/May/23 9:43 Labels: SizeAndTimeBasedRollingPolicy Priority: Major Reporter: dgodmun Description: Hello,   I've found an issue related with the class CoreConstants:   /** * Maximum number of threads to allow in a context's executor service. */ // if you need a different MAX_POOL_SIZE, please file create a jira issue // asking to make MAX_POOL_SIZE a parameter. public static final int MAX_POOL_SIZE = 32;   The size of the pool is causing a problem when using SizeAndTimeBasedRollingPolicy at the end of the day when the number of files in the logger is bigger than 32. See log details of the issue: 02:00:01,852 |-INFO in c.q.l.co.rolling.helper.RenameUtil - Renaming file [/.../DEMO_LP3/USDAED.log] to [/.../DEMO_LP3/USDAED.2023-05-11.0.log2522180056964847.tmp] 02:00:01,852 |-ERROR in  SizeAndTimeBasedFNATP [FILE-SIFT] - Appender [FILE-SIFT] failed to append. java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask at 398bae3b[Not completed, task = java.util.concurrent.Executors$RunnableAdapter at 198af505[Wrapped task = ch.qos.logback.core.rolling.helper.Compressor$CompressionRunnable at 3d7e666b]] rejected from java.util.concurrent.ThreadPoolExecutor at 296f8602[Running, pool size = 32, active threads = 32, queued tasks = 0, completed tasks = 91]     at java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask at 398bae3b[Not completed, task = java.util.concurrent.Executors$RunnableAdapter at 198af505[Wrapped task = ch.qos.logback.core.rolling.helper.Compressor$CompressionRunnable at 3d7e666b]] rejected from java.util.concurrent.ThreadPoolExecutor at 296f8602[Running, pool size = 32, active threads = 32, queued tasks = 0, completed tasks = 91]     at     at java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2065)     at     at java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:833)     at     at java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1365)     at     at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:123)     at     at ch.qos.logback.core.rolling.helper.Compressor.asyncCompress(Compressor.java:229)     at     at ch.qos.logback.core.rolling.TimeBasedRollingPolicy.renameRawAndAsyncCompress(TimeBasedRollingPolicy.java:196)     at     at ch.qos.logback.core.rolling.TimeBasedRollingPolicy.rollover(TimeBasedRollingPolicy.java:182)     at     at ch.qos.logback.core.rolling.RollingFileAppender.attemptRollover(RollingFileAppender.java:220)     at     at ch.qos.logback.core.rolling.RollingFileAppender.rollover(RollingFileAppender.java:198)     at     at ch.qos.logback.core.rolling.RollingFileAppender.subAppend(RollingFileAppender.java:246)     at     at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:102)     at     at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:85)     at     at ch.qos.logback.core.sift.SiftingAppenderBase.append(SiftingAppenderBase.java:122)     at     at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:83)     at     at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachab The issue leaves a tmp file in the disk.   In order to reproduce it is just required having more than 32 files to roll with a reasonable size, if the queue of the thread pool is full then it will fail.     It would be very interesting having the possibility of defining the number of threads by configuration. I know the case I'm working on is very special, it is not comming having so many files rolling at the end of the day for the logger. Thank you very much.   ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From logback-dev at qos.ch Tue May 16 14:08:00 2023 From: logback-dev at qos.ch (logback developers list) Date: Tue, 16 May 2023 14:08:00 +0200 (CEST) Subject: [logback-dev] [JIRA] Updates for LOGBACK-1741: AsyncAppender hangs intermittently In-Reply-To: References: Message-ID: logback / LOGBACK-1741 [Open] AsyncAppender hangs intermittently ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1741 ============================== Issue created ------------------------------ Jingfei Hu created this issue on 16/May/23 13:56 Summary: AsyncAppender hangs intermittently Issue Type: Bug Affects Versions: 1.3.1 Assignee: Logback dev list Components: logback-classic, logback-core Created: 16/May/23 13:56 Environment: openjdk version "1.8.0_332" OpenJDK Runtime Environment (build 1.8.0_332-b718) OpenJDK 64-Bit Server VM (build 25.332-b718, mixed mode) Labels: AsyncAppender Priority: Major Reporter: Jingfei Hu Description: Hello team, Recently we leverage AsyncAppender to reduce latency as logging. It does help to reduce the latency in case of large amounts of logging events. However, we spot a hang issue. Though, for now, it occurs only once, we're afraid it's a bug of logback or JDK and it might happen again. Below is the thread stack, almost all threads of our process are blocked on this lock and we fail to locate the thread owning this lock(it's weird that jstack doesn't show which thread holds that lock, we guess the thread holding the lock might crash for somehow reason, but we have no way to prove that) {code:java} "msgWorkTP-582450565-6-thread-1" #642 prio=5 os_prio=0 tid=0x00007efec4094000 nid=0x4ca7 waiting on condition [0x00007efe841f9000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park0(Native Method) - parking to wait for <0x00000007463ab208> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at sun.misc.Unsafe.park(Unsafe.java:1038) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:176) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:842) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:876) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1207) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285) at java.util.concurrent.ArrayBlockingQueue.remainingCapacity(ArrayBlockingQueue.java:468) at ch.qos.logback.core.AsyncAppenderBase.isQueueBelowDiscardingThreshold(AsyncAppenderBase.java:170) at ch.qos.logback.core.AsyncAppenderBase.append(AsyncAppenderBase.java:162) at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:85) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:272) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:259) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:426) at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:386) at ch.qos.logback.classic.Logger.info(Logger.java:584) {code} Our configuration is below {code:java} 1024 0 true {code} And module configuration of MODULE_APPENDER is below {code:java} ${user.home}/logs/sandbox/platform-test-support-sandbox-module.log ${user.home}/logs/sandbox/platform-test-support-sandbox-module.log.%d{yyyy-MM-dd}.%i 100MB 5 500MB %d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %msg%n UTF-8 INFO {code} ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From logback-dev at qos.ch Sun May 21 23:05:00 2023 From: logback-dev at qos.ch (logback developers list) Date: Sun, 21 May 2023 23:05:00 +0200 (CEST) Subject: [logback-dev] [JIRA] Updates for LOGBACK-1742: Allow LogbackMDCAdapter to be set non-statically In-Reply-To: References: Message-ID: logback / LOGBACK-1742 [Open] Allow LogbackMDCAdapter to be set non-statically ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1742 ============================== Issue created ------------------------------ Ceki Gülcü created this issue on 21/May/23 22:54 Summary: Allow LogbackMDCAdapter to be set non-statically Issue Type: Bug Assignee: Logback dev list Created: 21/May/23 22:54 Priority: Major Reporter: Ceki Gülcü ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af) From logback-dev at qos.ch Sun May 21 23:39:00 2023 From: logback-dev at qos.ch (logback developers list) Date: Sun, 21 May 2023 23:39:00 +0200 (CEST) Subject: [logback-dev] [JIRA] (LOGBACK-1742) Allow LogbackMDCAdapter to be set non-statically In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 403 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 3408 bytes Desc: not available URL: From logback-dev at qos.ch Tue May 30 11:50:00 2023 From: logback-dev at qos.ch (logback developers list) Date: Tue, 30 May 2023 11:50:00 +0200 (CEST) Subject: [logback-dev] [JIRA] (LOGBACK-1735) ILoggingEvent#getInstant should return `Instant.ofEpochMills(getTimeStamp())` instead of null for compatibility In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 799 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 460 bytes Desc: not available URL: From logback-dev at qos.ch Tue May 30 23:30:00 2023 From: logback-dev at qos.ch (logback developers list) Date: Tue, 30 May 2023 23:30:00 +0200 (CEST) Subject: [logback-dev] [JIRA] Updates for LOGBACK-1743: SocketReceiver configuration broken In-Reply-To: References: Message-ID: logback / LOGBACK-1743 [Open] SocketReceiver configuration broken ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1743 ============================== Issue created ------------------------------ Volker Götz created this issue on 30/May/23 23:19 Summary: SocketReceiver configuration broken Issue Type: Bug Affects Versions: 1.4.0, 1.4.7 Assignee: Logback dev list Created: 30/May/23 23:19 Priority: Major Reporter: Volker Götz Description: The standard {{ServerSocketReceiver}} configuration, as mentioned in the [documentation chapter 13 |https://logback.qos.ch/manual/receivers.html] is not working anymore. The XML configuration cannot be parsed: {code} Can't handle model of type class ch.qos.logback.classic.model.ReceiverModel with tag: receiver at line 13 Ignoring unknown property [port] in [ch.qos.logback.classic.LoggerContext] {code} Configuration file: {code:xml} %d{HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n 9876 {code} The full log output with the error: {code} 23:16:45,076 |-INFO in ch.qos.logback.classic.LoggerContext[default] - This is logback-classic version 1.4.7 23:16:45,091 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml] 23:16:45,093 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/Users/volker/Workspaces/IntelliJ/G-ITS/logback-receiver/build/resources/main/logback.xml] 23:16:45,170 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - Processing appender named [CONSOLE] 23:16:45,171 |-INFO in ch.qos.logback.core.model.processor.AppenderModelHandler - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender] 23:16:45,175 |-INFO in ch.qos.logback.core.model.processor.ImplicitModelHandler - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property 23:16:45,183 |-INFO in ch.qos.logback.classic.model.processor.RootLoggerModelHandler - Setting level of ROOT logger to DEBUG 23:16:45,183 |-INFO in ch.qos.logback.core.model.processor.AppenderRefModelHandler - Attaching appender named [CONSOLE] to Logger[ROOT] 23:16:45,186 |-ERROR in ch.qos.logback.core.model.processor.DefaultProcessor at 3023df74 - Can't handle model of type class ch.qos.logback.classic.model.ReceiverModel with tag: receiver at line 13 23:16:45,187 |-WARN in ch.qos.logback.core.model.processor.ImplicitModelHandler - Ignoring unknown property [port] in [ch.qos.logback.classic.LoggerContext] 23:16:45,187 |-ERROR in ch.qos.logback.core.model.processor.DefaultProcessor at 3023df74 - Can't handle model of type class ch.qos.logback.classic.model.ReceiverModel with tag: receiver at line 13 23:16:45,187 |-INFO in ch.qos.logback.core.model.processor.DefaultProcessor at 3023df74 - End of configuration. 23:16:45,188 |-INFO in ch.qos.logback.classic.joran.JoranConfigurator at 5e0e82ae - Registering current configuration as safe fallback point {code} ============================== This message was sent by Atlassian Jira (v9.6.0#960000-sha1:a3ee8af)