September 2017 - logback-dev

[JIRA] (LOGBACK-1341) SizeAndTimeBasedRollingPolicy does not zip all the files on day change
by QOS.CH (JIRA) 14 Sep '17

14 Sep '17

Abhishek Mundewal created LOGBACK-1341: ------------------------------------------ Summary: SizeAndTimeBasedRollingPolicy does not zip all the files on day change Key: LOGBACK-1341 URL: https://jira.qos.ch/browse/LOGBACK-1341 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.2.3 Environment: Reporter: Abhishek Mundewal Assignee: Logback dev list SizeAndTimeBasedRollingPolicy does not zip all the files on day change. Due to that it does not clean/delete the older (older than MaxHistory) files. We've the application those are generating big (2GB/3GB) log files on daily basis, so that's why we moved to SizeAndTimeBasedRollingPolicy from TimeBasedRollingPolicy, but here is a problem that (SizeAndTimeBasedRollingPolicy) does not zip/archive all the files on day change, that's why when max history reached the files which were archived/zipped were deleted but rest were left there. I googled but did not find any solution for that. Please consider adding this feature to Logback and feel free to contact me if further clarification is required. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1340) Color support and OSGi
by QOS.CH (JIRA) 13 Sep '17

13 Sep '17

Antonio Facciorusso created LOGBACK-1340: -------------------------------------------- Summary: Color support and OSGi Key: LOGBACK-1340 URL: https://jira.qos.ch/browse/LOGBACK-1340 Project: logback Issue Type: Bug Components: logback-classic Affects Versions: 1.2.3 Environment: Equinox OSGi environment running on Windows 10 Pro 64bit. Logback: 1.2.3 Jansi: 1.16 Reporter: Antonio Facciorusso Assignee: Logback dev list Attachments: logback-classic-jansi-error.log The following exception is thrown when _"<withJansi>true</withJansi>"_ is used with ConsoleAppender on Windows (full stack trace in attached log file): _16:39:40,801 |-WARN in ch.qos.logback.core.ConsoleAppender[STDOUT] - Failed to create WindowsAnsiOutputStream. Falling back on the default stream. ch.qos.logback.core.util.DynamicClassLoadingException: Failed to instantiate type org.fusesource.jansi.WindowsAnsiOutputStream_ _at ch.qos.logback.core.util.DynamicClassLoadingException: Failed to instantiate type org.fusesource.jansi.WindowsAnsiOutputStream_ _at at ch.qos.logback.core.util.OptionHelper.instantiateByClassNameAndParameter(OptionHelper.java:69)_ ... _Caused by: java.lang.ClassNotFoundException: org.fusesource.jansi.WindowsAnsiOutputStream cannot be found by ch.qos.logback.classic_1.2.3_ _at at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:432)_ _at at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:345)_ _at at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:337)_ _at at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)_ _at at java.lang.ClassLoader.loadClass(ClassLoader.java:357)_ _at at ch.qos.logback.core.util.OptionHelper.instantiateByClassNameAndParameter(OptionHelper.java:56)_ _at ... 49 common frames omitted_ the jansi library correctly exports this package and logback-core correctly imports the same package. It seems that the following entry is missing in logback-classic's MANIFEST.MF file: *org.fusesource.jansi; resolution:=optional; version="[1.9, 2)"* -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-624) MDC Adapter with configurable InheritableThreadLocal
by QOS.CH (JIRA) 13 Sep '17

13 Sep '17

1 0

Moving Java Forward Faster
by Rory O'Donnell 07 Sep '17

07 Sep '17

Hi Ceki, Oracle is proposing a rapid release model for Java SE going-forward. The high points are highlighted below, details of the changes can be found on Mark Reinhold’s blog [1] , OpenJDK discussion email list [2]. Under the proposed release model, after JDK 9, we will adopt a strict, time-based model with a new major release every six months, update releases every quarter, and a long-term support release every three years. The new JDK Project will run a bit differently than the past "JDK $N" Projects: - The main development line will always be open but fixes, enhancements, and features will be merged only when they're nearly finished. The main line will be Feature Complete [3] at all times. - We'll continue to use the JEP Process [4] for new features and other significant changes. The bar to target a JEP to a specific release will, however, be higher since the work must be Feature Complete in order to go in. Owners of large or risky features will be strongly encouraged to split such features up into smaller and safer parts, to integrate earlier in the release cycle, and to publish separate lines of early-access builds prior to integration. The JDK Updates Project will run in much the same way as the past "JDK $N" Updates Projects, though update releases will be strictly limited to fixes of security issues, regressions, and bugs in newer features. Related to this proposal, we intend to make a few changes in what we do: - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [5], to make it easier for developers to deploy Java applications to cloud environments. We'll initially publish OpenJDK builds for Linux/x64, followed later by builds for macOS/x64 and Windows/x64. - We'll continue to ship proprietary "Oracle JDK" builds, which include "commercial features" [6] such as Java Flight Recorder and Mission Control [7], under a click-through binary-code license [8]. Oracle will continue to offer paid support for these builds. - After JDK 9 we'll open-source the commercial features in order to make the OpenJDK builds more attractive to developers and to reduce the differences between those builds and the Oracle JDK. This will take some time, but the ultimate goal is to make OpenJDK and Oracle JDK builds completely interchangeable. - Finally, for the long term we'll work with other OpenJDK contributors to establish an open build-and-test infrastructure. This will make it easier to publish early-access builds for features in development, and eventually make it possible for the OpenJDK Community itself to publish authoritative builds of the JDK. Questions , comments, feedback to OpenJDK discuss mailing list [2] Rgds,Rory [1]https://mreinhold.org/blog/forward-faster [2]http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html [3]http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete [4]http://openjdk.java.net/jeps/0 [5]http://openjdk.java.net/legal/gplv2+ce.html [6]http://www.oracle.com/technetwork/java/javase/terms/products/index.html [7]http://www.oracle.com/technetwork/java/javaseproducts/mission-control/ind… [8]http://www.oracle.com/technetwork/java/javase/terms/license/index.html

1 0

[JIRA] (LOGBACK-1106) There is no conversion class registered for conversion word [d]
by QOS.CH (JIRA) 01 Sep '17

01 Sep '17

1 0