Peter Vlugter (JIRA | 19 Nov 04:13 2014
Picon

[JIRA] (LOGBACK-142) Logback Context is not thread safe, throws java.util.ConcurrentModificationException

Peter Vlugter commented on LOGBACK-142

I'm seeing a similar ConcurrentModificationException but in a different hash map (one in ContextBase).

Is configuration expected to be thread-safe? Should I create a new issue?

The calling code is here: https://github.com/playframework/playframework/blob/2.3.6/framework/src/play/src/main/scala/play/api/Logger.scala#L256

Example stack trace:

java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:922) at java.util.HashMap$EntryIterator.next(HashMap.java:962) at java.util.HashMap$EntryIterator.next(HashMap.java:960) at java.util.HashMap.putAllForCreate(HashMap.java:554) at java.util.HashMap.<init>(HashMap.java:298) at ch.qos.logback.core.ContextBase.getCopyOfPropertyMap(ContextBase.java:68) at ch.qos.logback.classic.spi.LoggerContextVO.<init>(LoggerContextVO.java:46) at ch.qos.logback.classic.LoggerContext.updateLoggerContextVO(LoggerContext.java:86) at ch.qos.logback.classic.LoggerContext.putProperty(LoggerContext.java:92) at ch.qos.logback.core.util.ContextUtil.addHostNameAsProperty(ContextUtil.java:75) at ch.qos.logback.classic.joran.action.ConfigurationAction.begin(ConfigurationAction.java:57) at ch.qos.logback.core.joran.spi.Interpreter.callBeginAction(Interpreter.java:275) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:147) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:129) at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:50) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:149) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:135) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:99) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:49)
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Deanna Delapasse (JIRA | 18 Nov 19:40 2014
Picon

[JIRA] (LOGBACK-747) maxHistory doesnot normally work in SizeAndTimeBasedFNATP

I'm experiencing this same issue. <maxHistory> doesn't seem to be noticed at all. This feature seems to have been reported many many times and occasionally marked as fixed, but it's definitely broken!

<appender name="ROLLING" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>c:/temp/logs/logback_dld.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<maxHistory>2</maxHistory>
<fileNamePattern>c:/temp/logs/logback_dld-%d

{yyyy-MM-dd}

.%i.log</fileNamePattern>
<timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
<maxFileSize>20MB</maxFileSize>
</timeBasedFileNamingAndTriggeringPolicy>
</rollingPolicy>

<encoder>
<!--pattern>%date %level [$thread] %logger

{10}

[%file:%line] %msg%n</pattern-->
<pattern>%d

{YYYY-MM-dd HH:mm:ss.SSS}

[%thread] %-5level %logger

{36}

- %msg%n</pattern>
</encoder>
</appender>

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Ralf Wiebicke (JIRA | 18 Nov 18:22 2014
Picon

[JIRA] (LOGBACK-1032) SMTP Appender mixes up mails

Issue Type: Bug
Affects Versions: 1.1.2
Assignee: Logback dev list
Attachments: logback.xml
Components: logback-core
Created: 18/Nov/14 6:21 PM
Description:

I do issue 10 error message using this code:

final Logger log = LoggerFactory.getLogger("myLogger");
for(int i = 0; i<10; i++)
log.error("myMessage" + i);

I configured logback.xml (attached) to write to console and to send emails. Console says:

17:56:21.172 [http-bio-8443-exec-1] ERROR myLogger - myMessage0
17:56:21.174 [http-bio-8443-exec-1] ERROR myLogger - myMessage1
17:56:21.174 [http-bio-8443-exec-1] ERROR myLogger - myMessage2
17:56:21.174 [http-bio-8443-exec-1] ERROR myLogger - myMessage3
17:56:21.174 [http-bio-8443-exec-1] ERROR myLogger - myMessage4
17:56:21.174 [http-bio-8443-exec-1] ERROR myLogger - myMessage5
17:56:21.174 [http-bio-8443-exec-1] ERROR myLogger - myMessage6
17:56:21.174 [http-bio-8443-exec-1] ERROR myLogger - myMessage7
17:56:21.175 [http-bio-8443-exec-1] ERROR myLogger - myMessage8
17:56:21.175 [http-bio-8443-exec-1] ERROR myLogger - myMessage9

which is perfect.
Also ch.qos.logback.classic.ViewStatusMessagesServlet shows my emails with 10 rows saying

INFO | SMTPAppender | About to send out SMTP message "ERROR myLogger myMessageNNN" to [xxx-JY/383W3OFBBDgjK7y7TUQ@public.gmane.org]

with N in 0 to 9, but the order of emails is shuffled to 7-0-9-2-8-1-4-3-5-6, which is still ok.

But unfortunatly, in my email account I find 10 equal emails, all with subject "ERROR myLogger myMessage8" and body

-----------------
ERROR myLogger

myMessage6
-----------------

So instead of sending 10 emails, one of them is sent 10 times. Even worse, subject and body of that email do not correspond to each other.

All 10 emails do have exactly the same Message-ID.

I tried this with logback 1.1.2, 1.1.1, and 1.1.0 (fetched from mvnrepository) and it always shows the same behaviour.

I tried it with two different smtp servers of my employer, and I did access both via Thunderbird and SquirrelMail, but this makes no difference.

If I do a "Thread.sleep(1000)" before each log.error, everything works as expected.

Environment:

Linux 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
java version "1.7.0_65"
OpenJDK Runtime Environment (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu0.14.04.1)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

Project: logback
Priority: Major
Reporter: Ralf Wiebicke
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
sinonim | 18 Nov 14:16 2014
Picon

MDC logging in logback-access - implementation enquiry

Hi,

We are currently using the logstash-logback-encoder project to send logging
events to logstash. Fact is that we also need to send some details which are
put into MDC. The current AccessEvent implementation does not support this.
(there is also a ticket similar to this at
http://jira.qos.ch/browse/LOGBACK-1016)

We are interested to submit an implementation for this feature, which can be
done in the following ways:
1. modify IAccessEvent to include getMDCPropertyMap() just like
ILoggingEvent
2. create a new interface IMDCAwareAccessEvent to extend IAccessEvent and
add MDC functionality there and then make AccessEvent implement 
IMDCAwareAccessEvent instead of  IAccessEvent

What are the chances for any of these 2 proposed implementations to be
approved?

Thank you.

--
View this message in context: http://logback.10977.n7.nabble.com/MDC-logging-in-logback-access-implementation-enquiry-tp13913.html
Sent from the Developer mailing list archive at Nabble.com.
Rahul (JIRA | 18 Nov 11:22 2014
Picon

[JIRA] (LOGBACK-711) Add "url" attribute to <property /> configuation

Rahul commented on LOGBACK-711

Hi
Any update on this one , is this issue resolved or is there any other way to load resource from a configured path.
please update, thanks

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Picon

[JIRA] (LOGBACK-1031) Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: java.lang.NullPointerException

I have seen that its because of not having a null check in the following code

private Node T() throws ScanException { Token t = peekAtCurentToken(); //The t is null here switch (t.type) {

in the

ch.qos.logback.core.subst.Parser

class in the logback-core-1.1.1.jar file

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Picon

[JIRA] (LOGBACK-1031) Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: java.lang.NullPointerException

Issue Type: Bug
Assignee: Logback dev list
Created: 17/Nov/14 2:30 PM
Description:

Failed to instantiate [ch.qos.logback.classic.LoggerContext]
Reported exception:
java.lang.NullPointerException
at ch.qos.logback.core.subst.Parser.T(Parser.java:75)
at ch.qos.logback.core.subst.Parser.E(Parser.java:50)
at ch.qos.logback.core.subst.Parser.parse(Parser.java:46)
at ch.qos.logback.core.subst.NodeToStringTransformer.tokenizeAndParseString(NodeToStringTransformer.java:55)
at ch.qos.logback.core.subst.NodeToStringTransformer.handleVariable(NodeToStringTransformer.java:96)
at ch.qos.logback.core.subst.NodeToStringTransformer.compileNode(NodeToStringTransformer.java:72)
at ch.qos.logback.core.subst.NodeToStringTransformer.transform(NodeToStringTransformer.java:60)
at ch.qos.logback.core.subst.NodeToStringTransformer.substituteVariable(NodeToStringTransformer.java:48)
at ch.qos.logback.core.util.OptionHelper.substVars(OptionHelper.java:117)
at ch.qos.logback.core.joran.spi.InterpretationContext.subst(InterpretationContext.java:159)
at ch.qos.logback.core.joran.action.NestedBasicPropertyIA.body(NestedBasicPropertyIA.java:87)
at ch.qos.logback.core.joran.spi.Interpreter.callBodyAction(Interpreter.java:295)
at ch.qos.logback.core.joran.spi.Interpreter.characters(Interpreter.java:175)
at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:57)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:149)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:135)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:99)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:49)
at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:75)
at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:150)
at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:85)
at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55)
at org.slf4j.LoggerFactory.bind(LoggerFactory.java:128)
at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:107)
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:295)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:269)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:281)

