May 2019 - logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1468) I want to store only the last 500MB log data everyday and gzip it .
by QOS.CH (JIRA) 31 May '19

31 May '19

Vamsi Vutukuri created LOGBACK-1468: ---------------------------------------- Summary: I want to store only the last 500MB log data everyday and gzip it . Key: LOGBACK-1468 URL: https://jira.qos.ch/browse/LOGBACK-1468 Project: logback Issue Type: Task Components: logback-core Affects Versions: 1.1.8 Environment: Ubuntu 14.04 logback.xml Reporter: Vamsi Vutukuri Assignee: Logback dev list Attachments: text.txt Hi help to complete the task . I need only the last 500MB generated logs data each day and compress it and have backup of 10days and should delete the older file after 10th day Even though i use rolling file appender its zipping the first 500MB data and creating a tmp file if the app generates extra 500mb data same day i need to store only 500mb data that to app lastestly generated logs . He is my configuration : <appender name="FILE-ROLLING" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>test.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <fileNamePattern>test.%d\{yyyy-MM-dd}.%i.log.gz</fileNamePattern>  <maxFileSize>500MB</maxFileSize>  <totalSizeCap>5GB</totalSizeCap>  <maxHistory>10</maxHistory> </rollingPolicy> <encoder> <pattern>%d\{yyyy-MM-dd HH:mm:ss:SSS}*%m%n<</pattern> </encoder> </appender> -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1467) LogbackValve fails to find config with absolute path outside of tomcat home
by QOS.CH (JIRA) 31 May '19

31 May '19

Tamás Györgyey created LOGBACK-1467: --------------------------------------- Summary: LogbackValve fails to find config with absolute path outside of tomcat home Key: LOGBACK-1467 URL: https://jira.qos.ch/browse/LOGBACK-1467 Project: logback Issue Type: Bug Components: logback-access Affects Versions: 1.2.3 Environment: linux, tomcat 9, java 11 Reporter: Tamás Györgyey Assignee: Logback dev list Priority: Trivial When a filename property is specified, LogbackValve searches for the config by prepending catalina.base and catalina.home to the path, then looks for it as a resource. Neither of those manages to find a file referenced with an absolute path (e.g. /tmp/logback-access.xml). A simple workaround is to create a symlink from the default location to the external file, but this shouldn't be necessary. Specifying a file location outside tomcat home is convenient in certain situations and should be supported. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 13 - Early Access build 23 is available
by Rory O'Donnell 31 May '19

31 May '19

Hi Ceki, *OpenJDK builds *- JDK 13 - Early Access build 23 is available at http://jdk.java.net/13/ * These early-access , open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Changes in this build <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B22%22%3A%3…> * Release notes [1] *Significant changes since the last availability email* * build 23 o Support for Unicode 12.1 (JDK-8221431 <https://bugs.openjdk.java.net/browse/JDK-8221431>) o Add new keytool -showinfo -tls command for displaying TLS configuration information (JDK-8219861 <https://bugs.openjdk.java.net/browse/JDK-8219861>) * build 22 o New methods for creating DOM and SAX factories with Namespace support (JDK-8219692 <https://bugs.openjdk.java.net/browse/JDK-8219692>) o Removal of two DocuSign root CA certificates (JDK-8223499 <https://bugs.openjdk.java.net/browse/JDK-8223499>) * build 21 o JDWP support for IPv6 (JDK-8184770 <https://bugs.openjdk.java.net/browse/JDK-8184770>) o Change the mechanism by which JDK loads the platform-specific AWT Toolkit (JDK-8212700 <https://bugs.openjdk.java.net/browse/JDK-8212700>) o Upgrade CLDR to Version 35.1 (JDK-8221432 <https://bugs.openjdk.java.net/browse/JDK-8221432>) o xConfigurable Read Timeout for CRLs (JDK-8191808 <https://bugs.openjdk.java.net/browse/JDK-8191808>) o Removal of two Comodo root CA certificates (JDK-8222136 <https://bugs.openjdk.java.net/browse/JDK-8222136>) Bug fixes for issues reported by Open Source Projects * build 22 o OutOfMemory on compiling with darcula.jar in classpath (JDK-8222807 <https://bugs.openjdk.java.net/browse/JDK-8222807>) * build 21 o java -version output and certain system properties contain "null" text in their values (JDK-8223695 <https://bugs.openjdk.java.net/browse/JDK-8223695>) * build 20 o assert(Compile::current()->live_nodes() < Compile::current()->max_node_limit()) failed: Live Node limit exceeded limit (JDK-8219520 <https://bugs.openjdk.java.net/browse/JDK-8219520>) o C2: MemNode::can_see_stored_value() ignores casts which carry control dependency (JDK-8219902 <https://bugs.openjdk.java.net/browse/JDK-8219902>) o New fix of the deadlock in sun.security.ssl.SSLSocketImpl (JDK-8219991 <https://bugs.openjdk.java.net/browse/JDK-8219991>) JEP updates since last email * JEP 350: Dynamic CDS Archives <http://openjdk.java.net/jeps/350> was *Integrated*. * JEP 351: ZGC: Uncommit Unused Memory <http://openjdk.java.net/jeps/351> was *Integrated*. * JEP 353: Reimplement the Legacy Socket API <http://openjdk.java.net/jeps/353> was*Targetted* JDK 13. * JEP 355: Text Blocks (Preview) <http://openjdk.java.net/jeps/355> was *Proposed to target* JDK 13. Rgds,Rory [1] http://jdk.java.net/13/release-notes -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

