- 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 

- moved jmxConfig.html under manual/jmxConfig.html
- updated chapter on JMX support
- updated news.html
- other minor changes in documentation

mbean of different web-application. This feature was requested in LBCLASSIC-61.

If you have two web-apps, minimal and minimal other, the logback.xml config files
relative to jmxConfigurator would look like:

<configuration>
  <jmxConfigurator suffix="Webapp=minimal" />
  ...
</configuration>

for the "minimal" web-app, and

<configuration>
  <jmxConfigurator suffix="Webapp=minimalOther" />
  ...
</configuration>

for the other web-app.

You can choose other values for the suffix contents if you wish. For
example,

  <jmxConfigurator suffix="Fruit=banana" />

is perfectly valid.

To help with garbage collection, JMXConfigurator now will clear most if
its internal fields. This is not strictly necessary but still helps with GC. 

Refactoring test cases in relation to LBCLASSIC-83.

 LBCLASSIC-83 (Logger.setLevel(null) may throw an NPE)

 LBCLASSIC-61 (configurable ObjectName)
 LBCLASSIC-24 (better error messages after reload)
 LBCLASSIC-33 (JMX configurator unregisters itself)
 LBCLASSIC-78 (NPE in JMXConfigurator getLoggerLevel)
 LBCLASSIC-79 (NPE in JMXConfigurator setLoggerLevel)
 

While testing LBCLASSIC 61,24 and 33, I wanted to correct LBCLASSIC-78
and LBCLASSIC-79 which are related to JMXConfigurator. It turns out
that LBCLASSIC-79 has a much deeper cause identified in LBCLASSIC-83.

Work on LBCLASSIC 61,24 and 33 is still ongoing. The present commit
reflects the nature of that ongoing and incomplete work.

This commit is related to:

 LBCLASSIC-61 (configurable ObjectName)
 LBCLASSIC-24 (better error messages after reload)
 LBCLASSIC-33 (JMX configurator unregisters itself)

- Refactoring of LoggerContext class so it has a cleaner lifecycle
- Major refactorization of c.q.l.c.jmx.Configurator (renamed as JMXConfigurator) in order
  to fix the aforementioned bugs
  
  More updates to follow

run on older JDKs we make JDK 1.6 a requirement for running the DBAppenderIntegration tests.

run on older JDKs we make JDK 1.6 a requirement for running the DBAppenderIntegration tests. 

We now use sqljdbc4. (note the suffix 4)

loop len of 10'000 is already pretty long

Related to LBCLASSIC-54

Mopping up refactoring of turbo filters

 	 
- Heavy refactoring of TurboFilters 
  TurboFilters are now collected in a CopyOnWriteArrayList which is
  ensures safe access even if the turbo filter list is modified during
  the lifetime of the application
  
  Added test cases to ensure that performance does not degrade in an
  uncontrolled fashion
  
  More cleaning up to follow