March 2016 - logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1152) dead links on download page
by Sylvain Delafoy (JIRA) 14 Mar '16

14 Mar '16

1 0

[qos-ch/logback] 151857: decommissioned ReconfigureOnChangeFilter and repla...
by Ceki Gulcu 11 Mar '16

11 Mar '16

Branch: refs/heads/master Home: https://github.com/qos-ch/logback Commit: 151857344eaefda8f641d93ac23e9e2c1be2b723 https://github.com/qos-ch/logback/commit/151857344eaefda8f641d93ac23e9e2c1b… Author: Ceki Gulcu <ceki(a)qos.ch> Date: 2016-03-11 (Fri, 11 Mar 2016) Changed paths: M logback-access/src/main/java/ch/qos/logback/access/tomcat/LogbackValve.java M logback-classic/src/main/groovy/ch/qos/logback/classic/gaffer/ConfigurationDelegate.groovy M logback-classic/src/main/java/ch/qos/logback/classic/LoggerContext.java A logback-classic/src/main/java/ch/qos/logback/classic/joran/ReconfigureOnChangeTask.java A logback-classic/src/main/java/ch/qos/logback/classic/joran/ReconfigureOnChangeTaskListener.java M logback-classic/src/main/java/ch/qos/logback/classic/joran/action/ConfigurationAction.java M logback-classic/src/main/java/ch/qos/logback/classic/net/SocketReceiver.java M logback-classic/src/main/java/ch/qos/logback/classic/turbo/ReconfigureOnChangeFilter.java M logback-classic/src/test/groovy/ch/qos/logback/classic/gaffer/ConfigurationDelegateTest.groovy A logback-classic/src/test/input/joran/roct/inclusion/inner0.xml A logback-classic/src/test/input/joran/roct/inclusion/topByResource.xml A logback-classic/src/test/input/joran/roct/inclusion/topLevel0.xml A logback-classic/src/test/input/joran/roct/scan 1.groovy A logback-classic/src/test/input/joran/roct/scan 1.xml A logback-classic/src/test/input/joran/roct/scan_logback_474.xml A logback-classic/src/test/input/joran/roct/scan_perf.xml R logback-classic/src/test/input/turbo/inclusion/inner0.xml R logback-classic/src/test/input/turbo/inclusion/topByResource.xml R logback-classic/src/test/input/turbo/inclusion/topLevel0.xml R logback-classic/src/test/input/turbo/scan 1.groovy R logback-classic/src/test/input/turbo/scan 1.xml R logback-classic/src/test/input/turbo/scan_logback_474.xml R logback-classic/src/test/input/turbo/scan_perf.xml M logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic135/LoggingRunnable.java A logback-classic/src/test/java/ch/qos/logback/classic/joran/ReconfigureOnChangeTaskTest.java M logback-classic/src/test/java/ch/qos/logback/classic/turbo/ReconfigureOnChangeTest.java M logback-core/src/main/java/ch/qos/logback/core/Context.java M logback-core/src/main/java/ch/qos/logback/core/ContextBase.java M logback-core/src/main/java/ch/qos/logback/core/CoreConstants.java M logback-core/src/main/java/ch/qos/logback/core/joran/GenericConfigurator.java M logback-core/src/main/java/ch/qos/logback/core/joran/action/IncludeAction.java M logback-core/src/main/java/ch/qos/logback/core/joran/event/SaxEventRecorder.java M logback-core/src/main/java/ch/qos/logback/core/joran/event/StartEvent.java M logback-core/src/main/java/ch/qos/logback/core/joran/spi/ConfigurationWatchList.java M logback-core/src/main/java/ch/qos/logback/core/joran/util/ConfigurationWatchListUtil.java M logback-core/src/main/java/ch/qos/logback/core/joran/util/PropertySetter.java M logback-core/src/main/java/ch/qos/logback/core/rolling/SizeAndTimeBasedFNATP.java M logback-core/src/main/java/ch/qos/logback/core/rolling/SizeBasedTriggeringPolicy.java M logback-core/src/main/java/ch/qos/logback/core/status/StatusUtil.java A logback-core/src/main/java/ch/qos/logback/core/util/DefaultInvocationGate.java M logback-core/src/main/java/ch/qos/logback/core/util/ExecutorServiceUtil.java M logback-core/src/main/java/ch/qos/logback/core/util/InvocationGate.java M logback-core/src/test/java/ch/qos/logback/core/contention/AbstractMultiThreadedHarness.java M logback-core/src/test/java/ch/qos/logback/core/contention/MultiThreadedHarness.java M logback-core/src/test/java/ch/qos/logback/core/contention/WaitOnExecutionMultiThreadedHarness.java M logback-core/src/test/java/ch/qos/logback/core/issue/LOGBACK_849/Basic.java M logback-core/src/test/java/ch/qos/logback/core/joran/TrivialConfiguratorTest.java M logback-core/src/test/java/ch/qos/logback/core/joran/action/IncludeActionTest.java M logback-core/src/test/java/ch/qos/logback/core/rolling/SizeAndTimeBasedFNATP_Test.java M logback-core/src/test/java/ch/qos/logback/core/rolling/TimeBasedRollingWithArchiveRemoval_Test.java Log Message: ----------- decommissioned ReconfigureOnChangeFilter and replaced it with ReconfigureOnChangeTask, added ScheduledExecutorService to Context

