- logback-access tests are now all JUnit4

  instead of a generic K. This simplifies the code without real loss
  of generality. :-) 

- Finished renaming HoardingAppender as SiftingAppender (as well as associated classes)

No commit message

- BasicStatusMessages's internal buffer now has two parts, the head part and the tail part.

- Initial commit of HoardingAppender

HoardingAppender contains other appenders which it can build
dynamically depending on MDC values. The built appender is specified
as part of a configuration file. Here is an example.

<configuration debug="true">
  <appender name="HOARD"  class="ch.qos.logback.classic.hoard.HoardingAppender">
    <mdcKey>userid</mdcKey>
    <hoard>
      <!-- you can put any appender here -->
      <appender name="file-${userid}" class="ch.qos.logback.core.FileAppender">
        <File>${userid}.log</File>
        <Append>true</Append>
        <layout class="ch.qos.logback.classic.PatternLayout">
          <Pattern>%d [%thread] %level %logger{35} - %msg%n</Pattern>
        </layout>
      </appender>
    </hoard>
  </appender>
  <root level="DEBUG">
    <appender-ref ref="HOARD" />
  </root>
</configuration>

A new file appender will be built each according to the MDC value
associated with the key "userid" when a logging event occurs. The
above configuration file will ventilate logging into log files named
after the userid. 

- Added PropertyContainer interface
- Context interface now extends PropertyContainer
- InterpretationContext implements PropertyContainer
  It now has a field called propertiesMap which has precedence
  over values placed in the context
- InterpretationContext.getSubstitutionProperty was renamed as
  getProperty
- It is now possible to initialize a joran Interpreter with an initial
  (not empty) pattern

This is still very much ongoing work.
  

Fix LBCORE-78. 

AsynchronousCompressor shuts down the executor it created, thus avoiding a memory leak.

- cosmetic changes in Context

Removed 'synchronized' keyword from the incSize() and size() methods. 
Synchronization was causing a deadlock described in LBCLASSIC-81
These two methods are used internally by logback for testing purposes.

The getEffectiveLevel() method needs to be synchronized to protect
against concurrent modification when iterating over
childrenList.iterator().

  the collection returned by Collections.synchronizedList()

- preparing release 0.9.13
- minor doc changes

An NPE would be thrown when setting the level of a logger to null, if the
logger in question had children.

- removed slf4j-ext declaration from the parent pom. In child modules the slf4j-ext was being inserted in compile scope instead
  of test scope.
- updated documentation in relation to contextName and insertFromJNDI configuration directives. 

- migrated some tests to JUnit4 format
-  other cosmetic changes

Fixes LBCLASSIC-90. Logger reset set logger levels to NULL, except for the root logger which gets set to DEBUG.

  See also LBCLASSIC-43
- cosmetic changes

Added an FAQ entry:

  Is it possible for multiple JEE applications to share the same 
  configuration file but without stepping on each other's toes?


Related to LBCLASSIC-42

- converted all tests in logback-core to JUnit 4

I prefer
  try {
    r.lock();
    doSomething();
  } finally  {
    r.unlock();
  }
  
instead of 

  r.lock();
  try {
    doSomething();  
  } finally  {
    r.unlock();
  }

  because I think that the lock is held for a shorter time (however small it may be).
  In case r.lock() throws an exception, we are probably screwed in both approaches.