[JIRA] (LOGBACK-1466) Log File's default read&write authority
by QOS.CH (JIRA) 23 May '19

23 May '19

wangtie created LOGBACK-1466: -------------------------------- Summary: Log File's default read&write authority Key: LOGBACK-1466 URL: https://jira.qos.ch/browse/LOGBACK-1466 Project: logback Issue Type: Improvement Environment: Linux Reporter: wangtie Assignee: Logback dev list Priority: Minor My jar file can be execute by some users they belongs to different groups. When some one lanuch the jar file , and if this jar executed by some others before, we will get an exception, because the log file's default access authority is 644. Is there any configure option to solve this? Thank you -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1421) Logback 1.2.3 threads getting deadlocked at CachingDateFormatter
by QOS.CH (JIRA) 20 May '19

20 May '19

1 0

[JIRA] (LOGBACK-1465) xxe vulnerability in Logback
by QOS.CH (JIRA) 16 May '19

16 May '19

1 0

[JIRA] (LOGBACK-1465) xxe vulnerability in Logback
by QOS.CH (JIRA) 16 May '19

16 May '19

1 0

Why my logs contain null characters(holes)
by Tianjiao Liu 15 May '19

15 May '19

Hi all, I am using logback(SiftingAppender and RollingFileAppender) in my application. Whenever requests come in, they will be logged to different files according to the id from url query. This is working really well and I get the expected result. However, I noticed occasionally, there are some null characters in the middle of logs. I am not sure why this happens and how to reduce it. I did some research and the closest thing I found is https://serverfault.com/questions/71341/why-do-jboss-and-logrotate-create-l… They are using logrotate with log4j and that results in the null character. However, in my case, the whole log rotate and lifecycle is handled by logback. This is partial of my logback xml configuration: <appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"><discriminator> <key>id</key> <defaultValue>main</defaultValue></discriminator><sift> <appender name="${id}Rolling" class="ch.qos.logback.core.rolling.RollingFileAppender"> <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <fileNamePattern>${logRoot}/${id}.%d{"yyyy-MM-dd-HH", UTC}.%i.json</fileNamePattern> <maxFileSize>${logSizeLimit}</maxFileSize> <maxHistory>100</maxHistory> <totalSizeCap>20GB</totalSizeCap> </rollingPolicy> <encoder> <pattern>%msg%n</pattern> </encoder> </appender></sift> And in the java code: String jsonOutput = gson.toJson(ping); MDC.put("id", id)); logger.info(jsonOutput); MDC.remove("id"); The output log looks like : {"timestamp":{"seconds":1557048143,"nanos":028000000},"httpRequest":{"status":200,"remoteIp":"111.11.111.111","requestMethod":"GET","requestUrl":" https://my.example.com/?id=testid","userAgent":"Mozilla/5.0 "}} ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@{"timestamp":{"seconds":1557041043,"nanos":318000000},"httpRequest":{"status":200,"remoteIp":"111.11.111.111","requestMethod":"GET","requestUrl":" https://my.example.com/?id=testid","userAgent":"Mozilla/5.0 "}} I am using vim to open it, so it displays null character as ^@. These null characters are appended at the beginning of a real log message. I haven't found a pattern when this will happen. Does anyone have any idea why this happens? Best regards, TJ Liu

1 0

[JIRA] (LOGBACK-745) TimeBasedRollingPolicy does not trigger
by QOS.CH (JIRA) 10 May '19

10 May '19

1 0

[JIRA] (LOGBACK-745) TimeBasedRollingPolicy does not trigger
by QOS.CH (JIRA) 10 May '19

10 May '19

1 0