- 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.

- relevant test cases

- logback now uses slf4j version 1.5.6
- ContextJNDISelector was refactored. The config file name for a new logger context is based on convention "logback-CONTEXTNAME.xml" 
  This obviates the need to set the "logback/configuration-resource" JNDI env-entry.

With each call to getLogger() method, LoggerContext will now retrieve the ILoggerFactory afresh from StaticLoggerBinder. 
This change enables context selectors of native implementations, e.g logback, to work correctly. 

  logback can succeed even in presence of recursive calls
  to LoggerFactory.getLogger (invoked during the initialization of
  logback). See also http://bugzilla.slf4j.org/show_bug.cgi?id=106
  and http://jira.qos.ch/browse/LBCORE-47
  
  This test fails if SLF4J 1.5.5 is used.
  
  Related to http://bugzilla.slf4j.org/show_bug.cgi?id=113
  and http://jira.qos.ch/browse/LBCORE-51

 - Absorb thrown SecurityException/AccessControlException when accessing system properties
   This fixes LBCLASSIC-86

instances running on multiple JVMs can safely write to the same log file. With 
certain limitations, prudent mode extends to RollingFileAppender. 

  from multiple JVM on different hosts

Experimental support for multiple JVM's writing to the same file

Experimental support for multiple JVM's writing to the same file

having special meaning, and will return the simple class name,
removing the package name prefix. This feature was asked by
Silvano Maffeis.
    

some components needed to survive resetting of the context. 

For example, when the JMXConfigrator.reload*() methods are invoked, if
the JMXConfigurator instance is unregistered from the MBeans server
while the reload*() method is still running, then a
NullPointerException is thrown from the JMX server. Thus,
JMXConfigurator needs to survive the resetting of the LoggerContext it
is attached to. However, when the host application is stopped (or
restarted), the JMXConfigrator needs to be unregistered from the
MBeans server, otherwise severe memory leaks occur.

Consequently, LoggerContext now offers two related but distinct
methods, reset() and stop(). The former should be called if you just
wish to reset the configuration of the logger context. The former
should be called when you wish to completely stop the LoggerContext so
that it can not be reused ever again.

The LoggerContext.shutdownAndReset method no longer exists. (Simply
deprecating in favor of stop() or reset() seemed too error prone.)

renmaed site.css as screen.css

  Consequently, renaming print.css as sitePrint.css.
- updating references