1 0

[JIRA] (LOGBACK-1071) Java 8 compact3 profile compatibility
by max urech (JIRA) 11 Mar '16

11 Mar '16

1 0

[JIRA] (LOGBACK-1151) IncludeAction reads included file even in fall mode
by Ceki Gulcu (JIRA) 10 Mar '16

10 Mar '16

1 0

Question: AsyncAppender's thread safety?
by Aaron Curley 07 Mar '16

07 Mar '16

Hello all, I’m most likely missing something here, but reviewing AsyncAppender in logback classic 1.1.6, I’m not sure how it’s entirely thread safe, especially with respect to the “started” flag in its grandparent class (UnsynchronizedAppenderBase). In particular, the doAppend() method in UnsynchronizedAppenderBase checks the “started” boolean member's value (line 72) before actually appending, yet, no synchronization primitives are (or appear to be, from my perspective) used to ensure that the “started” member is visible to all threads once it is updated via start(). I would have thought that AsyncAppender would have inherited from AppenderBase (which is thread safe and does mark “started” as volatile) rather than extending UnsynchronizedAppenderBase. Baring this, I would have thought that the “started” member would be “overridden” with AsyncAppender’s own volatile version of this flag or access to started would be protected with a lock. As a result, isn’t it possible that if one thread calls start() and then another thread immediately logs something (calling doAppend()), the logging thread would see “started” as false? Wouldn’t this result in “skipping” certain log messages entirely (if the appender was very recently started)? I think I must be missing something. Can someone clarify how this works? Thanks in advance! Best Regards, Aaron Curley accwebs(a)gmail.com P. S. I would have also expected start() and stop() (in AsyncAppender or its parent) to be overridden to introduce synchronization, since AsyncAppender is generally used by multiple threads. Right now, it appears that start & stop operations are not idempotent nor are multiple (simultaneous) calls prevented.

2 4

[JIRA] (LOGBACK-1148) AsyncAppender thread safety issues
by Aaron Curley (JIRA) 07 Mar '16

07 Mar '16

1 0

[JIRA] (LOGBACK-1149) IllegalArgumentException when using $ in logger name
by Stevo Slavic (JIRA) 04 Mar '16

04 Mar '16

1 0

[JIRA] (LOGBACK-1149) IllegalArgumentException when using $ in logger name
by Ceki Gulcu (JIRA) 04 Mar '16

04 Mar '16

1 0

[JIRA] (LOGBACK-1149) IllegalArgumentException when using $ in logger name
by Ceki Gulcu (JIRA) 04 Mar '16

04 Mar '16

1 0

[JIRA] (LOGBACK-1149) IllegalArgumentException when using $ in logger name
by Stevo Slavic (JIRA) 04 Mar '16

04 Mar '16

1 0