Project: logback
Priority: Major
Reporter: VENKATESWARA RAO PATELLA
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Arnaud Gourlay (JIRA | 13 Nov 11:56 2014
Picon

[JIRA] (LOGBACK-978) Configuration variable & literal parsing errors

I have also encountered this bug when having a logger name ending with '$'.
This bug appears from version 1.0.7 on.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Nicolás Hertzulis (JIRA | 12 Nov 19:16 2014
Picon

[JIRA] (LOGBACK-1030) ConsoleAppender forces AsyncAppender's includeCallerData property to true

Issue Type: Bug
Affects Versions: 1.1.2
Assignee: Logback dev list
Components: logback-classic, logback-core
Created: 12/Nov/14 7:16 PM
Description:

By configuring an application with both an AsyncAppender and a ConsoleAppender, the includeCallerData property of AsyncAppender will always be true, no mather if it's omitted or explicitly set to false.

This problem came to my attention after implementing the AsyncAppender in production. I had forgotten to set includeCallerData to true and hence the application was logging question marks . When I implemented the AsyncAppender in a testing environment along with the ConsoleAppender before setting includeCallerData to true, the question marks were replaced correctly.

Example configuration:

<?xml version="1.0" encoding="UTF-8"?> <configuration scan="true"> <appender name="Console" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%d %-4p [%X{uow}-%X{requestId}] [%t] [%X{group}] (%F:%L\) : %msg%n</pattern> </encoder> </appender> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>/tmp/app.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <!-- daily rollover --> <fileNamePattern>notifier.%d{yyyy-MM-dd}.log</fileNamePattern> <!-- keep 30 days' worth of history --> <maxHistory>10</maxHistory> </rollingPolicy> <encoder> <pattern>%d %-4p [%X{uow}-%X{requestId}] [%t] [%X{group}] (%F:%L\) : %msg%n</pattern> </encoder> </appender> <appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender"> <appender-ref ref="FILE" /> <includeCallerData>false</includeCallerData> </appender> <root level="INFO"> <appender-ref ref="Console" /> <appender-ref ref="ASYNC" /> </root> </configuration>
Project: logback
Priority: Minor
Reporter: Nicolás Hertzulis
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Claudio Bley (JIRA | 10 Nov 14:23 2014
Picon

[JIRA] (LOGBACK-1029) confusing warning generated for ConsoleAppender target

Issue Type: Improvement
Affects Versions: 1.1.2
Assignee: Logback dev list
Components: logback-core
Created: 10/Nov/14 2:23 PM
Description:

Really just a minor thing, but quite confusing:

Having this appender defined in my logback.groovy:

appender("CONSOLE", ConsoleAppender)

{ target = 'SystemErr' ... }

I got this warning from logback:

Main: 13:44:44,338 + WARN in ch.qos.logback.core.ConsoleAppender[CONSOLE] - [SystemErr] should be one of [SystemOut, SystemErr]
Main: 13:44:44,338 |-WARN in ch.qos.logback.core.ConsoleAppender[CONSOLE] - Using previously set target, System.out by default.

Well, looking at that warning I could not see what I had done wrong.

Would be nice if that warning can be fixed to print the actual two possible options.

Project: logback
Labels: consoleoutput
Priority: Trivial
Reporter: Claudio Bley
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Vyacheslav Blinov (JIRA | 7 Nov 14:22 2014
Picon

[JIRA] (LOGBACK-1028) Date formatter always uses default locale

Issue Type: Bug
Assignee: Logback dev list
Created: 07/Nov/14 2:20 PM
Description:

Hi,

I'm using logback to collect logs of application running on end user machines. The logs have a date in it's pattern. The problem I'm having is that timestamps from arabic machines are for example looks like ١٦:٤٧:٠٤.٠٣٢
While I can use Google translate to translate them to english it is still not the best way to do it. Looking at the sources and docs of logback I didn't found any way of supplying custom locale for date, and from source code it looks like that date formatter is instantiated using default constructor which implicitly uses current default locale (which happens to be arabic on arabic machines et cetera).

Please provide a way to choose locale for dates printed into logs explicitly.

Project: logback
Priority: Major
Reporter: Vyacheslav Blinov
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev

Gmane