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

[JIRA] (LOGBACK-1336) TimeBasedRollingPolicy doesn't perform rollover twice a day when AM/PM pattern is used
by QOS.CH (JIRA) 17 Aug '17

17 Aug '17

Volodymyr Masliy created LOGBACK-1336: ----------------------------------------- Summary: TimeBasedRollingPolicy doesn't perform rollover twice a day when AM/PM pattern is used Key: LOGBACK-1336 URL: https://jira.qos.ch/browse/LOGBACK-1336 Project: logback Issue Type: Bug Affects Versions: 1.2.3 Reporter: Volodymyr Masliy Assignee: Logback dev list When %d\{yyyy-MM-dd-a} pattern is used in rolling policy, logback performs rolling on daily basis, whereas twice a day rolling is expected. Example: 2017-08-17-AM.log and 2017-08-17-PM.log -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1335) Internal logback threads with same name created at server startup
by QOS.CH (JIRA) 16 Aug '17

16 Aug '17

1 0

[JIRA] (LOGBACK-1335) Internal logback threads with same name created at server startup
by QOS.CH (JIRA) 14 Aug '17

14 Aug '17

Kirti Singh created LOGBACK-1335: ------------------------------------ Summary: Internal logback threads with same name created at server startup Key: LOGBACK-1335 URL: https://jira.qos.ch/browse/LOGBACK-1335 Project: logback Issue Type: Bug Components: logback-core Affects Versions: 1.1.7 Environment: Linux application deployed on apache tomcat Reporter: Kirti Singh Assignee: Logback dev list Attachments: logback.jpg *Scenario:* I have a web application written in java. The application is deployed on multiple linux servers on apache tomcat(version 8.0.41). I am using springboot starter managed logback. Spring version: 1.3.5.RELEASE this version internally manages 1.7.1 version of logback. My logback file has timebased as well as sizebased policy set. *Issue:* I am observing a sporadic issue on few servers where log file breaks into two at random time. The weird part is that the file that gets rolled over has last day's date(instead of today's date) and future logs keep getting written to this rolled file instead of the new file that is created. *Observation:* I connected my application with visualvm and saw that two internal threads of logback are created with the same name. I have attached a screenshot from visualvm showing two threads with logback-1 name and two threads named logback-2. Ideally this should not happen because "Threads created internally by logback are now named _logback-n_, where _n_ is an integer. For the first thread _n_ is set to 1, for each successive thread _n_ is incremented by 1."(ref: [https://logback.qos.ch/news.html) I have a hunch that somehow logback is misbehaving to create two threads at server startup. *For notice:* This is not happening across all the servers. This is sporadic. Also, All our servers have equal load balancing in place. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1334) Conditional support without need for Janino library (use JavaScript)
by QOS.CH (JIRA) 10 Aug '17

10 Aug '17

Jan Engehausen created LOGBACK-1334: --------------------------------------- Summary: Conditional support without need for Janino library (use JavaScript) Key: LOGBACK-1334 URL: https://jira.qos.ch/browse/LOGBACK-1334 Project: logback Issue Type: New Feature Components: logback-classic, logback-core Reporter: Jan Engehausen Assignee: Logback dev list Priority: Minor Currently, conditional support (use of {{<if>}} in configuration) requires the inclusion of the Janino libraries. Certain security-sensitive industries do not allow such libraries present at runtime (see also LOGBACK-623). Proposal: Use alternative JavaScript evalutation of conditions. This removes the need for the additional Janino library. This should be an "opt-in" feature, e.g. activated by a switch on the {{<configuration>}} element. -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

Ready for JDK 9 ?
by Rory O'Donnell 08 Aug '17

08 Aug '17

Hi Ceki, Thank you very much for all your testing of JDK 9 during its development! Such contributions have significantly helped shape and improve JDK 9. Now that we have reached the JDK 9 Final Release Candidate phase [1] , I would like to ask if your project can be considered to be 'ready for JDK 9', or if there are any remaining show stopper issues which you've encountered when testing with the JDK 9 release candidate. JDK 9 b181 is available at http://jdk.java.net/9/ If you have a public web page, mailing list post, or even a tweet announcing you project's readiness for JDK 9, I'd love to add the URL to the upcoming JDK 9 readiness page on the Quality Outreach wiki. Looking forward to hearing from you, Rory [1] http://openjdk.java.net/projects/jdk9/ -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland

1 0

Re: [logback-dev] [JIRA] (LOGBACK-1333) Snapshot version typo: SNAPSHPOT
by Richard Sand 05 Aug '17

05 Aug '17

I reported that too in LOGBACK-1307 :-) Ceki if you're interested I'd volunteer some time to help with 1.3.0... -Richard ------ Original Message ------ From: "QOS.CH (JIRA)" <noreply-jira(a)qos.ch> To: logback-dev(a)qos.ch Sent: 8/5/2017 1:23:00 PM Subject: [logback-dev] [JIRA] (LOGBACK-1333) Snapshot version typo: SNAPSHPOT >Jan Engehausen created LOGBACK-1333: >--------------------------------------- > > Summary: Snapshot version typo: SNAPSHPOT > Key: LOGBACK-1333 > URL: https://jira.qos.ch/browse/LOGBACK-1333 > Project: logback > Issue Type: Bug > Components: logback-core > Environment: Hello, the current master has several {{pom.xml}} >files with {{1.3.0-SNAPSHPOT}} - that of course should be >{{1.3.0-SNAPSHOT}} ;) > Reporter: Jan Engehausen > Assignee: Logback dev list > Priority: Trivial > > > > > > >-- >This message was sent by Atlassian JIRA >(v7.3.1#73012) >_______________________________________________ >logback-dev mailing list >logback-dev(a)qos.ch >http://mailman.qos.ch/mailman/listinfo/logback-dev --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

Logger arguments braces
by Martin Grajcar 05 Aug '17

05 Aug '17

I find the behavior of logger.whatever(format, ....) rather confusing. 1. What bothers me most: Forgetting a brace means that an argument gets ignored, which may mean waiting one more week till something like logger.error("Rare problem: {}, problem, details) fires again. A simple fix would be to follow Guava's implementation like in https://github.com/google/guava/blob/master/guava/src/ com/google/common/base/Preconditions.java#L154 which says "Unmatched arguments will be appended to the formatted message in square braces". This is a simple fix and the behavior gets changed only in case of a user error. I'd gladly contribute the fix. 2. A strange thing is that an exception needs no braces. So logger.info("Foo {} bar {}", o1, o2) leaves {} behind if o2 happens to be an exception. This is no big deal, but it's undocumented. My logfiles are full of braces as it took me a while till I found it out.

1 0

[JIRA] (LOGBACK-554) improve RollingCalendar and TimeBasedFileNamingAndTriggeringPolicyBase to enable periodic loggic
by QOS.CH (JIRA) 03 Aug '17

03 Aug '17

1 0

[JIRA] (LOGBACK-1332) Missing v1.1.11 download link
by QOS.CH (JIRA) 02 Aug '17

02 Aug '17

1 0

[JIRA] (LOGBACK-1332) Missing v1.1.11 download link
by QOS.CH (JIRA) 02 Aug '17

02 Aug '17

1 0