Merged branch 'jetty-9.3.x' into 'jetty-9.4.x'.

jetty-documentation/pom.xml

@@ -132,7 +132,8 @@
           <dependency>
             <groupId>net.sf.docbook</groupId>
             <artifactId>docbook-xml</artifactId>
-            <version>5.0-all</version>
+            <!--version>5.0-all</version-->
+            <version>5.1b4-all</version>
             <classifier>resources</classifier>
             <type>zip</type>
             <scope>runtime</scope>

jetty-documentation/src/main/asciidoc/administration/alpn/alpn.adoc

@@ -257,6 +257,7 @@ This section is for Jetty developers that need to update the ALPN implementation
 
 Clone the OpenJDK repository with the following command:
 
+[source, screen]
 ....
 $ hg clone http://hg.openjdk.java.net/jdk7u/jdk7u jdk7u # OpenJDK 7
 $ hg clone http://hg.openjdk.java.net/jdk8u/jdk8u jdk8u # OpenJDK 8
@@ -267,6 +268,7 @@ $ ./get_source.sh
 
 To update the source to a specific tag, use the following command:
 
+[source, screen]
 ....
 $ ./make/scripts/hgforest.sh update <tag-name>
   

jetty-documentation/src/main/asciidoc/administration/extras/rewrite-handler.adoc

@@ -29,6 +29,7 @@ The RewriteHandler matches a request against a set of rules, and modifies the re
 
 The standard Jetty distribution bundle contains the `jetty-rewrite` link:#startup-modules[module], so all you need to do is to enable it using one of the link:#start-jar[module commands], eg:
 
+[source, screen]
 ....
 
 $ java -jar start.jar --add-to-startd=rewrite

jetty-documentation/src/main/asciidoc/administration/extras/statistics-handler.adoc

@@ -95,6 +95,7 @@ Typically this can be done as the top level handler, but you may choose to confi
 Please note that `jetty-stats.xml` has to appear in the command line after the main Jetty configuration file as shown below. 
 It should be able to be uncommented in the start.ini file.
 
+[source, screen]
 ....
 $ java -jar start.jar OPTIONS=default etc/jetty.xml etc/jetty-stats.xml
     

jetty-documentation/src/main/asciidoc/administration/fastcgi/configuring-fastcgi.adoc

@@ -29,6 +29,7 @@ Refer to xref:jetty-downloading[] for more information about how to install Jett
 
 The fourth step is to create a Jetty base directory (see xref:startup-base-and-home[]), called in the following `$JETTY_BASE`, where you setup the configuration needed to support FastCGI in Jetty, and configure the `fcgi`, `http` and `deploy` modules, so that Jetty will be able to accept HTTP requests from browsers, convert them in FastCGI, and proxy them to `php-fpm`:
 
+[source, screen]
 ....
 $ mkdir -p /usr/jetty/wordpress
 $ cd /usr/jetty/wordpress
@@ -134,6 +135,7 @@ Refer to the link:{JDURL}/org/eclipse/jetty/fcgi/server/proxy/FastCGIProxyServle
 
 The last step is to start Jetty (see xref:startup[]) and hit `http://localhost:8080` with your browser and enjoy WordPress:
 
+[source, screen]
 ....
 $ cd $JETTY_BASE
 $ java -jar /opt/jetty/start.jar
@@ -147,6 +149,7 @@ In order to configure Jetty to listen for HTTP/2 requests from clients that are
 
 Enabling the `http2` is really simple; in additions to the modules you have enabled above, add the `http2` module:
 
+[source, screen]
 ....
 $ cd $JETTY_BASE
 $ java -jar $JETTY_HOME/start.jar --add-to-start=http2
@@ -167,6 +170,7 @@ These will setup a clear text connector on port 8080 for HTTP/1.1 and a TLS conn
 
 At this point, you can start Jetty (see xref:startup[]), hit `http://localhost:8080` with your browser and enjoy WordPress via HTTP/2 using a HTTP/2 enabled browser:
 
+[source, screen]
 ....
 $ cd $JETTY_BASE
 $ java -jar $JETTY_HOME/start.jar

jetty-documentation/src/main/asciidoc/administration/http2/enabling-http2.adoc

@@ -19,6 +19,7 @@
 
 This section is written assuming that a jetty base directory is being used and a demo jetty base that support HTTP/1, HTTPS/1 and deployment from a webapps directory can be created with the commands:
 
+[source, screen]
 ....
 $ JETTY_BASE=http2-demo
 $ mkdir $JETTY_BASE

jetty-documentation/src/main/asciidoc/administration/jmx/jetty-jconsole.adoc

@@ -29,6 +29,7 @@ To monitor Jetty's server status with JConsole, make sure JConsole is running, a
 
 The simplest way to enable support is to add the jmx support module to your $\{jetty.base}.
 
+[source, screen]
 ....
 [mybase]$ java /opt/jetty-dist/start.jar --add-to-start=jmx
 INFO: jmx-remote      initialised in ${jetty.base}/start.ini (appended)
@@ -60,6 +61,7 @@ The way to do this is to set your MAVEN_OPTS environment variable (if you're not
 
 Here is an example that sets the system property on the fly in a BASH shell, before starting Jetty via the plugin:
 
+[source, screen]
 ....
 
 $ export MAVEN_OPTS=-Dcom.sun.management.jmxremote

jetty-documentation/src/main/asciidoc/administration/logging/chapter.adoc

@@ -19,3 +19,13 @@
 
 This chapter discusses various options for configuring logging.
 
+include::configuring-jetty-logging.adoc[]
+include::default-logging-with-stderrlog.adoc[]
+include::configuring-jetty-request-logs.adoc[]
+include::example-apache-log4j.adoc[]
+include::example-java-util-logging.adoc[]
+include::example-java-util-logging-native.adoc[]
+include::example-logback.adoc[]
+include::example-slf4j-multiple-loggers.adoc[]
+include::example-logback-centralized-logging.adoc[]
+include::dump-tool.adoc[]

jetty-documentation/src/main/asciidoc/administration/logging/configuring-jetty-logging.adoc

@@ -15,16 +15,13 @@
 //  ========================================================================
 
 [[configuring-jetty-logging]]
-= Configuring Jetty Logging
+=== Configuring Jetty Logging
 
-Jetty provides logging via its own `org.eclipse.jetty.util.log.Logger`
+Jetty provides logging via its own `org.eclipse.jetty.util.log.Logger` layer, and does not natively use any existing Java logging framework.
-layer, and does not natively use any existing Java logging framework.
+All logging events, produced via the Jetty logging layer, have a name, a level, and a message.
-All logging events, produced via the Jetty logging layer, have a name, a
+The name is a FQCN (fully qualified class name) similar to how all existing Java logging frameworks operate.
-level, and a message. The name is a FQCN (fully qualified class name)
-similar to how all existing Java logging frameworks operate.
 
-Jetty logging, however, has a slightly different set of levels that it
+Jetty logging, however, has a slightly different set of levels that it uses internally:
-uses internally:
 
 WARN::
   For events serious enough to inform and log, but not fatal.
@@ -33,67 +30,43 @@ INFO::
 DEBUG::
   Debugging events (very noisy).
 IGNORE::
-  Exception events that you can safely ignore, but useful for some
+  Exception events that you can safely ignore, but useful for some people.
-  people. You might see this level as DEBUG under some Java logging
+  You might see this level as DEBUG under some Java logging framework configurations, where it retains the _ignore_ phrase somewhere in the logging.
-  framework configurations, where it retains the _ignore_ phrase
-  somewhere in the logging.
-
 ____
 [NOTE]
 Jetty logging produces no FATAL or SEVERE events.
 ____
 
 [[selecting-log-framework]]
-== Selecting the Log Framework
+==== Selecting the Log Framework
 
-Configure the Jetty logging layer via the
+Configure the Jetty logging layer via the `org.eclipse.jetty.util.log.Log` class, following link:{GITBROWSEURL}/jetty-util/src/main/java/org/eclipse/jetty/util/log/Log.java[these rules].
-`org.eclipse.jetty.util.log.Log` class, following
-link:{GITBROWSEURL}/jetty-util/src/main/java/org/eclipse/jetty/util/log/Log.java[these
-rules].
 
 1.  Load Properties
-* First from a Classpath Resource called `jetty-logging.properties` (if
+* First from a Classpath Resource called `jetty-logging.properties` (if found).
-found).
 * Then from the `System.getProperties()`.
 2.  Determine the log implementation.
-* If property `org.eclipse.jetty.util.log.class` is defined, load the
+* If property `org.eclipse.jetty.util.log.class` is defined, load the class it defines as the logger implementation from the server `classpath`.
-class it defines as the logger implementation from the server classpath.
+* If the class `org.slf4j.Logger` exists in server classpath, the Jetty implementation becomes `org.eclipse.jetty.util.log.Slf4jLog`.
-* If the class `org.slf4j.Logger` exists in server classpath, the Jetty
+* If no logger implementation is specified, default to `org.eclipse.jetty.util.log.StdErrLog`.
-implementation becomes `org.eclipse.jetty.util.log.Slf4jLog`.
-* If no logger implementation is specified, default to
-`org.eclipse.jetty.util.log.StdErrLog`.
-
 ____
 [NOTE]
-You can create your own custom logging by providing an implementation of
+You can create your own custom logging by providing an implementation of the link:{JDURL}org/eclipse/jetty/util/log/Logger.html[Jetty Logger API]. 
-the link:{JDURL}org/eclipse/jetty/util/log/Logger.html[Jetty Logger
+For an example of a custom logger, see link:{GITBROWSEURL}/jetty-util/src/main/java/org/eclipse/jetty/util/log/JavaUtilLog.java[JavaUtilLog.java].
-API]. For an example of a custom logger, see
-link:{GITBROWSEURL}/jetty-util/src/main/java/org/eclipse/jetty/util/log/JavaUtilLog.java[JavaUtilLog.java].
 ____
 
 [[configuring-jetty-stderrlog]]
-== The jetty-logging.properties file
+==== The jetty-logging.properties file
 
-By default, the internal Jetty Logging discovery mechanism will load
+By default, the internal Jetty Logging discovery mechanism will load logging specific properties from a classpath resource called `jetty-logging.properties` and then initialize the Logging from a combination of properties found in that file, along with any System Properties.
-logging specific properties from a classpath resource called
+A typical jetty-logging.properties file will include at least the declaration of which logging implementation you want to use by defining a value for the `org.eclipse.jetty.util.log.class` property.
-`jetty-logging.properties` and then initialize the Logging from a
+  
-combination of properties found in that file, along with any System
+Examples for various logging frameworks can be found later in this documentation.
-Properties.
 
-A typical jetty-logging.properties file will include at least the
+* Default Logging with link:#default-logging-with-stderrlog[Jetty's StdErrLog]
-declaration of which logging implementation you want to use by defining
-a value for the `org.eclipse.jetty.util.log.class` property.
-
-Examples for various logging frameworks can be found later in this
-documentation.
-
-* Default Logging with link:#default-logging-with-stderrlog[Jetty's
-StdErrLog]
 * Using link:#example-logging-log4j[Log4j via Slf4jLog]
 * Using link:#example-logging-logback[Logback via Slf4jLog]
 * Using java.util.logging via Slf4jLog
 * Using java.util.logging via Jetty's JavaUtilLog
-* Capturing link:#example-slf4j-multiple-loggers[Multiple Logging
+* Capturing link:#example-slf4j-multiple-loggers[Multiple Logging Frameworks via Slf4jLog]
-Frameworks via Slf4jLog]
+* link:#example-logging-logback-centralized[Centralized Logging with Logback and Sfl4jLog]
-* link:#example-logging-logback-centralized[Centralized Logging with
-Logback and Sfl4jLog]

jetty-documentation/src/main/asciidoc/administration/logging/configuring-jetty-request-logs.adoc

@@ -15,19 +15,15 @@
 //  ========================================================================
 
 [[configuring-jetty-request-logs]]
-= Configuring Jetty Request Logs
+=== Configuring Jetty Request Logs
 
 Request logs are a record of the requests that the server has processed.
-There is one entry per request received, and commonly in the standard
+There is one entry per request received, and commonly in the standard NCSA format, so you can use tools like http://en.wikipedia.org/wiki/Webalizer[Webalizer] to analyze them conveniently.
-NCSA format, so you can use tools like
-http://en.wikipedia.org/wiki/Webalizer[Webalizer] to analyze them
-conveniently.
 
 [[constructing-request-log-entry]]
-== Constructing a Request Log Entry
+==== Constructing a Request Log Entry
 
-A standard request log entry includes the client IP address, date,
+A standard request log entry includes the client IP address, date, method, URL, result, size, referrer, and user agent, for example:
-method, URL, result, size, referrer, and user agent, for example:
 
 ....
 123.4.5.6 - - [27/Aug/2004:10:16:17 +0000]
@@ -37,25 +33,16 @@ method, URL, result, size, referrer, and user agent, for example:
 ....
 
 [[implementing-request-log]]
-== Implementing a Request Log
+==== Implementing a Request Log
 
-Jetty provides an implementation called _`NCSARequestLog`_ which
+Jetty provides an implementation called _`NCSARequestLog`_ which supports the NCSA format in files that you can roll over on a daily basis.
-supports the NCSA format in files that you can roll over on a daily
-basis.
 
-The http://logback.qos.ch/[Logback Project] offers
+The http://logback.qos.ch/[Logback Project] offers http://logback.qos.ch/access.html[another implementation] of a `RequestLog` interface, providing rich and powerful HTTP-access log functionality.
-http://logback.qos.ch/access.html[another implementation] of a
-RequestLog interface, providing rich and powerful HTTP-access log
-functionality.
 
-If neither of these options meets your needs, you can implement a custom
+If neither of these options meets your needs, you can implement a custom request logger by implementing Jetty's link:{JDURL}/org/eclipse/jetty/server/RequestLog.html[`RequestLog.java`] interface and plugging it in similar to the `NCSARequestLog`, as shown below.
-request logger by implementing Jetty's
-link:{JDURL}/org/eclipse/jetty/server/RequestLog.html[`RequestLog.java`]
-interface and plugging it in similar to the NCSARequestLog, as shown
-below.
 
 [[configuring-request-log]]
-== Configuring a Request Log
+==== Configuring a Request Log
 
 To configure a single request log for the entire Jetty Server instance:
 
@@ -85,19 +72,16 @@ requestLog.setLogTimeZone("GMT");
 server.setRequestLog(requestLog);
 ----
 
-This configures a request log in `$JETTY_HOME/logs` with filenames
+This configures a request log in `$JETTY_HOME/logs` with filenames including the date. 
-including the date. Old log files are kept for 90 days before being
+Old log files are kept for 90 days before being deleted. 
-deleted. Existing log files are appended to and the extended NCSA format
+Existing log files are appended to and the extended NCSA format is used in the GMT time zone.
-is used in the GMT timezone.
 
-To examine many more configuration options, see
+To examine many more configuration options, see link:{JDURL}/org/eclipse/jetty/server/NCSARequestLog.html[NCSARequestLog.java].
-link:{JDURL}/org/eclipse/jetty/server/NCSARequestLog.html[NCSARequestLog.java]
 
 [[configuring-separate-request-log-for-web-application]]
-== Configuring a Separate Request Log For a Web Application
+==== Configuring a Separate Request Log For a Web Application
 
-To configure a separate request log for a web application, add the
+To configure a separate request log for a web application, add the following to the context XML file.
-following to the context XML file.
 
 [source,xml]
 ----

jetty-documentation/src/main/asciidoc/administration/logging/default-logging-with-stderrlog.adoc

@@ -15,45 +15,37 @@
 //  ========================================================================
 
 [[default-logging-with-stderrlog]]
-= Default Logging with Jetty's StdErrLog
+=== Default Logging with Jetty's StdErrLog
 
-If you do nothing to configure your own logging framework, then Jetty
+[[stderrlog-configuration]]
-will default to using an internal `org.eclipse.jetty.util.log.StdErrLog`
+==== StdErrLog Configuration
-implementation. This will output all logging events to STDERR (aka
-System.err).
 
-Simply use Jetty and you get StdErrLog based logging output.
+If you do nothing to configure a separate logging framework, Jetty will default to using an internal `org.eclipse.jetty.util.log.StdErrLog` implementation. 
+This will output all logging events to STDERR (aka `System.err`).
 
-Included in the Jetty distribution is a logging module that is capable
+Simply use Jetty and `StdErrLog` based logging is output.
-of performing simple capturing of all STDOUT and STDERR output to a file
-that is rotated daily.
 
-To enable on the command line:
+Included in the Jetty distribution is a logging module that is capable of performing simple capturing of all STDOUT and STDERR output to a file that is rotated daily.
+
+To enable on this feature via the command line:
 
 [source,bash]
 ----
 [my-base]$ java -jar /opt/jetty/start.jar --module=logging
 ----
 
-You can also include the `--module=logging` command in your
+You can also include the `--module=logging` command in your `${jetty.base}/start.ini`.
-`${jetty.base}/start.ini`
 
 [source,bash]
 ----
 [my-base]$ java -jar /opt/jetty/start.jar --add-to-start=logging
 ----
 
-The default configuration for logging output will create a file
+The default configuration for logging output will create a file `${jetty.logs}/yyyy_mm_dd.stderrout.log` which allows configuration of the output directory by setting the `jetty.logs` property.
-`${jetty.logs}/yyyy_mm_dd.stderrout.log` which allows you to configure
-the output directory by setting the `jetty.logs` property to a path of
-your choice.
 
-If you want a more advanced configuration of your logging output,
+For more advanced logging configurations, please consider use of a separate logging library.
-consider using your logging library of choice.
 
-The recommended way to configure StdErrLog is to create a
+The recommended way to configure `StdErrLog` is to create a `${jetty.home}/resources/jetty-logging.properties` file, specify the log implementation to `StdErrLog` and then setup logging levels.
-`${jetty.home}/resources/jetty-logging.properties` file, specify the Log
-implementation to StdErrLog and then setup your logging levels.
 
 [source,properties]
 ----
@@ -65,46 +57,34 @@ org.eclipse.jetty.LEVEL=INFO
 org.eclipse.jetty.websocket.LEVEL=DEBUG
 ----
 
-There are a number of properties you can define in here that will affect
+There are a number of properties that can be defined in the configuration that will affect the behavior of `StdErrLog`.
-the StdErrLog behavior.
 
 `<name>.LEVEL=<level>`::
-  Sets the logging level for all loggers within the `name` specified to
+  Sets the logging level for all loggers within the `name` specified to the level, which can be (in increasing order of restriction) `ALL`, `DEBUG`, `INFO`, `WARN`, `OFF`. 
-  the level, which can be (in increasing order of restriction) `ALL`,
+  The name (or hierarchy) can be a specific fully qualified class or a package namespace.
-  `DEBUG`, `INFO`, `WARN`, `OFF`. The name (or hierarchy) can be a
+  For example, `org.eclipse.jetty.http.LEVEL=DEBUG` is a package namespace approach to turn all loggers in the Jetty HTTP package to DEBUG level, and  `org.eclipse.jetty.io.ChanelEndPoint.LEVEL=ALL` turns on all logging events for the specific class, including `DEBUG`, `INFO`, `WARN` (and even special internally ignored exception classes). 
-  specific fully qualified class or a package namespace, for example,
+  If more than one system property specifies a logging level, the most specific one applies.
-  `org.eclipse.jetty.http.LEVEL=DEBUG` is a package namespace approach
-  to turn all loggers in the Jetty HTTP package to DEBUG level, and
-  `org.eclipse.jetty.io.ChanelEndPoint.LEVEL=ALL` turns on all logging
-  events for the specific class, including `DEBUG`, `INFO`, `WARN` (and
-  even special internally ignored exception classes). If more than one
-  system property specifies a logging level, the most specific one
-  applies.
 `<name>.SOURCE=<boolean>`::
-  Named Logger specific, attempts to print the Java source file name and
+  Named Logger specific, attempts to print the Java source file name and line number from where the logging event originated. 
-  line number from where the logging event originated. Name must be a
+  Name must be a fully qualified class name (this configurable does not support package name hierarchy). 
-  fully qualified class name (this configurable does not support package
+  Default is false. 
-  name hierarchy). Default is false. Be aware that this is a slow
+  Be aware that this is a slow operation and has an impact on performance.
-  operation and has an impact on performance.
 `<name>.STACKS=<boolean>`::
-  Named Logger specific, controls the display of stacktraces. Name must
+  Named Logger specific, controls the display of stacktraces. 
-  be a fully qualified class name (this configurable does not support
+  Name must be a fully qualified class name (this configurable does not support package name hierarchy).
-  package name hierarchy).
-  +
   Default is true.
 `org.eclipse.jetty.util.log.stderr.SOURCE=<boolean>`::
-  Special Global Configuration. Attempts to print the Java source file
+  Special Global Configuration. 
-  name and line number from where the logging event originated. Default
+  Attempts to print the Java source file name and line number from where the logging event originated. 
-  is false.
-`org.eclipse.jetty.util.log.stderr.LONG=<boolean>`::
-  Special Global Configuration. When true, outputs logging events to
-  STDERR using long form, fully qualified class names. When false, uses
-  abbreviated package names.
-  +
   Default is false.
-  +
+`org.eclipse.jetty.util.log.stderr.LONG=<boolean>`::
-  Example when set to false:
+  Special Global Configuration. 
-  +
+  When true, outputs logging events to `STDERR` using long form, fully qualified class names. 
+  When false, uses abbreviated package names.
+  Default is false.
+  * Example when set to false:
+
+[source, screen]
 ....
 2014-06-03 14:36:16.013:INFO:oejs.Server:main: jetty-9.2.0.v20140526
 2014-06-03 14:36:16.028:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/opt/jetty/demo-base/webapps/] at interval 1
@@ -113,8 +93,9 @@ the StdErrLog behavior.
 2014-06-03 14:36:17.888:INFO:oejs.Server:main: Started @257ms
 ....
   +
-  Example when set to true:
+  * Example when set to true:
   +
+[source, screen]
 ....
 2014-06-03 14:38:19.019:INFO:org.eclipse.jetty.server.Server:main: jetty-9.2.0.v20140526
 2014-06-03 14:38:19.032:INFO:org.eclipse.jetty.deploy.providers.ScanningAppProvider:main: Deployment monitor [file:/opt/jetty/demo-base/webapps/] at interval 1
@@ -123,28 +104,19 @@ the StdErrLog behavior.
 2014-06-03 14:38:20.723:INFO:org.eclipse.jetty.server.Server:main: Started @243ms
 ....
 
-Deprecated Parameters:
+[[deprecated-parameters]]
+==== Deprecated Parameters
 
-These parameters existed in prior versions of Jetty, and are no longer
+These parameters existed in prior versions of Jetty, and are no longer supported. 
-supported. They are included here for historical (and search engine)
+They are included here for historical (and search engine) reasons.
-reasons.
 
 `org.eclipse.jetty.util.log.DEBUG`::
-  Formerly used to enable DEBUG level logging on any logger used within
+  Formerly used to enable DEBUG level logging on any logger used within Jetty (not just Jetty's own logger).
-  Jetty (not just Jetty's own logger).
+  * Replaced with using the logger implementation specific configuration and level filtering.
-  +
-  Replaced with using the logger implementation specific configuration
-  and level filtering.
 `org.eclipse.jetty.util.log.stderr.DEBUG`::
-  Formerly used to enable DEBUG level logging on the internal Jetty
+  Formerly used to enable DEBUG level logging on the internal Jetty `StdErrLog` implementation.
-  StdErrLog implementation.
+  * Replaced with level specific equivalent.
-  +
+    Example: `org.eclipse.jetty.LEVEL=DEBUG`
-  Replaced with level specific equivalent: example:
-  `org.eclipse.jetty.LEVEL=DEBUG`
 `DEBUG`::
-  Ancient debugging flag that turned on all debugging, even non-logging
+  Ancient debugging flag that turned on all debugging, even non-logging debugging.
-  debugging.
+  * Jetty no longer uses because many third party libraries employ this overly simple property name, which would generate far too much console output.
-  +
-  Jetty no longer uses because many third party libraries employ this
-  overly simple property name, which would generate far too much console
-  output.

jetty-documentation/src/main/asciidoc/administration/logging/example-apache-log4j.adoc

@@ -15,18 +15,14 @@
 //  ========================================================================
 
 [[example-logging-log4j]]
-= Example: Logging with Apache Log4j
+=== Example: Logging with Apache Log4j
 
-It is possible to have the Jetty Server logging configured so that Log4j
+It is possible to have the Jetty Server logging configured so that Log4j controls the output of logging events produced by Jetty. 
-controls the output of logging events produced by Jetty. This is
+This is accomplished by configuring Jetty for logging to http://logging.apache.org/log4j/[Apache Log4j] via http://slf4j.org/manual.html[Slf4j] and the http://slf4j.org/manual.html#swapping[Slf4j binding layer for Log4j].
-accomplished by configuring Jetty for logging to
-http://logging.apache.org/log4j/[Apache Log4j] via
-http://slf4j.org/manual.html[Slf4j] and the
-http://slf4j.org/manual.html#swapping[Slf4j binding layer for Log4j].
 
-A convenient replacement `logging` module has been created to bootstrap
+A convenient replacement `logging` module has been created to bootstrap your `${jetty.base}` directory for logging with log4j.
-your `${jetty.base}` directory for logging with log4j.
 
+[source, screen]
 ....
 [mybase]$ mkdir modules
 [mybase]$ cd modules
@@ -53,37 +49,19 @@ INFO: resources       enabled in     ${jetty.base}/start.ini
 
 The replacement `logging.mod` performs a number of tasks.
 
-1.  `mybase` is a `${jetty.base}` directory
+.  `mybase` is a `${jetty.base}` directory.
-2.  The jetty-distribution is unpacked (and untouched) into
+.  The jetty-distribution is unpacked (and untouched) into `/opt/jetty-dist/` and becomes the `${jetty.home}` directory for this demonstration.
-`/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this
+.  The `curl` command downloads the replacement `logging.mod` and puts it into the `${jetty.base}/modules/` directory for use by mybase only.
-demonstration.
+.  The `start.jar --add-to-start=logging` command performs a number of steps to make the logging module available to the `${jetty.base}` configuration.
-3.  The `curl` command downloads the replacement `logging.mod` and puts
+..  The `--module=logging` command is added to the `${jetty.base}/start.ini` configuration.
-it into the `${jetty.base}/modules/` directory for use by mybase only.
+..  Required `${jetty.base}` directories are created: `${jetty.base}/logs` and `${jetty.base}/resources`
-4.  The `start.jar --add-to-start=logging` command performs a number of
+..  Required libraries are downloaded (if not present already): slf4j-api, slf4j-log4j, and log4j itself.
-steps to make the logging module available to the `${jetty.base}`
+* The libraries are put in the `${jetty.base}/lib/logging/` directory.
-configuration.
+..  Required configuration files are downloaded (if not present already): `jetty-logging.properties`, and `log4j.properties`
-1.  The `--module=logging` command is added to the
+* The configuration files are placed in the `${jetty.base}/resources/` directory.
-`${jetty.base}/start.ini` configuration
-2.  Required `${jetty.base}` directories are created:
-`${jetty.base}/logs` and `${jetty.base}/resources`
-3.  Required libraries are downloaded (if not present already):
-slf4j-api, slf4j-log4j, and log4j itself.
-+
-The libraries are put in the `${jetty.base}/lib/logging/` directory.
-4.  Required configuration files are downloaded (if not present
-already): `jetty-logging.properties`, and `log4j.properties`
-+
-The configuration files are put in the `${jetty.base}/resources/`
-directory.
-5.  At this point you have your `mybase` configured so that the jetty
-server itself will log using log4j, using the log4j configuration found
-in `mybase/resources/log4j.properties`
 
-You can verify the server classpath by using the `start.jar
+At this point the Jetty `mybase` is configured so that the Jetty server itself will log using log4j, using the log4j configuration found in `mybase/resources/log4j.properties`.
-    --list-config` command.
 
-In essence, Jetty is now configured to emit its own logging events to
+The server classpath can be verified by using the `start.jar --list-config` command.
-slf4j, and slf4j itself is using the static log binder found in
+
-slf4j-log4j12.jar. Making all Jetty + Slf4j + Log4j events emitted by
+In essence, Jetty is now configured to emit its own logging events to slf4j, and slf4j itself is using the static log binder found in `slf4j-log4j12.jar`, making all Jetty + Slf4j + Log4j events emitted by the Jetty server go to Log4j for routing (to console, file, syslog, etc...).
-the Jetty server go to Log4j for routing (to console, file, syslog,
-etc...)

jetty-documentation/src/main/asciidoc/administration/logging/example-java-util-logging-native.adoc

@@ -15,7 +15,7 @@
 //  ========================================================================
 
 [[example-logging-java-util-logging-native]]
-= Example: Logging with Java's java.util.logging via JavaUtilLog
+=== Example: Logging with Java's java.util.logging via JavaUtilLog
 
 It is possible to have the Jetty Server logging configured so that
 `java.util.logging` controls the output of logging events produced by
@@ -26,13 +26,13 @@ This example demonstrates how to configuring Jetty for logging to
 
 ____
 [IMPORTANT]
-While this is a valid setup, the Jetty project recommends always using the link:#example-logging-java-util-logging[slf4j to java.util.logging configuration] for memory and performance reasons.
+While this is a valid setup, the Jetty project recommends always using the link:#example-logging-java-util-logging[slf4j to java.util.logging configuration] for memory and performance reasons. 
-(this naive implementation is very non-performant and is not guaranteed to exist in the future)
+This native implementation is very non-performant and is not guaranteed to exist in the future.
 ____
 
-A convenient replacement `logging` module has been created to bootstrap
+A convenient replacement `logging` module has been created to bootstrap your `${jetty.base}` directory for logging with `java.util.logging`.
-your `${jetty.base}` directory for logging with java.util.logging.
 
+[source, screen]
 ....
 [mybase]$ mkdir modules
 [mybase]$ cd modules
@@ -57,53 +57,34 @@ INFO: resources       enabled in     ${jetty.base}/${jetty.base}
 
 The replacement `logging.mod` performs a number of tasks.
 
-1.  `mybase` is a `${jetty.base}` directory
+.  `mybase` is a `${jetty.base}` directory.
-2.  The jetty-distribution is unpacked (and untouched) into
+.  The jetty-distribution is unpacked (and untouched) into `/opt/jetty-dist/` and becomes the `${jetty.home}` directory for this demonstration.
-`/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this
+.  The `curl` command downloads the replacement `logging.mod` and puts it into the `${jetty.base}/modules/` directory for use by `mybase` only.
-demonstration.
+.  The `start.jar --add-to-start=logging` command performs a number of steps to make the logging module available to the `${jetty.base}`
-3.  The `curl` command downloads the replacement `logging.mod` and puts
-it into the `${jetty.base}/modules/` directory for use by mybase only.
-4.  The `start.jar --add-to-start=logging` command performs a number of
-steps to make the logging module available to the `${jetty.base}`
 configuration.
-1.  The `--module=logging` command is added to the
+..  The `--module=logging` command is added to the `${jetty.base}/start.ini` configuration.
-`${jetty.base}/start.ini` configuration
+..  Required `${jetty.base}` directories are created: `${jetty.base}/logs` and `${jetty.base}/resources`.
-2.  Required `${jetty.base}` directories are created:
+..  Required configuration files are downloaded (if not present already): `jetty-logging.properties`, and `logging.properties`
-`${jetty.base}/logs` and `${jetty.base}/resources`
+* The configuration files are put in the `${jetty.base}/resources/` directory.
-3.  Required configuration files are downloaded (if not present
+..  Required `java.util.logging` initialization commands are downloaded (if not present already): `jetty-logging.xml`.
-already): `jetty-logging.properties`, and `logging.properties`
+* The xml file is put in the `${jetty.base}/etc/` directory.
-+
-The configuration files are put in the `${jetty.base}/resources/`
-directory.
-4.  Required `java.util.logging` initialization commands are downloaded
-(if not present already): `jetty-logging.xml`
-+
-The xml file is put in the `${jetty.base}/etc/` directory.
-5.  At this point you have your `mybase` configured so that the jetty
-server itself will log using java.util.logging, using the
-java.util.logging configuration found in
-`mybase/resources/logging.properties`
 
-You can verify the server classpath by using the `start.jar
+At this point the Jetty `mybase` is configured so that the Jetty server itself will log using `java.util.logging`, using the `java.util.logging` configuration found in `mybase/resources/logging.properties`.
-    --list-config` command.
 
-In essence, Jetty is now configured to use
+The server classpath can be verified by using the `start.jar --list-config` command.
-`org.eclipse.jetty.util.log.JavaUtilLog`, which emit its own logging
-events to java.util.logging. Making all Jetty + java.util.logging events
-emitted by the Jetty server go to java.util.logging for routing (to
-console, file, etc...)
 
-If you have any custom java.util.logging handlers that you want to use,
+In essence, Jetty is now configured to use `org.eclipse.jetty.util.log.JavaUtilLog`, which emit its own logging events to `java.util.logging`, making all Jetty and `java.util.logging` events emitted by the Jetty server go to `java.util.logging` for routing (to console, file, etc...).
-put the implementation jar in your `${jetty.base}/lib/logging/`
+
-directory and reference them in the
+If there any custom `java.util.logging` handlers to be used, put the implementation jar in the `${jetty.base}/lib/logging/` directory and reference them in the `${jetty.base}/resources/logging.properties` file.
-`${jetty.base}/resources/logging.properties` file.
 
 ____
 [NOTE]
 `java.util.logging` is configured via the `${jetty.base}/resources/logging.properties` file during a valid startup of Jetty.
+
 This means that if there is any startup errors that occur before `java.util.logging` is configured, they will likely be lost and/or not routed through your configuration.
-(Other logging frameworks are more reliable in that they always initialize and configure on first use, unlike java.util.logging)
+
-+
+Other logging frameworks are more reliable in that they always initialize and configure on first use, unlike `java.util.logging`.
-While it is possible to configure java.util.logging sooner, even at JVM startup, the example demonstrated here does not show this technique.
+
-For more information consult the http://docs.oracle.com/javase/7/docs/api/java/util/logging/LogManager.html[official java.util.logging.LogManager javadoc documentation from Oracle].
+* While it is possible to configure `java.util.logging` sooner, even at JVM startup, the example demonstrated here does not show this technique.
+For more information consult the official `java.util.logging.LogManager` javadoc http://docs.oracle.com/javase/7/docs/api/java/util/logging/LogManager.html[documentation from Oracle].
 ____

jetty-documentation/src/main/asciidoc/administration/logging/example-java-util-logging.adoc

@@ -15,21 +15,16 @@
 //  ========================================================================
 
 [[example-logging-java-util-logging]]
-= Example: Logging with Java's java.util.logging via Slf4j
+=== Example: Logging with Java's java.util.logging via Slf4j
 
-It is possible to have the Jetty Server logging configured so that
+It is possible to have the Jetty Server logging configured so that `java.util.logging` controls the output of logging events produced by Jetty.
-`java.util.logging` controls the output of logging events produced by
-Jetty.
 
-This example demonstrates how to configuring Jetty for logging to
+This example demonstrates how to configuring Jetty for logging to `java.util.logging` via http://slf4j.org/manual.html[Slf4j] and the http://slf4j.org/manual.html#swapping[Slf4j binding layer for java.util.logging].
-`java.util.logging` via http://slf4j.org/manual.html[Slf4j] and the
+If you want to use the built-in native `JavaUtilLog` implementation, see #example-logging-java-util-logging-native .
-http://slf4j.org/manual.html#swapping[Slf4j binding layer for
-java.util.logging]. If you want to use the built-in native JavaUtilLog
-implementation, see #example-logging-java-util-logging-native
 
-A convenient replacement `logging` module has been created to bootstrap
+A convenient replacement `logging` module has been created to bootstrap your `${jetty.base}` directory for logging with `java.util.logging`.
-your `${jetty.base}` directory for logging with java.util.logging.
 
+[source, screen]
 ....
 [mybase]$ mkdir modules
 [mybase]$ cd modules
@@ -56,57 +51,35 @@ INFO: resources       enabled in     ${jetty.base}/start.ini
 
 The replacement `logging.mod` performs a number of tasks.
 
-1.  `mybase` is a `${jetty.base}` directory
+.  `mybase` is a `${jetty.base}` directory
-2.  The jetty-distribution is unpacked (and untouched) into
+.  The jetty-distribution is unpacked (and untouched) into `/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this demonstration.
-`/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this
+.  The `curl` command downloads the replacement `logging.mod` and puts it into the `${jetty.base}/modules/` directory for use by `mybase` only.
-demonstration.
+.  The `start.jar --add-to-start=logging` command performs a number of steps to make the logging module available to the `${jetty.base}` configuration.
-3.  The `curl` command downloads the replacement `logging.mod` and puts
+..  The `--module=logging` command is added to the `${jetty.base}/start.ini` configuration.
-it into the `${jetty.base}/modules/` directory for use by mybase only.
+..  Required `${jetty.base}` directories are created: `${jetty.base}/logs` and `${jetty.base}/resources`.
-4.  The `start.jar --add-to-start=logging` command performs a number of
+..  Required libraries are downloaded (if not present already): slf4j-api, and slf4j-jdk14.
-steps to make the logging module available to the `${jetty.base}`
+* The libraries are put in the `${jetty.base}/lib/logging/` directory.
-configuration.
+..  Required configuration files are downloaded (if not present already): `jetty-logging.properties`, and `logging.properties`.
-1.  The `--module=logging` command is added to the
+* The configuration files are put in the `${jetty.base}/resources/` directory.
-`${jetty.base}/start.ini` configuration
+..  Required `java.util.logging` initialization commands are downloaded (if not present already): `jetty-logging.xml`.
-2.  Required `${jetty.base}` directories are created:
+* The xml file is put in the `${jetty.base}/etc/` directory.
-`${jetty.base}/logs` and `${jetty.base}/resources`
-3.  Required libraries are downloaded (if not present already):
-slf4j-api, and slf4j-jdk14.
-+
-The libraries are put in the `${jetty.base}/lib/logging/` directory.
-4.  Required configuration files are downloaded (if not present
-already): `jetty-logging.properties`, and `logging.properties`
-+
-The configuration files are put in the `${jetty.base}/resources/`
-directory.
-5.  Required `java.util.logging` initialization commands are downloaded
-(if not present already): `jetty-logging.xml`
-+
-The xml file is put in the `${jetty.base}/etc/` directory.
-5.  At this point you have your `mybase` configured so that the jetty
-server itself will log using java.util.logging, using the
-java.util.logging configuration found in
-`mybase/resources/logging.properties`
 
-You can verify the server classpath by using the `start.jar
+At this point the Jetty `mybase` is configured so that the Jetty server itself will log using `java.util.logging`, using the `java.util.logging` configuration found in `mybase/resources/logging.properties`.
-    --list-config` command.
 
-In essence, Jetty is now configured to emit its own logging events to
+The server classpath can be verified by using the `start.jar --list-config` command.
-slf4j, and slf4j itself is using the static log binder found in
-slf4j-jdk14.jar. Making all Jetty + Slf4j + java.util.logging events
-emitted by the Jetty server go to java.util.logging for routing (to
-console, file, etc...)
 
-If you have any custom java.util.logging handlers that you want to use,
+In essence, Jetty is now configured to emit its own logging events to slf4j, and slf4j itself is using the static log binder found in `slf4j-jdk14.jar`, making all Jetty + Slf4j + `java.util.logging` events emitted by the Jetty server go to `java.util.logging` for routing (to console, file, etc...).
-put the implementation jar in your `${jetty.base}/lib/logging/`
+
-directory and reference them in the
+If there any custom `java.util.logging` handlers to be used, put the implementation jar in the `${jetty.base}/lib/logging/` directory and reference them in the `${jetty.base}/resources/logging.properties` file.
-`${jetty.base}/resources/logging.properties` file.
 
 ____
 [NOTE]
 `java.util.logging` is configured via the `${jetty.base}/resources/logging.properties` file during a valid startup of Jetty.
+
 This means that if there is any startup errors that occur before `java.util.logging` is configured, they will likely be lost and/or not routed through your configuration.
-(Other logging frameworks are more reliable in that they always initialize and configure on first use, unlike java.util.logging)
+
-+
+Other logging frameworks are more reliable in that they always initialize and configure on first use, unlike `java.util.logging`.
-While it is possible to configure java.util.logging sooner, even at JVM startup, the example demonstrated here does not show this technique.
+
-For more information consult the http://docs.oracle.com/javase/7/docs/api/java/util/logging/LogManager.html[official java.util.logging.LogManager javadoc documentation from Oracle].
+* While it is possible to configure `java.util.logging` sooner, even at JVM startup, the example demonstrated here does not show this technique.
+For more information consult the official `java.util.logging.LogManager` javadoc http://docs.oracle.com/javase/7/docs/api/java/util/logging/LogManager.html[documentation from Oracle].
 ____

jetty-documentation/src/main/asciidoc/administration/logging/example-logback-centralized-logging.adoc

@@ -15,43 +15,27 @@
 //  ========================================================================
 
 [[example-logging-logback-centralized]]
-= Example: Centralized Logging with Logback
+=== Example: Centralized Logging with Logback
 
-The term _Centralized Logging_ refers to a forced logging configuration
+The term _Centralized Logging_ refers to a forced logging configuration for the Jetty Server and all web applications that are deployed on the server. 
-for the Jetty Server and all web applications that are deployed on the
+It routes all logging events from the web applications to a single configuration on the Server side.
-server. It routes all logging events from the web applications to a
-single configuration on the Server side.
 
-The example below shows how to accomplish this with Jetty and Slf4j,
+The example below shows how to accomplish this with Jetty and Slf4j, using `Logback` to manage the final writing of logs to disk.
-using Logback to manage the final writing of logs to disk.
 
 ____
 [IMPORTANT]
 This mechanism forces all webapps to use the server's configuration for logging, something that isn't 100% appropriate for all webapps.
-+
 An example would be having Jenkins-CI deployed as an webapp, if you force its logging configuration to the server side, you lose the ability on http://jenkins-ci.org/[Jenkins-CI] to see the logs from the various builds (as now those logs are actually going to the main server log).
 ____
 
-This configuration is essentially the multiple logger configuration with
+This configuration is essentially the multiple logger configuration with added configuration to the deployers to force a `WebAppClassLoader` change to use the server classpath over the webapps classpath for the logger specific classes.
-added configuration to the deployers to force a WebAppClassLoader change
-to use the server classpath over the webapps classpath for the logger
-specific classes.
 
-The technique used by this configuration is to provide an
+The technique used by this configuration is to provide an link:{JDURL}org/eclipse/jetty/deploy/AppLifeCycle.Binding.html[AppLifeCycle.Binding] against the link:{JDURL}/org/eclipse/jetty/deploy/AppLifeCycle.html[`"deploying"`node] that modifies the link:{JDURL}/org/eclipse/jetty/webapp/WebAppContext.html#addSystemClass(java.lang.String)[WebAppContext.addSystemClass(String)] for the common logging classes. 
-link:{JDURL}org/eclipse/jetty/deploy/AppLifeCycle.Binding.html[AppLifeCycle.Binding]
+See https://github.com/jetty-project/jetty-webapp-logging/blob/master/src/main/java/org/eclipse/jetty/webapp/logging/CentralizedWebAppLoggingBinding.java[org.eclipse.jetty.logging.CentralizedWebAppLoggingBinding] for actual implementation.
-against the
-link:{JDURL}/org/eclipse/jetty/deploy/AppLifeCycle.html[`"deploying"`
-node] that modifies the
-link:{JDURL}/org/eclipse/jetty/webapp/WebAppContext.html#addSystemClass(java.lang.String)[WebAppContext.addSystemClass(String)]
-for the common logging classes. (See
-https://github.com/jetty-project/jetty-webapp-logging/blob/master/src/main/java/org/eclipse/jetty/webapp/logging/CentralizedWebAppLoggingBinding.java[org.eclipse.jetty.logging.CentralizedWebAppLoggingBinding]
-for actual implementation)
 
-A convenient replacement `logging` module has been created to bootstrap
+A convenient replacement `logging` module has been created to bootstrap your `${jetty.base}` directory for capturing all Jetty server logging from multiple logging frameworks into a single logging output file managed by Logback.
-your `${jetty.base}` directory for capturing all Jetty server logging
-from multiple logging frameworks into a single logging output file
-managed by logback.
 
+[source, screen]
 ....
 [mybase]$ mkdir modules
 [mybase]$ cd modules
@@ -96,71 +80,30 @@ INFO: resources       enabled in     ${jetty.base}/start.ini
 
 The replacement `logging.mod` performs a number of tasks.
 
-1.  `mybase` is a `${jetty.base}` directory
+.  `mybase` is a `${jetty.base}` directory.
-2.  The jetty-distribution is unpacked (and untouched) into
+.  The jetty-distribution is unpacked (and untouched) into `/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this demonstration.
-`/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this
+.  The `curl` command downloads the replacement `logging.mod` and puts it into the `${jetty.base}/modules/` directory for use by mybase only.
-demonstration.
+.  The `start.jar --add-to-start=logging,webapp-logging` command performs a number of steps to make the logging module available to the `${jetty.base}` configuration.
-3.  The `curl` command downloads the replacement `logging.mod` and puts
+..  Several entries are added to the `${jetty.base}/start.ini` configuration.
-it into the `${jetty.base}/modules/` directory for use by mybase only.
+*  `--module=logging` is added to enable the logging module.
-4.  The `start.jar
+*  `--module=webapp-logging` is added to enable the webapp-logging module.
-        --add-to-start=logging,webapp-logging` command performs a number
+..  Required `${jetty.base}` directories are created: `${jetty.base}/logs` and `${jetty.base}/resources`.
-of steps to make the logging module available to the `${jetty.base}`
+..  Required logging libraries are downloaded (if not present already) to the `${jetty.base}/lib/logging/` directory:
-configuration.
+* `slf4j-api.jar` - API jar for Slf4j (used by most of the rest of the jars)
-1.  Several entries are added to the `${jetty.base}/start.ini`
+* `log4j-over-slf4j.jar` - Slf4j jar that captures all log4j emitted logging events
-configuration
+* `jul-to-slf4j.jar` - Slf4j jar that captures all java.util.logging events
-1.  `--module=logging` is added to enable the logging module
+* `jcl-over-slf4j.jar` - Slf4j jar that captures all commons-logging events
-2.  `--module=webapp-logging` is added to enable the webapp-logging
+* `logback-classic.jar` - the Slf4j adapter jar that routes all of the captured logging events to logback itself.
-module
+* `logback-core.jar` - the logback implementation jar, that handles all of the filtering and output of the logging events.
-2.  Required `${jetty.base}` directories are created:
+..  Required webapp-logging library is downloaded (if not present already) to the `${jetty.base}/lib/webapp-logging/` directory:
-`${jetty.base}/logs` and `${jetty.base}/resources`
+* `jetty-webapp-logging.jar` - the Jetty side deployment manger app-lifecycle bindings for modifying the `WebAppClassloaders` of deployed webapps.
-3.  Required logging libraries are downloaded (if not present already):
+..  Required configuration files are downloaded (if not present already) to the `${jetty.base}/resources/` directory: `jetty-logging.properties`, and `logback.xml`.
-* slf4j-api.jar - API jar for Slf4j (used by most of the rest of the
+..  Required initialization commands are downloaded (if not present already) to the `${jetty.base}/etc/` directory: `jetty-logging.xml`, `jetty-webapp-logging.xml`, and `jetty-mdc-handler.xml`.
-jars)
-* log4j-over-slf4j.jar - Slf4j jar that captures all log4j emitted
-logging events
-* jul-to-slf4j.jar - Slf4j jar that captures all java.util.logging
-events
-* jcl-over-slf4j.jar - Slf4j jar that captures all commons-logging
-events
-* logback-classic.jar - the Slf4j adapter jar that routes all of the
-captured logging events to logback itself.
-* logback-core.jar - the logback implementation jar, that handles all of
-the filtering and output of the logging events.
-+
-These libraries are put in the `${jetty.base}/lib/logging/` directory.
-4.  Required webapp-logging library are downloaded (if not present
-already):
-* jetty-webapp-logging.jar - the jetty side deployment manger
-app-lifecycle bindings for modifying the WebAppClassloaders of deployed
-webapps.
-+
-This library is put in the `${jetty.base}/lib/webapp-logging/`
-directory.
-5.  Required configuration files are downloaded (if not present
-already): `jetty-logging.properties`, and `logback.xml`
-+
-The configuration files are put in the `${jetty.base}/resources/`
-directory.
-6.  Required initialization commands are downloaded (if not present
-already): `jetty-logging.xml`, `jetty-webapp-logging.xml`, and
-`jetty-mdc-handler.xml`
-+
-These xml files are put in the `${jetty.base}/etc/` directory.
-5.  At this point you have your `mybase` configured so that the jetty
-server itself will log using slf4j, and all other logging events from
-other Jetty Server components (such as database drivers, security
-layers, jsp, mail, and other 3rd party server components) are routed to
-logback for filtering and output.
-+
-All webapps deployed via the DeploymentManager have their
-WebAppClassLoader modified to use server side classes and configuration
-for all logging implementations.
 
-You can verify the server classpath by using the `start.jar
+At this point the Jetty `mybase` is configured so that the jetty server itself will log using slf4j, and all other logging events from other Jetty Server components (such as database drivers, security layers, jsp, mail, and other 3rd party server components) are routed to logback for filtering and output.
-    --list-config` command.
 
-In essence, Jetty is now configured to emit its own logging events to
+All webapps deployed via the `DeploymentManager` have their `WebAppClassLoader` modified to use server side classes and configuration for all logging implementations.
-slf4j, and various slf4j bridge jars are acting on behalf of log4j,
+
-java.util.logging, and commons-logging, routing all of the logging
+The server classpath can be verified by using the `start.jar --list-config` command.
-events to logback (a slf4j adapter) for routing (to console, file,
+
-etc...)
+In essence, Jetty is now configured to emit its own logging events to slf4j, and various slf4j bridge jars are acting on behalf of log4j, `java.util.logging`, and `commons-logging`, routing all of the logging events to logback (a slf4j adapter) for routing (to console, file, etc...).

jetty-documentation/src/main/asciidoc/administration/logging/example-logback-sifting.adoc

@@ -15,12 +15,11 @@
 //  ========================================================================
 
 [[example-logging-logback-sifting]]
-= Example: MDC Based Sifting of Logs with Logback
+=== Example: MDC Based Sifting of Logs with Logback
 
-This page describes how to create log files at the server level and name
+This page describes how to create log files at the server level and name them based on an arbitrary context. 
-them based on an arbitrary context. You do this with SLF4J + Logback +
+This can be done with SLF4J + Logback + Jetty Webapp Logging in the mix. 
-Jetty Webapp Logging in the mix. Find example projects for this feature
+Find example projects for this feature at github:
-at github:
 
 ....
 https://github.com/jetty-project/jetty-and-logback-example
@@ -30,19 +29,11 @@ https://github.com/jetty-project/jetty-and-logback-example
 [cols=",",options="header",]
 |=======================================================================
 |Modules |Description
-|/jetty-distro-with-logback-basic/ |Configures the jetty distribution
+|/jetty-distro-with-logback-basic/ |Configures the jetty distribution with logback enabled at the server level with an example logback configuration.
-with logback enabled at the server level with an example logback
-configuration.
 
-|/jetty-distro-with-logback-sifting/ |Configures the jetty distribution
+|/jetty-distro-with-logback-sifting/ |Configures the jetty distribution with logback, centralized webapp logging, an MDC handler, and a sample logback configuration that performs sifting based on the incoming Host header on the requests.
-with logback, centralized webapp logging, an MDC handler, and a sample
-logback configuration that performs sifting based on the incoming Host
-header on the requests.
 
-|/jetty-slf4j-mdc-handler/ |Provides the SLF4J MDC key/value pairs that
+|/jetty-slf4j-mdc-handler/ |Provides the SLF4J MDC key/value pairs that Jetty needs to perform the sample sifting.
-Jetty needs to perform the sample sifting.
 
-|/jetty-slf4j-test-webapp/ |A sample webapp+servlet that accepts
+|/jetty-slf4j-test-webapp/ |A sample webapp+servlet that accepts arbitrary values on a form POST and logs them via SLF4J, so that you can see the results of this example.
-arbitrary values on a form POST and logs them via SLF4J, so that you can
-see the results of this example.
 |=======================================================================

jetty-documentation/src/main/asciidoc/administration/logging/example-logback.adoc

@@ -15,17 +15,14 @@
 //  ========================================================================
 
 [[example-logging-logback]]
-= Example: Logging with Logback
+=== Example: Logging with Logback
 
-It is possible to have the Jetty Server logging configured so that
+It is possible to have the Jetty Server logging configured so that Logback controls the output of logging events produced by Jetty. 
-Logback controls the output of logging events produced by Jetty. This is
+This is accomplished by configuring Jetty for logging to `Logback`, which uses http://slf4j.org/manual.html[Slf4j] and the http://logback.qos.ch/[Logback Implementation for Slf4j].
-accomplished by configuring Jetty for logging to `Logback`, which uses
-http://slf4j.org/manual.html[Slf4j] and the
-http://logback.qos.ch/[Logback Implementation for Slf4j].
 
-A convenient replacement `logging` module has been created to bootstrap
+A convenient replacement `logging` module has been created to bootstrap the `${jetty.base}` directory for logging with logback.
-your `${jetty.base}` directory for logging with logback.
 
+[source, screen]
 ....
 [mybase]$ mkdir modules
 [mybase]$ cd modules
@@ -50,37 +47,17 @@ DOWNLOAD: https://raw.githubusercontent.com/jetty-project/logging-modules/master
 
 The replacement `logging.mod` performs a number of tasks.
 
-1.  `mybase` is a `${jetty.base}` directory
+.  `mybase` is a `${jetty.base}` directory.
-2.  The jetty-distribution is unpacked (and untouched) into
+.  The jetty-distribution is unpacked (and untouched) into `/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this demonstration.
-`/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this
+.  The `curl` command downloads the replacement `logging.mod` and puts it into the `${jetty.base}/modules/` directory for use by `mybase` only.
-demonstration.
+.  The `start.jar --add-to-start=logging` command performs a number of steps to make the logging module available to the `${jetty.base}` configuration.
-3.  The `curl` command downloads the replacement `logging.mod` and puts
+..  The `--module=logging` command is added to the `${jetty.base}/start.ini` configuration.
-it into the `${jetty.base}/modules/` directory for use by mybase only.
+..  Required `${jetty.base}` directories are created: `${jetty.base}/logs` and `${jetty.base}/resources`.
-4.  The `start.jar --add-to-start=logging` command performs a number of
+..  Required libraries are downloaded (if not present already) to the `${jetty.base}/lib/logging/` directory: slf4j-api, logback-core, and logback-classic.
-steps to make the logging module available to the `${jetty.base}`
+..  Required configuration files are downloaded (if not present already) to the `${jetty.base}/lib/resources/` directory.: `jetty-logging.properties`, and `logback.xml`.
-configuration.
-1.  The `--module=logging` command is added to the
-`${jetty.base}/start.ini` configuration
-2.  Required `${jetty.base}` directories are created:
-`${jetty.base}/logs` and `${jetty.base}/resources`
-3.  Required libraries are downloaded (if not present already):
-slf4j-api, logback-core, and logback-classic.
-+
-The libraries are put in the `${jetty.base}/lib/logging/` directory.
-4.  Required configuration files are downloaded (if not present
-already): `jetty-logging.properties`, and `logback.xml`
-+
-The configuration files are put in the `${jetty.base}/resources/`
-directory.
-5.  At this point you have your `mybase` configured so that the jetty
-server itself will log using logback, using the logback configuration
-found in `mybase/resources/logback.xml`
 
-You can verify the server classpath by using the `start.jar
+At this point the Jetty `mybase` is configured so that the Jetty server itself will log using Logback, using the Logback configuration found in `mybase/resources/logback.xml`
-    --list-config` command.
 
-In essence, Jetty is now configured to emit its own logging events to
+The server classpath can be verified by using the `start.jar --list-config` command.
-slf4j, and slf4j itself is using the static log binder found in
+
-logback-classic.jar. Making all Jetty + Slf4j + Logback events emitted
+In essence, Jetty is now configured to emit its own logging events to slf4j, and slf4j itself is using the static log binder found in logback-classic.jar, making all Jetty + Slf4j + Logback events emitted by the Jetty server go to Logback for routing (to console, file, syslog, etc...).
-by the Jetty server go to Logback for routing (to console, file, syslog,
-etc...)

jetty-documentation/src/main/asciidoc/administration/logging/example-slf4j-multiple-loggers.adoc

@@ -15,17 +15,11 @@
 //  ========================================================================
 
 [[example-slf4j-multiple-loggers]]
-= Example: Capturing Multiple Logging Frameworks with Slf4j
+=== Example: Capturing Multiple Logging Frameworks with Slf4j
 
-This page describes how to configure Jetty for capturing multiple
+This page describes how to configure Jetty for capturing multiple logging frameworks logging events into a single logging implementation handled by Slf4j.
-logging frameworks logging events into a single logging implementation
-handled by Slf4j.
 
-When using Slf4j, you can configure a single logging solution for the
+A single logging solution can be configured for the variety of logging libraries available in common use when using Slf4j. With careful setup, all of the following logging APIs can be supported at the same time, with a single configuration file to control the output of events produced.
-variety of logging libraries available in common use. With careful
-setup, you can support all of the following logging APIs at the same
-time, with a single configuration file to control the output of events
-produces by these APIs.
 
 Logging APIs that Slf4j supports:
 
@@ -35,15 +29,27 @@ Logging APIs that Slf4j supports:
 * JDK 1.4 Logging (aka `java.util.logging`)
 * Apache Commons Logging
 
-To accomplish this you must make some careful choices, starting with a
+To accomplish this configuration a single underlying logging framework should first be chosen.
-single underlying logging framework. This decision guides the rest of
+This decision guides the rest of the choices about jar files to place on the server classpath.
-your choices about JARs to place on the Server classpath.
+
+____
+[CAUTION]
+There MUST NOT be multiple underlying logging frameworks on the classpath.
+If there are, the Slf4j framework fails to load.
+____
+
+____
+[NOTE]
+Some third party libraries provide their own implementations of common logging APIs; be careful not to accidentally include an underlying logging framework.
+For example, if you are using SpringSource you likely have a `com.springsource.org.apache.log4j.jar` along with a `log4j.jar`, which have the same classes in them.
+In this example, use the `com.springsource.org.apache.log4j.jar` version and exclude the `log4j.jar`, as the SpringSource version includes extra metadata suitable for using SpringSource.
+____
 
 .Slf4j Logging Grid
 [width="100%",cols="25%,25%,25%,25%",options="header",]
 |=======================================================================
-|Logging API |Slf4j Binding Jar |Slf4j Adapter Jar |Underlying Logging
+|Logging API |Slf4j Binding Jar |Slf4j Adapter Jar |Underlying Logging Framework
-Framework
+
 |Logback API |n/a |logback-classic.jar |logback-core.jar
 
 |Log4j
@@ -60,63 +66,27 @@ Framework
 |=======================================================================
 
 Logging API::
-  The Logging API that you are either capturing events from and/or using
+  * The Logging API that you are either capturing events from and/or using to write out those events (for example, to disk).
-  to write out those events (for example, to disk).
 Slf4j Binding JAR::
-  Special JARs, created and maintained by the Slf4j project, that
+  * Special JARs, created and maintained by the Slf4j project, that pretend to be the various Logging API implementation classes, but instead just route that Logging API's events to Slf4j to handle.
-  pretend to be the various Logging API implementation classes, but
+  * There MAY be multiple Slf4j binding JARs present on the classpath at the same time.
-  instead just route that Logging API's events to Slf4j to handle.
+  
-  +
+  * For a single logging API, if you choose to use the Slf4j binding JAR, then you MUST NOT include the SLf4j adapter JAR or underlying logging  framework in the classpath as well.
-  There MAY be multiple Slf4j binding JARs present on the classpath at
-  the same time.
-  +
-  For a single logging API, if you choose to use the Slf4j binding JAR,
-  then you MUST NOT include the SLf4j adapter JAR or underlying logging
-  framework in the classpath as well.
 Slf4j Adapter Jar::
-  These JARs are created and maintained by the Slf4j project and route
+  * These JARs are created and maintained by the Slf4j project and route Slf4j logging events to a specific underlying logging framework.
-  Slf4j logging events to a specific underlying logging framework.
+  * There MUST NOT be multiple Slf4j adapter JARs present on the classpath at the same time.
-  +
+  * Logging events that these adapter JARs capture can come from direct use of the Slf4j API or via one of the Slf4j binding JAR implementations.
-  There MUST NOT be multiple Slf4j adapter JARs present on the classpath
-  at the same time.
-  +
-  Logging events that these adapter JARs capture can come from direct
-  use of the Slf4j API or via one of the Slf4j binding JAR
-  implementations.
 Underlying Logging Framework::
-  This is the last leg of your configuration, the implementation that
+  * This is the last leg of the configuration, the implementation that processes, filters, and outputs the logging events to the console, logging directory on disk, or whatever else the underlying logging framework supports (like Socket, SMTP, Database, or even SysLog in the case of Logback).
-  processes, filters, and outputs the logging events to the console,
-  logging directory on disk, or whatever else the underlying logging
-  framework supports (like Socket, SMTP, Database, or even SysLog in the
-  case of Logback).
-  +
-  ____
-  [CAUTION]
-  There MUST NOT be multiple underlying logging frameworks on the classpath.
-  If there are, the Slf4j framework fails to load.
-  ____
-+
-  ____
-  [NOTE]
-  Some third party libraries provide their own implementations of common   logging APIs; be careful not to accidentally include an underlying   logging framework.
-+
-  For example, if you are using SpringSource you likely have a `com.springsource.org.apache.log4j.jar` along with a `log4j.jar`, which have the same classes in them.
-  In this example, use the `com.springsource.org.apache.log4j.jar` version and exclude the `log4j.jar`, as the SpringSource version includes extra metadata suitable for using SpringSource.
-  ____
 
 The following sections use Logback as the underlying Logging framework.
-This requires using `logback-classic.jar` and `logback-core.jar`, and
+This requires using `logback-classic.jar` and `logback-core.jar`, and excluding any other Slf4j adapter JAR or underlying logging framework.
-excluding any other Slf4j adapter JAR or underlying logging framework.
 
-It also requires including the other Slf4j binding JARs in the
+It also requires including the other Slf4j binding JARs in the classpath, along with some special initialization for `java.util.logging`.
-classpath, along with some special initialization for
-`java.util.logging`.
 
-A convenient replacement `logging` module has been created to bootstrap
+A convenient replacement `logging` module has been created to bootstrap the `${jetty.base}` directory for capturing all Jetty server logging from multiple logging frameworks into a single logging output file managed by logback.
-your `${jetty.base}` directory for capturing all Jetty server logging
-from multiple logging frameworks into a single logging output file
-managed by logback.
 
+[source, screen]
 ....
 [mybase]$ mkdir modules
 [mybase]$ cd modules
@@ -147,54 +117,24 @@ INFO: resources       enabled in     ${jetty.base}/start.ini
 
 The replacement `logging.mod` performs a number of tasks.
 
-1.  `mybase` is a `${jetty.base}` directory
+.  `mybase` is a `${jetty.base}` directory.
-2.  The jetty-distribution is unpacked (and untouched) into
+.  The jetty-distribution is unpacked (and untouched) into `/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this demonstration.
-`/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this
+.  The `curl` command downloads the replacement `logging.mod` and puts it into the `${jetty.base}/modules/` directory for use by `mybase` only.
-demonstration.
+.  The `start.jar --add-to-start=logging` command performs a number of steps to make the logging module available to the `${jetty.base}` configuration.
-3.  The `curl` command downloads the replacement `logging.mod` and puts
+..  The `--module=logging` command is added to the `${jetty.base}/start.ini` configuration.
-it into the `${jetty.base}/modules/` directory for use by mybase only.
+..  Required `${jetty.base}` directories are created: `${jetty.base}/logs` and `${jetty.base}/resources`.
-4.  The `start.jar --add-to-start=logging` command performs a number of
+..  Required libraries are downloaded (if not present already) to the the `${jetty.base}/lib/logging/` directory:
-steps to make the logging module available to the `${jetty.base}`
+* `slf4j-api.jar` - API jar for Slf4j (used by most of the rest of the jars)
-configuration.
+* `log4j-over-slf4j.jar` - Slf4j jar that captures all log4j emitted logging events
-1.  The `--module=logging` command is added to the
+* `jul-to-slf4j.jar` - Slf4j jar that captures all `java.util.logging` events
-`${jetty.base}/start.ini` configuration
+* `jcl-over-slf4j.jar` - Slf4j jar that captures all `commons-logging` events
-2.  Required `${jetty.base}` directories are created:
+* `logback-classic.jar` - the Slf4j adapter jar that routes all of the captured logging events to logback itself.
-`${jetty.base}/logs` and `${jetty.base}/resources`
+* `logback-core.jar` - the logback implementation jar, that handles all of the filtering and output of the logging events.
-3.  Required libraries are downloaded (if not present already):
+..  Required configuration files are downloaded (if not present already) to the `${jetty.base}/resources/` directory: `jetty-logging.properties`, and `logback.xml`
-* slf4j-api.jar - API jar for Slf4j (used by most of the rest of the
+..  Required `java.util.logging` initialization commands are downloaded (if not present already) to the `${jetty.base}/etc/` directory: `jetty-logging.xml`
-jars)
-* log4j-over-slf4j.jar - Slf4j jar that captures all log4j emitted
-logging events
-* jul-to-slf4j.jar - Slf4j jar that captures all java.util.logging
-events
-* jcl-over-slf4j.jar - Slf4j jar that captures all commons-logging
-events
-* logback-classic.jar - the Slf4j adapter jar that routes all of the
-captured logging events to logback itself.
-* logback-core.jar - the logback implementation jar, that handles all of
-the filtering and output of the logging events.
-+
-These libraries are put in the `${jetty.base}/lib/logging/` directory.
-4.  Required configuration files are downloaded (if not present
-already): `jetty-logging.properties`, and `logback.xml`
-+
-The configuration files are put in the `${jetty.base}/resources/`
-directory.
-5.  Required `java.util.logging` initialization commands are downloaded
-(if not present already): `jetty-logging.xml`
-+
-The xml file is put in the `${jetty.base}/etc/` directory.
-5.  At this point you have your `mybase` configured so that the jetty
-server itself will log using slf4j, and all other logging events from
-other Jetty Server components (such as database drivers, security
-layers, jsp, mail, and other 3rd party server components) are routed to
-logback for filtering and output.
 
-You can verify the server classpath by using the `start.jar
+At this point the Jetty `mybase` is configured so that the jetty server itself will log using slf4j, and all other logging events from other Jetty server components (such as database drivers, security layers, jsp, mail, and other 3rd party server components) are routed to logback for filtering and output.
-    --list-config` command.
 
-In essence, Jetty is now configured to emit its own logging events to
+The server classpath can be verified by using the `start.jar --list-config` command.
-slf4j, and various slf4j bridge jars are acting on behalf of log4j,
+
-java.util.logging, and commons-logging, routing all of the logging
+In essence, Jetty is now configured to emit its own logging events to slf4j, and various slf4j bridge jars are acting on behalf of log4j, `java.util.logging`, and `commons-logging`, routing all of the logging events to logback (a Slf4j adapter) for routing (to console, file, etc...).
-events to logback (a slf4j adapter) for routing (to console, file,
-etc...)

jetty-documentation/src/main/asciidoc/administration/npn/npn.adoc

@@ -281,6 +281,7 @@ implementation with the OpenJDK versions.
 
 Clone the OpenJDK repository with the following command:
 
+[source, screen]
 ....
 $ hg clone http://hg.openjdk.java.net/jdk7u/jdk7u jdk7u
 $ cd jdk7u
@@ -290,6 +291,7 @@ $ ./get_source.sh
 
 To update the source to a specific tag, use the following command:
 
+[source, screen]
 ....
 $ ./make/scripts/hgforest.sh update <tag-name>
   

jetty-documentation/src/main/asciidoc/administration/runner/jetty-runner.adoc

@@ -33,6 +33,7 @@ You will need the jetty-runner jar:
 Let's assume we have a very simple webapp, that does not need any resources from its environment, nor any configuration apart from the defaults. 
 Starting it is as simple as doing the following:
 
+[source, screen]
 ....
 > java -jar jetty-runner.jar simple.war      
 ....
@@ -41,12 +42,14 @@ This will start jetty on port 8080, and deploy the webapp to "/".
 
 Your webapp does not have to be packed into a war, you can deploy a webapp that is a directory instead in the same way:
 
+[source, screen]
 ....
 > java -jar jetty-runner.jar simple  
 ....
 
 In fact, the webapp does not have to be a war or even a directory, it can simply be a jetty link:#using-context-provider[context xml] file that describes your webapp:
 
+[source, screen]
 ....
 > java -jar jetty-runner.jar simple-context.xml
 ....
@@ -62,6 +65,7 @@ If you have more than one webapp that must be deployed, simply provide them all
 You can control the context paths for them using the "--path" parameter. 
 Here's an example of deploying 2 wars (although either or both of them could be unpacked directories instead):
 
+[source, screen]
 ....
 > java -jar jetty-runner.jar --path /one my1.war --path /two my2.war  
 ....
@@ -69,6 +73,7 @@ Here's an example of deploying 2 wars (although either or both of them could be
 If you have context xml files that describe your webapps, you can fully configure your webapps in them, and hence you don't need to use the command line switches. 
 Just provide the list of context files like so:
 
+[source, screen]
 ....
 > java -jar jetty-runner.jar my-first-context.xml my-second-context.xml my-third-context.xml
     
@@ -86,6 +91,7 @@ By default the jetty-runner will listen on port 8080.
 You can easily change this on the command line using the "--port" command. 
 Here's an example that runs our simple.war on port 9090:
 
+[source, screen]
 ....
 > java -jar jetty-runner.jar --port 9090 simple.war  
 ....
@@ -95,6 +101,7 @@ Here's an example that runs our simple.war on port 9090:
 Instead of, or in addition to using command line switches, you can use one or more jetty.xml files to configure the environment for your webapps. 
 Here's an example where we apply two different jetty.xml files:
 
+[source, screen]
 ....
 > java -jar jetty-runner.jar --config jetty.xml --config jetty-https.xml simple.war    
 ....
@@ -108,6 +115,7 @@ ____
 
 You can see the fill set of configuration options using the --help switch:
 
+[source, screen]
 ....
 > java -jar jetty-runner.jar --help    
 ....
@@ -139,6 +147,7 @@ Context opts:
 Printing the version:::
   Print out the version of jetty and then exit immediately.
 +
+[source, screen]
 ....
 > java -jar jetty-runner.jar --version          
 
@@ -149,6 +158,7 @@ Configuring a request log:::
   If the file is prefixed with yyyy_mm_dd then the file will be automatically rolled over. 
   Note that for finer grained configuration of the link:{JDURL}/org/eclipse/jetty/server/NCSARequestLog.html[request log], you will need to use a jetty xml file instead.
 +
+[source, screen]
 ....
 > java -jar jetty-runner.jar --log yyyy_mm_dd-requests.log  my.war            
 
@@ -158,6 +168,7 @@ Configuring the output log:::
   Redirect the output of jetty logging to the named file. 
   If the file is prefixed with yyyy_mm_dd then the file will be automatically rolled over.
 +
+[source, screen]
 ....
 > java -jar jetty-runner.jar --out yyyy_mm_dd-output.log my.war        
 
@@ -167,6 +178,7 @@ Configuring the interface for http:::
   Like jetty standalone, the default is for the connectors to listen on all interfaces on a machine. 
   You can control that by specifying the name or ip address of the particular interface you wish to use with the --host argument:
 +
+[source, screen]
 ....
 > java -jar jetty-runner.jar --host 192.168.22.19 my.war
 
@@ -176,6 +188,7 @@ Configuring the port for http:::
   The default port number is 8080. 
   To link:#how-to-configure-connectors[configure a https connector], use a jetty xml config file instead.
 +
+[source, screen]
 ....
 > java -jar jetty-runner.jar --port 9090  my.war        
 
@@ -186,6 +199,7 @@ Configuring stop:::
   This requires the use of a "secret" key, to prevent malicious or accidental termination. 
   Use the --stop-port and --stop-key parameters as arguments to the jetty-runner:
 +
+[source, screen]
 ....
 > java -jar jetty-runner.jar --stop-port 8181 --stop-key abc123
         
@@ -195,6 +209,7 @@ Then, to stop jetty from a different terminal, you need to supply the same port
 For this you'll either need a local installation of jetty, the link:#jetty-maven-plugin[jetty-maven-plugin], the link:#jetty-ant[jetty-ant plugin], or write a custom class. 
 Here's how to use a jetty installation to perform a stop:
 +
+[source, screen]
 ....
 > java -jar start.jar --stop-port 8181 --stop-key abc123 --stop
         
@@ -207,6 +222,7 @@ Configuring the container classpath:::
 --lib adds the location of a directory which contains jars to add to the container classpath. 
 You can add 1 or more. Here's an example of configuring 2 directories:
 +
+[source, screen]
 ....
 > java -jar jetty-runner.jar --lib /usr/local/external/lib --lib $HOME/external-other/lib my.war
         
@@ -216,6 +232,7 @@ You can add 1 or more. Here's an example of configuring 2 directories:
 You can add 1 or more. 
 Here's an example of configuring 3 extra jars:
 +
+[source, screen]
 ....
 > java -jar jetty-runner.jar --jar /opt/stuff/jars/jar1.jar --jar $HOME/jars/jar2.jar --jar /usr/local/proj/jars/jar3.jar  my.war
         
@@ -225,6 +242,7 @@ Here's an example of configuring 3 extra jars:
 You can add 1 or more. 
 Here's an example of configuring a single extra classes dir:
 +
+[source, screen]
 ....
 > java -jar jetty-runner.jar --classes /opt/stuff/classes my.war
         
@@ -236,6 +254,7 @@ Gathering statistics:::
   context with a password. Here's an example of enabling statistics,
   with no password protection:
 +
+[source, screen]
 ....
 > java -jar jetty-runner.jar --stats unsecure my.war
           
@@ -257,6 +276,7 @@ digest: MD5:6e120743ad67abfbc385bc2bb754e297,user
 +
 Assuming we've copied it into the local directory, we would apply it like so
 +
+[source, screen]
 ....
 > java -jar jetty-runner.jar --stats realm.properties my.war
         

jetty-documentation/src/main/asciidoc/administration/startup/screen-empty-base-listconfig.adoc

@@ -14,6 +14,7 @@
 //  You may elect to redistribute this code under either of these licenses.
 //  ========================================================================
 
+[source, screen]
 ....
 [mybase]$ java -jar /opt/jetty-distribution/start.jar --list-config
 

jetty-documentation/src/main/asciidoc/administration/startup/screen-empty-base.adoc

@@ -14,6 +14,7 @@
 //  You may elect to redistribute this code under either of these licenses.
 //  ========================================================================
 
+[source, screen]
 ....
 WARNING: Nothing to start, exiting ...
 

jetty-documentation/src/main/asciidoc/administration/startup/screen-http-webapp-deploy-listconfig.adoc

@@ -14,6 +14,7 @@
 //  You may elect to redistribute this code under either of these licenses.
 //  ========================================================================
 
+[source, screen]
 ....
 [mybase]$ java -jar /opt/jetty-distribution/start.jar --list-config
 

jetty-documentation/src/main/asciidoc/administration/startup/screen-http-webapp-deploy.adoc

@@ -14,6 +14,7 @@
 //  You may elect to redistribute this code under either of these licenses.
 //  ========================================================================
 
+[source, screen]
 ....
 [mybase]$ java -jar /opt/jetty-distribution/start.jar --add-to-start=http,webapp,deploy
 

jetty-documentation/src/main/asciidoc/administration/startup/screen-list-modules.adoc

@@ -14,6 +14,7 @@
 //  You may elect to redistribute this code under either of these licenses.
 //  ========================================================================
 
+[source, screen]
 ....
 [mybase]$ java -jar /opt/jetty-distribution/start.jar --list-modules
 

jetty-documentation/src/main/asciidoc/administration/startup/start-jar.adoc

@@ -21,6 +21,7 @@ The most basic way of starting the Jetty standalone server is to execute
 the `start.jar`, which is a bootstrap for starting Jetty with the
 configuration you want.
 
+[source, screen]
 ....
 [jetty-distribution-@project.version@]$ java -jar start.jar
 2013-09-23 11:27:06.654:INFO:oejs.Server:main: jetty-@project.version@
@@ -174,6 +175,7 @@ module system).
   http://graphviz.org/content/dot-language[dot file] of the module graph
   as it exists for the active `${jetty.base}`.
   +
+[source, screen]
 ....
 # generate module.dot
 $ java -jar start.jar --module=websocket --write-module-graph=modules.dot

jetty-documentation/src/main/asciidoc/administration/startup/startup-base-vs-home.adoc

@@ -61,6 +61,7 @@ enables the various demonstration webapps and server configurations.
 
 How to use the demo-base directory as a Jetty Base directory.
 
+[source, screen]
 ....
 [jetty-distribution-@project.version@]$ ls -la
 total 496
@@ -96,6 +97,7 @@ using the Jetty Base concepts.
 If you want to see what the Jetty Base looks like without executing
 Jetty, you can simply list the configuration
 
+[source, screen]
 ....
 [my-base]$ java -jar $JETTY_HOME/start.jar --list-config
 
@@ -221,6 +223,7 @@ elements came from, be it in either in `${jetty.home}` or
 If you look at the $\{jetty.base}/start.ini you will see something like
 the following.
 
+[source, screen]
 ....
 [my-base]$ cat start.ini
 # Enable security via jaas, and configure it
@@ -279,6 +282,7 @@ The Jetty start.jar and XML files always assume that both
 You can opt to manually define the `${jetty.home}` and `${jetty.base}`
 directories, such as this:
 
+[source, screen]
 ....
 [jetty-distribution-@project.version@]$ pwd
 /home/user/jetty-distribution-@project.version@
@@ -296,6 +300,7 @@ The following example uses default discovery of `${jetty.home}` by using
 the parent directory of wherever start.jar itself is, and a manual
 declaration of `${jetty.base}`.
 
+[source, screen]
 ....
 [jetty-distribution-@project.version@]$ pwd
 /home/user/jetty-distribution-@project.version@
@@ -313,6 +318,7 @@ The following demonstrates this by allowing default discovery of
 `${jetty.home}` via locating the `start.jar`, and using the `user.dir`
 System Property for `${jetty.base}`.
 
+[source, screen]
 ....
 [jetty-distribution-@project.version@]$ pwd
 /home/user/jetty-distribution-@project.version@

jetty-documentation/src/main/asciidoc/administration/startup/startup-classpath.adoc

@@ -67,6 +67,7 @@ The `--list-classpath` command line option is used as such.
 (Demonstrated with the link:#demo-base[demo-base from the Jetty
 Distribution])
 
+[source, screen]
 ....
 [demo-base]$ java -jar $JETTY_HOME/start.jar --list-classpath
 

jetty-documentation/src/main/asciidoc/administration/startup/startup-overview.adoc

@@ -87,6 +87,7 @@ XML Files::
 The simplest way to start Jetty is via the `start.jar` mechanism using
 the following Java command line:
 
+[source, screen]
 ....
 [user]$ cd jetty-distribution-@project.version@
 [jetty-distribution-@project.version@]$ java -jar start.jar --module=http jetty.http.port=8080
@@ -97,6 +98,7 @@ properties, and XML files with the metadata obtained from the `http`
 module. Specifically the `http` module is defined in the
 `${jetty.home}/modules/http.mod` file, and includes the following:
 
+[source, screen]
 ....
 [jetty-distribution-@project.version@]$ cat modules/http.mod
 [depend]
@@ -119,6 +121,7 @@ section is not actually used by the command above, so the
 Following the server dependency, the `${jetty.home}/modules/server.mod`
 file includes:
 
+[source, screen]
 ....
 [jetty-distribution-@project.version@]$ cat modules/server.mod
 [lib]
@@ -145,6 +148,7 @@ line required to start Jetty.
 Another way to see this is by asking Jetty what its configuration looks
 like:
 
+[source, screen]
 ....
 [jetty-distribution-@project.version@]$ java -jar start.jar --module=http jetty.http.port=9099 --list-config
 
@@ -206,6 +210,7 @@ using a traditional Java command line.
 The following is the equivalent `java` command line for what the
 `start.jar` bootstrap above performs.
 
+[source, screen]
 ....
 [user]$ cd jetty-distribution-@project.version@
 [jetty-distribution-@project.version@]$ echo jetty.http.port=8080 > /tmp/jetty.properties
@@ -237,6 +242,7 @@ You can further simplify the startup of this server by using the INI
 template defined by the modules to create a `start.ini` file with the
 command:
 
+[source, screen]
 ....
 [user]$ cd jetty-distribution-@project.version@
 [jetty-distribution-@project.version@]$ mkdir example-base
@@ -260,6 +266,7 @@ drwxrwxr-x 12 user webgroup 4096 Oct  4 11:49 ../
 Once complete, you can edit the `start.ini` file to modify any
 parameters and you can run the server with the simple command:
 
+[source, screen]
 ....
 [example-base]$ java -jar $JETTY_HOME/start.jar
 ....

jetty-documentation/src/main/asciidoc/administration/startup/startup-unix-service.adoc

@@ -27,6 +27,7 @@ This script is suitable for setting up Jetty as a service in Unix.
 
 The minimum steps to get Jetty to run as a Service
 
+[source, screen]
 ....
 [/opt/jetty]# tar -zxf /home/user/downloads/jetty-distribution-@project.version@.tar.gz 
 [/opt/jetty]# cd jetty-distribution-@project.version@/
@@ -61,6 +62,7 @@ The techniques outlined here assume an installation on Linux
 
 Prepare some empty directories to work with.
 
+[source, screen]
 ....
 # mkdir -p /opt/jetty
 # mkdir -p /opt/web/mybase
@@ -87,6 +89,7 @@ The directory purposes are as follows:
 Jetty $\{project.version} requires Java 7 (or greater) to run. Make sure
 you have it installed.
 
+[source, screen]
 ....
 # apt-get install openjdk-7-jdk
 ....
@@ -94,6 +97,7 @@ you have it installed.
 Or download Java 7 from:
 http://www.oracle.com/technetwork/java/javase/downloads/index.html
 
+[source, screen]
 ....
 # java -version
 java version "1.6.0_27"
@@ -125,6 +129,7 @@ OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
 It is recommended that you create a user to specifically run Jetty. This
 user should have the minimum set of privileges needed to run Jetty.
 
+[source, screen]
 ....
 # useradd --user-group --shell /bin/false --home-dir /opt/jetty/temp jetty
 ....
@@ -138,6 +143,7 @@ link:#jetty-downloading[Official Eclipse Download Site]
 
 Unpack it into place.
 
+[source, screen]
 ....
 [/opt/jetty]# tar -zxf /home/user/Downloads/jetty-distribution-@project.version@.tar.gz 
 [/opt/jetty]# ls -F
@@ -165,6 +171,7 @@ ____
 In past versions of Jetty, you would configure / modify / add to the jetty-distribution directory directly. While this is still supported, we encourage you to setup a proper `${jetty.base}` directory, as it will benefit you with easier jetty-distribution upgrades in the future.
 ____
 
+[source, screen]
 ....
 # cd /opt/web/mybase/
 [/opt/web/mybase]# ls
@@ -204,6 +211,7 @@ up and configuring a `${jetty.base}` directory.
 
 Copy your war file into place.
 
+[source, screen]
 ....
 # cp /home/user/projects/mywebsite.war /opt/web/mybase/webapps/
 ....
@@ -215,6 +223,7 @@ your opportunity to change this from the default value of `8080` to
 Edit the `/opt/web/mybase/start.ini` and change the `jetty.http.port`
 value.
 
+[source, screen]
 ....
 # grep jetty.http.port /opt/web/mybase/start.ini
 jetty.port=80
@@ -223,6 +232,7 @@ jetty.port=80
 Change the permissions on the Jetty distribution, and your webapp
 directories so that the user you created can access it.
 
+[source, screen]
 ....
 # chown --recursive jetty /opt/jetty
 # chown --recursive jetty /opt/web/mybase
@@ -231,6 +241,7 @@ directories so that the user you created can access it.
 Next we need to make the Unix System aware that we have a new Jetty
 Service that can be managed by the standard `service` calls.
 
+[source, screen]
 ....
 # cp /opt/jetty/jetty-distribution-@project.version@/bin/jetty.sh /etc/init.d/jetty
 # echo "JETTY_HOME=/opt/jetty/jetty-distribution-@project.version@" > /etc/default/jetty
@@ -240,6 +251,7 @@ Service that can be managed by the standard `service` calls.
 
 Test out the configuration
 
+[source, screen]
 ....
 # service jetty status
 Checking arguments to Jetty: 
@@ -275,6 +287,7 @@ along with the service level files necessary to start the service.
 
 Go ahead, start it.
 
+[source, screen]
 ....
 # service jetty start
 Starting Jetty: OK Wed Nov 20 12:35:28 MST 2013

jetty-documentation/src/main/asciidoc/administration/startup/startup-windows-service.adoc

@@ -29,6 +29,7 @@ The techniques outlined here are based on Windows 7 (64-bit), using JDK
 
 Prepare some empty directories to work with.
 
+[source, screen]
 ....
 C:\> mkdir opt
 C:\> cd opt
@@ -77,6 +78,7 @@ C:\opt\temp::
 Or download Java 7 from:
 http://www.oracle.com/technetwork/java/javase/downloads/index.html
 
+[source, screen]
 ....
 C:\opt>java -version
 java version "1.7.0_45"
@@ -94,6 +96,7 @@ of the `jetty-distribution-@project.version@` directory into place at
 Once you are complete, the contents of the `C:\opt\jetty` directory
 should look like this:
 
+[source, screen]
 ....
 C:\opt\jetty>dir
  Volume in drive C has no label.
@@ -140,6 +143,7 @@ file.
 Once you are complete, the contents of `C:\opt` directory should look
 like this:
 
+[source, screen]
 ....
 C:\opt> dir 
  Volume in drive C has no label.
@@ -164,6 +168,7 @@ your WebApps and the configurations that they need.
 We'll start by specifying which modules we want to use (this will create
 a start.ini file and also create a few empty directories for you)
 
+[source, screen]
 ....
 C:\opt\myappbase>java -jar ..\jetty\start.jar --add-to-start=deploy,http,logging
 
@@ -216,6 +221,7 @@ up and configuring a `${jetty.base}` directory.
 At this point you merely have to copy your WAR files into the webapps
 directory.
 
+[source, screen]
 ....
 C:\opt\myappbase> copy C:\projects\mywebsite.war webapps\
 ....

jetty-documentation/src/main/asciidoc/administration/tuning/high-load.adoc

@@ -50,6 +50,7 @@ Linux does a reasonable job of self-configuring TCP/IP, but there are a few limi
 
 You should increase TCP buffer sizes to at least 16MB for 10G paths and tune the auto-tuning (although you now need to consider buffer bloat).
 
+[source, screen]
 ....
 $ sysctl -w net.core.rmem_max=16777216
 $ sysctl -w net.core.wmem_max=16777216
@@ -64,6 +65,7 @@ $ sysctl -w net.ipv4.tcp_wmem="4096 16384 16777216"
 The default value is 128; if you are running a high-volume server and connections are getting refused at a TCP level, you need to increase this. 
 This is a very tweakable setting in such a case: if you set it too high, resource problems occur as it tries to notify a server of a large number of connections, and many remain pending, but if you set it too low, refused connections occur.
 
+[source, screen]
 ....
  $ sysctl -w net.core.somaxconn=4096
      
@@ -72,6 +74,7 @@ This is a very tweakable setting in such a case: if you set it too high, resourc
 The `net.core.netdev_max_backlog` controls the size of the incoming packet queue for upper-layer (java) processing. 
 The default (2048) may be increased and other related parameters (TODO MORE EXPLANATION) adjusted with:
 
+[source, screen]
 ....
 
 $ sysctl -w net.core.netdev_max_backlog=16384
@@ -85,6 +88,7 @@ $ sysctl -w net.ipv4.tcp_syncookies=1
 
 If many outgoing connections are made (for example, on load generators), the operating system might run low on ports. Thus it is best to increase the port range, and allow reuse of sockets in TIME_WAIT:
 
+[source, screen]
 ....
 
 $ sysctl -w net.ipv4.ip_local_port_range="1024 65535"
@@ -108,6 +112,7 @@ theusername            soft nofile     40000
 Linux supports pluggable congestion control algorithms. 
 To get a list of congestion control algorithms that are available in your kernel run:
 
+[source, screen]
 ....
 $ sysctl net.ipv4.tcp_available_congestion_control
         
@@ -116,6 +121,7 @@ $ sysctl net.ipv4.tcp_available_congestion_control
 If cubic and/or htcp are not listed, you need to research the control algorithms for your kernel. 
 You can try setting the control to cubic with:
 
+[source, screen]
 ....
 $ sysctl -w net.ipv4.tcp_congestion_control=cubic
     

jetty-documentation/src/main/asciidoc/configuring/connectors/configuring-ssl.adoc

@@ -113,6 +113,7 @@ read the full manuals of the tools you are using if you want to specify:
 The following command generates a key pair and certificate directly into
 file `keystore`:
 
+[source, screen]
 ....
 $ keytool -keystore keystore -alias jetty -genkey -keyalg RSA
 ....
@@ -129,6 +130,7 @@ passwords to protect both the keystore and the keys within it. The only
 mandatory response is to provide the fully qualified host name of the
 server at the "first and last name" prompt. For example:
 
+[source, screen]
 ....
 $ keytool -keystore keystore -alias jetty -genkey -keyalg RSA -sigalg SHA256withRSA
  Enter keystore password:  password
@@ -168,6 +170,7 @@ otherwise your certificate is only valid for one month.
 If you are using java 8 or later, then you may also use the SAN
 extension to set one or more names that the certificate applies to:
 
+[source, screen]
 ....
 $ keytool -keystore keystore -alias jetty -genkey -keyalg RSA -sigalg SHA256withRSA -ext 'SAN=dns:jetty.eclipse.org,dns:*.jetty.org'
  ...
@@ -178,6 +181,7 @@ $ keytool -keystore keystore -alias jetty -genkey -keyalg RSA -sigalg SHA256with
 
 The following command generates a key pair in the file `jetty.key`:
 
+[source, screen]
 ....
 $ openssl genrsa -aes128 -out jetty.key
 ....
@@ -188,6 +192,7 @@ arbitrary file that helps seed the random number generator.
 The following command generates a certificate for the key into the file
 ` jetty.crt`:
 
+[source, screen]
 ....
 $ openssl req -new -x509 -newkey rsa:2048 -sha256 -key jetty.key -out jetty.crt
 ....
@@ -201,6 +206,7 @@ passwords to protect both the keystore and the keys within it. The only
 mandatory response is to provide the fully qualified host name of the
 server at the "Common Name" prompt. For example:
 
+[source, screen]
 ....
 $ openssl genrsa -aes128 -out jetty.key
 Generating RSA private key, 2048 bit long modulus
@@ -267,6 +273,7 @@ request (CSR).
 The following command generates the file `jetty.csr` using `keytool` for
 a key/cert already in the keystore:
 
+[source, screen]
 ....
 $ keytool -certreq -alias jetty -keystore keystore -file jetty.csr
 ....
@@ -277,6 +284,7 @@ $ keytool -certreq -alias jetty -keystore keystore -file jetty.csr
 The following command generates the file `jetty.csr` using OpenSSL for a
 key in the file `jetty.key`:
 
+[source, screen]
 ....
 $ openssl req -new -key jetty.key -out jetty.csr
 ....
@@ -332,6 +340,7 @@ Rcz6oCRvCGCe5kDB
 The following command loads a PEM encoded certificate in the `jetty.crt`
 file into a JSSE keystore:
 
+[source, screen]
 ....
 $ keytool -keystore keystore -import -alias jetty -file jetty.crt -trustcacerts
 ....
@@ -340,6 +349,7 @@ If the certificate you receive from the CA is not in a format that
 `keytool` understands, you can use the `openssl` command to convert
 formats:
 
+[source, screen]
 ....
 $ openssl x509 -in jetty.der -inform DER -outform PEM -out jetty.crt
 ....
@@ -355,6 +365,7 @@ in response to your CSR.
 The following OpenSSL command combines the keys in `jetty.key` and the
 certificate in the `jetty.crt` file into the `jetty.pkcs12` file:
 
+[source, screen]
 ....
 $ openssl pkcs12 -inkey jetty.key -in jetty.crt -export -out jetty.pkcs12
 ....
@@ -362,6 +373,7 @@ $ openssl pkcs12 -inkey jetty.key -in jetty.crt -export -out jetty.pkcs12
 If you have a chain of certificates, because your CA is an intermediary,
 build the PKCS12 file as follows:
 
+[source, screen]
 ....
 $ cat example.crt intermediate.crt [intermediate2.crt] ... rootCA.crt > cert-chain.txt
 $ openssl pkcs12 -export -inkey example.key -in cert-chain.txt -out example.pkcs12
@@ -374,6 +386,7 @@ OpenSSL asks for an __export password__. A non-empty password is
 required to make the next step work. Then load the resulting PKCS12 file
 into a JSSE keystore with `keytool`:
 
+[source, screen]
 ....
 $ keytool -importkeystore -srckeystore jetty.pkcs12 -srcstoretype PKCS12 -destkeystore keystore
 ....

jetty-documentation/src/main/asciidoc/configuring/connectors/setting-port80-access-for-non-root-user.adoc

@@ -31,6 +31,7 @@ On some Linux systems you can use the _ipchains REDIRECT_ mechanism to
 redirect from one port to another inside the kernel (if ipchains is not
 available, then usually iptables is):
 
+[source, screen]
 ....
 # /sbin/ipchains -I input --proto TCP --dport 80 -j REDIRECT 8080
 ....
@@ -54,6 +55,7 @@ available, then usually ipchains is).
 You need to add something like the following to the startup scripts or
 your firewall rules:
 
+[source, screen]
 ....
 # /sbin/iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
 ....
@@ -92,6 +94,7 @@ the http port] to 80 (and link:#quickstart-changing-https-port[changed
 the https port] to 443 if you are using SSL).
 3.  Enable the setuid.mod module:
 +
+[source, screen]
 ....
 # java -jar start.jar --add-to-start=setuid
 ....
@@ -127,6 +130,7 @@ https://github.com/eclipse/jetty.toolchain/jetty-setuid[jetty-setuid]
 project. Build it locally, which will produce a native library
 appropriate for the operating system:
 +
+[source, screen]
 ....
 # mvn clean install
 ....
@@ -142,6 +146,7 @@ location of the native library to java. Here's an example of how to do
 it on the command line, assuming were are in the
 link:#demo-webapps-base[demo-base] directory:
 +
+[source, screen]
 ....
 # sudo java -Djava.library.path=libsetuid-linux -jar $JETTY_HOME/start.jar
 ....
@@ -152,6 +157,7 @@ link:#demo-webapps-base[demo-base] directory:
 Solaris 10 provides a User Rights Management framework that can permit
 users and processes superuser-like abilities:
 
+[source, screen]
 ....
 usermod -K defaultpriv=basic,net_privaddr myself
 ....

jetty-documentation/src/main/asciidoc/configuring/contexts/serving-webapp-from-particular-port.adoc

@@ -66,6 +66,7 @@ include::{SRCDIR}/examples/embedded/src/main/resources/jetty-otherserver.xml[]
 To run the other server, simply add the extra configuration file(s) to
 the command line:
 
+[source, screen]
 ....
 java -jar start.jar jetty-otherserver.xml
 ....

jetty-documentation/src/main/asciidoc/configuring/deploying/overlay-deployer.adoc

@@ -88,6 +88,7 @@ demonstration are available in overlays-demo.tar.gz. You can expand it
 on top of the jetty distribution; this tutorial expands it to /tmp and
 installs the components step-by-step:
 
+[source, screen]
 ....
 
 $ cd /tmp
@@ -122,6 +123,7 @@ The smarts of this are in etc/jetty-deploy.xml, which installs the
 OverlayedAppProvider into the DeploymentManager. You can then start
 Jetty normally:
 
+[source, screen]
 ....
 
 $ java -jar start.jar
@@ -143,6 +145,7 @@ You can download and deploy the WAR file for this demo using the
 following commands, which essentially downloads and extracts the WAR
 file to the $JETTY_HOME/overlays/webapps directory.
 
+[source, screen]
 ....
 
 $ cd /tmp
@@ -179,6 +182,7 @@ the web application for all instances you plan to deploy.
 You can install the demo template from the downloaded files with the
 command:
 
+[source, screen]
 ....
 
 $ mv $OVERLAYS/jtracTemplate\=jtrac-2.1.0 $JETTY_HOME/overlays/templates/
@@ -308,6 +312,7 @@ the configuration, which facilitates easy multi-tenant deployment.
 Now that you have installed a template, you can install one or more
 instance overlays to deploy the actual web applications:
 
+[source, screen]
 ....
 
 $ mv /tmp/overlays/instances/jtracTemplate\=blue $JETTY_HOME/overlays/instances/

jetty-documentation/src/main/asciidoc/configuring/deploying/quickstart-webapp.adoc

@@ -49,6 +49,7 @@ In a maven project this is done just by adding a dependency on the
 artifact ID jetty-quickstart or with a standard jetty distribution you
 can run the command:
 
+[source, screen]
 ....
 $ java -jar $JETTY_HOME/start.jar --add-to-startd=quickstart
 ....
@@ -60,7 +61,8 @@ web application already has a `webapps/myapp.xml` file, then you can
 simply change the class in the Configure element, otherwise you can
 create an `webapps/myapp.xml` file as follows:
 
-....
+[source, xml]
+____
 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_0.dtd">
 <Configure class="org.eclipse.jetty.quickstart.QuickStartWebApp">
@@ -68,7 +70,7 @@ create an `webapps/myapp.xml` file as follows:
   <Set name="contextPath">/benchmark</Set>
   <Set name="autoPreconfigure">true</Set>
 </Configure>
-....
+____
 
 ==== Preconfiguring the web application
 
@@ -84,6 +86,7 @@ class
 link:{JDURL}/org/eclipse/jetty/quickstart/PreconfigureQuickStartWar.html[org.eclipse.jetty.quickstart.PreconfigureQuickStartWar]
 simply with the jetty-all-uber (aggregate) jar:
 
+[source, screen]
 ....
 $ java -cp jetty-all-@project.version@-uber.jar org.eclipse.jetty.quickstart.PreconfigureQuickStartWar myapp.war
 ....
@@ -103,12 +106,13 @@ scan to be skipped. This can be done by adding a context-param to the
 `web.xml` file (this is done automatically by the Jetty Maven JSPC
 plugin):
 
-....
+[source, xml]
+____
 <context-param>
   <param-name>org.eclipse.jetty.jsp.precompiled</param-name>
   <param-value>true</param-value>
 </context-param>
-....
+____
 
 ==== Bypassing start.jar
 
@@ -119,6 +123,7 @@ the classpath. The start.jar mechanism can be bypassed by using the
 `–dry-run` option to generate and reuse a complete command line to start
 jetty at a later time:
 
+[source, screen]
 ....
 $ RUN=$(java -jar $JETTY_HOME/start.jar --dry-run)
 $ eval $RUN

jetty-documentation/src/main/asciidoc/configuring/security/jetty-home-and-jetty-base.adoc

@@ -61,12 +61,14 @@ This example assumes you have the jetty-distribution unpacked in
 
 1.  Create a base directory anywhere.
 +
+[source, screen]
 ....
 [/home/user]$ mkdir my-base
 [/home/user]$ cd my-base
 ....
 2.  Add the modules for SSL, HTTP, and webapp deployment.
 +
+[source, screen]
 ....
 [my-base]$ java -jar /home/user/jetty-distribution-@project.version@/start.jar --add-to-start=http,https,deploy
 
@@ -85,6 +87,7 @@ server          enabled in     ${jetty.base}/start.ini
 ....
 3.  Look at your directory.
 +
+[source, screen]
 ....
 [my-base]$ ls -la
 total 20
@@ -96,17 +99,20 @@ drwxrwxr-x   2 user group 4096 Oct  8 06:55 webapps/
 ....
 4.  Copy your WAR files into webapps.
 +
+[source, screen]
 ....
 [my-base]$ ls -la
 [my-base]$ cp ~/code/project/target/gadget.war webapps/
 ....
 5.  Copy your keystore into place.
 +
+[source, screen]
 ....
 [my-base]$ cp ~/code/project/keystore etc/keystore
 ....
 6.  Edit the `start.ini` to configure your SSL settings.
 +
+[source, screen]
 ....
 [my-base]$ cat start.ini
 ....
@@ -159,6 +165,7 @@ http.timeout=30000
 
 Look at the configuration you have at this point.
 
+[source, screen]
 ....
 [my-base]$ java -jar /home/user/jetty-distribution-@project.version@/start.jar --list-config
 
@@ -231,6 +238,7 @@ Jetty Active XMLs:
 
 Now start Jetty.
 
+[source, screen]
 ....
 [my-base]$ java -jar /home/user/jetty-distribution-@project.version@/start.jar
 2013-10-08 07:06:55.837:INFO:oejs.Server:main: jetty-@project.version@
@@ -260,6 +268,7 @@ a single unit, with dependencies on other modules.
 
 You can see the list of modules:
 
+[source, screen]
 ....
 [my-base]$ java -jar /home/user/jetty-distribution-@project.version@/start.jar --list-modules
 
@@ -449,6 +458,7 @@ easier to edit the `${jetty.base}/start.ini`.
 
 If you want to start using a new module:
 
+[source, screen]
 ....
 [my-base] $ java -jar ../jetty-distribution-@project.version@/start.jar --add-to-start=https
 ....
@@ -487,6 +497,7 @@ For more information on the `start.jar` in 9.1, see xref:start-jar[].
 `/home/user/jetty-distribution-@project.version@`.
 2.  Go to your base directory and just use the distribution, no editing.
 +
+[source, screen]
 ....
 [my-base]$ java -jar /home/user/jetty-distribution-@project.version@/start.jar
 ....
@@ -518,6 +529,7 @@ modules as well.
 You can see what the configuration looks like, after all of the modules
 are resolved, without starting Jetty via:
 
+[source, screen]
 ....
 [my-base] $ java -jar ../jetty-distribution-@project.version@/start.jar --list-config
 ....
@@ -529,6 +541,7 @@ Use the `--list-config` to see the configuration. Notice that only a
 subset of the JARs from the distribution are in use. The modules you
 have anabled determine that subset.
 
+[source, screen]
 ....
 [my-base]$ java -jar ~/jetty-distribution-@project.version@/start.jar --list-config
 ....

jetty-documentation/src/main/asciidoc/configuring/security/secure-passwords.adoc

@@ -38,6 +38,7 @@ generate all varieties of passwords.
 
 Run it without arguments to see usage instructions:
 
+[source, screen]
 ....
 
 $ export JETTY_VERSION=9.0.0-SNAPSHOT
@@ -52,6 +53,7 @@ If the password is ?, the user will be prompted for the password
 For example, to generate a secured version of the password "blah" for
 the user "me", do:
 
+[source, screen]
 ....
 
 $ export JETTY_VERSION=9.0.0.RC0

jetty-documentation/src/main/asciidoc/configuring/security/spnego-support.adoc

@@ -142,6 +142,7 @@ for the http server. To do this use a process similar to this:
 
 On the windows active domain controller run:
 
+[source, screen]
 ....
 
 $ setspn -A HTTP/linux.mortbay.org ADUser
@@ -151,6 +152,7 @@ $ setspn -A HTTP/linux.mortbay.org ADUser
 
 To create the keytab file use the following process:
 
+[source, screen]
 ....
 
 $ ktpass -out c:\dir\krb5.keytab -princ HTTP/linux.mortbay.org@MORTBAY.ORG -mapUser ADUser -mapOp set -pass ADUserPWD -crypto RC4-HMAC-NT -pType KRB5_NT_PRINCIPAL

jetty-documentation/src/main/asciidoc/development/ant/jetty-ant.adoc

@@ -98,6 +98,7 @@ This is the minimal configuration you need. You can now start Jetty on the defau
 
 At the command line enter:
 
+[source, screen]
 ....
 > ant jetty.run
 ....
@@ -345,6 +346,7 @@ stopping:::
 +
 To stop jetty via Ant, enter:
 +
+[source, screen]
 ....
 > ant jetty.stop
 ....

jetty-documentation/src/main/asciidoc/development/debugging/enable-remote-debugging.adoc

@@ -36,6 +36,7 @@ Assuming you have your webapp deployed into jetty, there are two different ways
 Via command line::
   Add the required parameters on the commandline like so.
 +
+[source, screen]
 ....
                             
 $ java -Xdebug -agentlib:jdwp=transport=dt_socket,address=9999,server=y,suspend=n -jar start.jar

jetty-documentation/src/main/asciidoc/development/embedding/jetty-helloworld.adoc

@@ -34,6 +34,7 @@ ____
 
 Use curl as follows:
 
+[source, screen]
 ....
 > mkdir Demo
 > cd Demo
@@ -57,6 +58,7 @@ include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/Hel
 
 The following command compiles the HelloWorld class:
 
+[source, screen]
 ....
 > mkdir classes
 > javac -d classes -cp jetty-all-uber.jar HelloWorld.java
@@ -67,6 +69,7 @@ The following command compiles the HelloWorld class:
 
 The following command runs the HelloWorld example:
 
+[source, screen]
 ....
 > java -cp classes:jetty-all-uber.jar org.eclipse.jetty.embedded.HelloWorld
 ....

jetty-documentation/src/main/asciidoc/development/frameworks/metro.adoc

@@ -41,6 +41,7 @@ The Metro distribution you downloaded should also contain several example web ap
 
 Here's an example of the log output from Jetty when one of the sample Metro wars (from `$metro.home/samples/async`) is deployed to Jetty:
 
+[source, screen]
 ....
 [2093] java -jar start.jar
 

jetty-documentation/src/main/asciidoc/development/frameworks/spring-usage.adoc

@@ -26,6 +26,7 @@ If you want to replace the jetty-xml being used to start the normal Jetty distri
 The skeleton of a jetty spring module can be enabled from the jetty-distribution via the link:#startup-modules[module mechanism].
 For example:
 
+[source, screen]
 ....
 $ java -jar start.jar --add-to-startd=spring
 ....

jetty-documentation/src/main/asciidoc/development/frameworks/weld.adoc

@@ -43,6 +43,7 @@ The easiest way to configure weld is within the jetty distribution itself:
 
 That should be it so when you start up your jetty distribution with the webapp you should see output similar to the following (providing your logging is the default configuration):
 
+[source, screen]
 ....
 2015-06-18 12:13:54.924:INFO::main: Logging initialized @485ms
 2015-06-18 12:13:55.231:INFO:oejs.Server:main: jetty-9.3.1-SNAPSHOT

jetty-documentation/src/main/asciidoc/development/maven/jetty-jspc-maven-plugin.adoc

@@ -171,6 +171,7 @@ For example, the following profile will only be invoked if the flag `-Dprod` is
 
 So, the following invocation would cause your code to be compiled, the jsps to be compiled, the <servlet> and <servlet-mapping>s inserted in the web.xml and your webapp assembled into a war:
 
+[source, screen]
 ....
 
 $ mvn -Dprod package

jetty-documentation/src/main/asciidoc/development/maven/jetty-maven-helloworld.adoc

@@ -36,6 +36,7 @@ To understand the basic operations of building and running against Jetty, first
 Maven uses convention over configuration, so it is best to use the project structure Maven recommends.
 You can use _link:#archetypes[http://maven.apache.org/guides/introduction/introduction-to-archetypes.html[archetypes]]_ to quickly setup Maven projects, but we will set up the structure manually for this simple tutorial example:
 
+[source, screen]
 ....
 > mkdir JettyMavenHelloWorld
 > cd JettyMavenHelloWorld
@@ -141,6 +142,7 @@ Use an editor to create the file `pom.xml` with the following contents:
 
 You can now compile and execute the HelloWorld class by using these commands:
 
+[source, screen]
 ....
 > mvn clean compile exec:java  
 ....
@@ -148,6 +150,7 @@ You can now compile and execute the HelloWorld class by using these commands:
 You can point your browser to `http://localhost:8080` to see the hello world page.
 You can observe what Maven is doing for you behind the scenes by using the `mvn dependency:tree` command, which reveals the transitive dependency resolved and downloaded as:
 
+[source, screen]
 ....
 > mvn dependency:tree
 [INFO] Scanning for projects...
@@ -180,6 +183,7 @@ The previous section demonstrated how to use Maven with an application that embe
 Now we will examine instead how to develop a standard webapp with Maven and Jetty.
 First create the Maven structure (you can use the maven webapp archetype instead if you prefer):
 
+[source, screen]
 ....
 > mkdir JettyMavenHelloWarApp
 > cd JettyMavenHelloWebApp
@@ -288,6 +292,7 @@ Use an editor to create the file `pom.xml` with the following contents, noting p
 
 Now you can both build and run the web application without needing to assemble it into a war by using the link:#jetty-maven-plugin[jetty-maven-plugin] via the command:
 
+[source, screen]
 ....
 > mvn jetty:run
 ....
@@ -302,6 +307,7 @@ The full reference is at link:#jetty-maven-plugin[Configuring the Jetty Maven Pl
 
 You can create a Web Application Archive (WAR) file from the project with the command:
 
+[source, screen]
 ....
 > mvn package    
 ....

jetty-documentation/src/main/asciidoc/development/maven/jetty-maven-plugin.adoc

@@ -50,6 +50,7 @@ First, add `jetty-maven-plugin` to your `pom.xml` definition:
 
 Then, from the same directory as your root `pom.xml`, type:
 
+[source, screen]
 ....
 mvn jetty:run
 ....
@@ -77,12 +78,14 @@ There are different goals to accomplish these tasks, as well as several others.
 
 To see a list of all goals supported by the Jetty Maven plugin, do:
 
+[source, screen]
 ....
 mvn jetty:help
 ....
 
 To see the detailed list of parameters that can be configured for a particular goal, in addition to its description, do:
 
+[source, screen]
 ....
 mvn jetty:help -Ddetail=true -Dgoal= goal-name
 ....
@@ -628,6 +631,7 @@ systemProperties::
 
 To deploy your unassembled web app to Jetty running in a new JVM:
 
+[source, screen]
 ....
 mvn jetty:run-forked
 ....
@@ -726,6 +730,7 @@ Here's a configuration example:
 
 Then, while Jetty is running (in another window), type:
 
+[source, screen]
 ....
 mvn jetty:stop
 ....

jetty-documentation/src/main/asciidoc/quick-start/getting-started/jetty-coordinates.adoc

@@ -20,10 +20,10 @@
 ==== Maven Coordinates
 
 Jetty has existed in Maven Central almost since its inception, however under a couple of different coordinates over the years. 
-When Jetty was based at SourceForge and then The Codehaus it was located under the groupId of `org.mortbay.jetty`. 
+When Jetty was based at SourceForge and then The Codehaus it was located under the `groupId` of `org.mortbay.jetty`. 
 With Jetty 7 the project moved to the Eclipse foundation and to a new `groupId` at that time to reflect its new home.
 
-The top level POM for the Jetty project is located under the following coordinates.
+The top level Project Object Model (POM) for the Jetty project is located under the following coordinates.
 
 [source,xml]
 ----

jetty-documentation/src/main/asciidoc/quick-start/getting-started/jetty-running.adoc

@@ -19,6 +19,7 @@
 
 To start Jetty on the default port of 8080, run the following command:
 
+[source, screen]
 ....
 > cd $JETTY_HOME
 > java -jar start.jar
@@ -40,6 +41,7 @@ Instead, see how to link:#creating-jetty-base[create a Jetty Base] below.
 
 Within the standard jetty distribution there is the `demo-base` directory, which demonstrates the recommended way to run Jetty in a directory separately from $JETTY_HOME:
 
+[source, screen]
 ....
 > cd $JETTY_HOME/demo-base/
 > java -jar $JETTY_HOME/start.jar
@@ -75,6 +77,7 @@ ____
 
 You can see the configuration of the demo-base by using the following commands:
 
+[source, screen]
 ....
 > cd $JETTY_HOME/demo-base/
 > java -jar $JETTY_HOME/start.jar --list-modules
@@ -97,6 +100,7 @@ jetty.base::
 
 The `jetty.home` and `jetty.base` properties may be explicitly set on the command line, or they can be inferred from the environment if used with commands like:
 
+[source, screen]
 ....
 > cd $JETTY_BASE
 > java -jar $JETTY_HOME/start.jar
@@ -104,6 +108,7 @@ The `jetty.home` and `jetty.base` properties may be explicitly set on the comman
 
 The following commands: create a new base directory; enables a HTTP connector and the web application deployer; copies a demo webapp to be deployed:
 
+[source, screen]
 ....
 > JETTY_BASE=/tmp/mybase
 > mkdir $JETTY_BASE
@@ -140,6 +145,7 @@ INFO: Base directory was modified
 
 You can configure Jetty to run on a different port by setting the `jetty.http.port` Property on the command line:
 
+[source, screen]
 ....
 > cd $JETTY_BASE
 > java -jar $JETTY_HOME/start.jar jetty.http.port=8081
@@ -151,13 +157,15 @@ By default, the jetty distribution defines the jetty.http.port property in the `
 
 ____
 [NOTE]
+--
 The configuration by properties works via the following chain:
-+
+
 * The start.d/http.ini file is part of the effective command line and contains the --module=http argument which activates the http module.
 * The modules/http.mod file defines the http module which specifies the etc/jetty-http.xml configuration file and the template ini properties it uses.
 * The jetty.http.port property is used by the Property XML element in etc/jetty.http.xml to inject the ServerConnector instance with the port.
-+
+
 For more information see the link:#quickstart-config[Quickstart Configuration Guide] and link:#configuring-connectors[Configuring Connectors].
+--
 ____
 
 [[quickstart-starting-https]]
@@ -165,6 +173,7 @@ ____
 
 To add the HTTPS connector to a jetty configuration, the https module can be activated by the following command:
 
+[source, screen]
 ....
 > java -jar $JETTY_HOME/start.jar --add-to-startd=https,http2
 [...]
@@ -192,6 +201,7 @@ ____
 
 You can configure the SSL connector to run on a different port by setting the `jetty.ssl.port` property on the command line:
 
+[source, screen]
 ....
 > cd $JETTY_BASE
 > java -jar $JETTY_HOME/start.jar jetty.ssl.port=8444
@@ -206,6 +216,7 @@ If you used --add-to-start command, then you can edit this property in the start
 The job of the `start.jar` is to interpret the command line, `start.ini` and `start.d` to build a Java classpath and list of properties and configuration files to pass to the main class of the Jetty XML configuration mechanism. 
 The `start.jar` mechanism has many options which are documented in the xref:startup[] administration section and you can see them in summary by using the command:
 
+[source, screen]
 ....
 > java -jar $JETTY_HOME/start.jar --help
 ....

jetty-documentation/src/main/asciidoc/reference/contributing/documentation.adoc

@@ -50,6 +50,7 @@ First you need to obtain the source of the documentation project.
 
 Clone the repository:
 
+[source, screen]
 ....
 $ git clone https://github.com/eclipse/jetty.project.git
 ....
@@ -57,6 +58,7 @@ $ git clone https://github.com/eclipse/jetty.project.git
 You will now have a local directory with all of jetty, including the jetty-documentation.
 Now we move on to building it.
 
+[source, screen]
 ....
 $ cd jetty.project/jetty-documentation 
 $ mvn install
@@ -68,6 +70,7 @@ This build will first produce docbook xml and then through the docbkx-maven-plug
 The downloads are all of the java dependencies that are required to make this build work. 
 After a while the downloading will stop and you should see the execution of the asciidoctor-maven-plugin followed by the docbkx-maven-plugin.
 
+[source, screen]
 ....
 [INFO] --- asciidoctor-maven-plugin:1.5.3:process-asciidoc (output-html) @ jetty-documentation ---
 [INFO] Rendered /Users/jesse/src/projects/jetty/jetty-docs/src/main/asciidoc/index.adoc
@@ -81,6 +84,7 @@ After a while the downloading will stop and you should see the execution of the
 
 The build is finished once you see a message akin to this:
 
+[source, screen]
 ....
 [INFO] ------------------------------------------------------------------------
 [INFO] BUILD SUCCESS
@@ -120,6 +124,7 @@ Now follow the process to push that change back into Jetty proper.
 Do make sure the change works and the build isn't broken though so make sure you run maven and check the output.
 Then commit the change.
 
+[source, screen]
 ....
 $ git commit -s -m "Tweaked the introduction to fix a horrid misspelled word." src/main/asciidoc/quickstart/introduction/topic.xml  
 ....
@@ -133,6 +138,7 @@ ____
 This will commit the change in your local repository. 
 You can then push the change up to your repository on github.
 
+[source, screen]
 ....
 $ git push
 ....

jetty-documentation/src/main/asciidoc/reference/contributing/release-testing.adoc

@@ -21,6 +21,7 @@ To test a Jetty release, complete the following steps for each release you want
 
 1.  Download the staged release:
 +
+[source, screen]
 ....
 
  wget https://oss.sonatype.org/content/repositories/jetty-[reponumber]/org/eclipse/jetty/jetty-distribution/[jetty-version]/jetty-distribution-9.[jetty-minor-version].tar.gz
@@ -30,6 +31,7 @@ To test a Jetty release, complete the following steps for each release you want
 2.  Extract to a directory of your choice.
 3.  Start jetty:
 +
+[source, screen]
 ....
 
  cd [installdir] ; java -jar start.jar
@@ -44,6 +46,7 @@ To test a Jetty release, complete the following steps for each release you want
 9.  In the examples section click "Servlet 3.1 Test" and verify that everything works as expected.
 10. Verify that hot deployment works.
 +
+[source, screen]
 ....
 
  cd [installdir] ;
@@ -54,6 +57,7 @@ To test a Jetty release, complete the following steps for each release you want
 11. Verify that `test.war` gets redeployed in `STDOUT`.
 12. Verify that the spdy example webapp and spdy-proxy do work
 +
+[source, screen]
 ....
 
  cd jetty_src/jetty-spdy/spdy-example-webapp
@@ -64,6 +68,7 @@ To test a Jetty release, complete the following steps for each release you want
 13. Browse to https://localhost:8443 and verify that all looks ok
 14. Stop the server with CTRL+C and restart it in proxy mode:
 +
+[source, screen]
 ....
 
  mvn -Pproxy jetty:run-forked
@@ -77,6 +82,7 @@ To test a Jetty release, complete the following steps for each release you want
 
 1.  Clone CometD.
 +
+[source, screen]
 ....
 
  clone git://github.com/cometd/cometd.git
@@ -106,6 +112,7 @@ To test a Jetty release, complete the following steps for each release you want
 ....
 3.  Build Cometd:
 +
+[source, screen]
 ....
 
  mvn clean install
@@ -119,6 +126,7 @@ Run the loadtest until ''JIT compilation time'' is close to a value of zero (abo
 6.  Make sure that the performance results are reasonably fast.
 On a MacBook Pro i7 2.6ghz dualcore produces the following:
 +
+[source, screen]
 ....
 
  ========================================
@@ -192,6 +200,7 @@ Thread Pool - Concurrent Threads max = 239 | Queue Size max = 1002 | Queue Laten
 ....
 7.  Deploy `cometd.war` to the `webapps` directory of the jetty-distribution tested above.
 +
+[source, screen]
 ....
 
  cp cometd-demo/target/cometd-demo-[version].war [pathToJetty]/jetty-distribution-[jetty-version]/webapps/
@@ -200,6 +209,7 @@ Thread Pool - Concurrent Threads max = 239 | Queue Size max = 1002 | Queue Laten
 ....
 8.  Start jetty and make sure there are no exceptions.
 +
+[source, screen]
 ....
 
  cd [pathToJetty] && java -jar start.jar

jetty-documentation/src/main/asciidoc/reference/contributing/releasing-jetty.adoc

@@ -40,6 +40,7 @@ Tag Name                       : jetty-9.9.0.v20130322
 ....
 2.  We use the 'release-9' branch to avoid problems with other developers actively working on the master branch.
 +
+[source, screen]
 ....
 
 // Get all of the remotes
@@ -56,6 +57,7 @@ $ git merge --no-ff master
 ....
 3.  Update the VERSION.txt with changes from the git logs, this populates the resolves issues since the last release.
 +
+[source, screen]
 ....
 
 $ mvn -N -Pupdate-version        
@@ -64,6 +66,7 @@ $ mvn -N -Pupdate-version
 ....
 4.  Edit the VERSION.txt file to set the 'Release Version' at the top alongside the Date of this release.
 +
+[source, screen]
 ....
 
 $ vi VERSION.txt        
@@ -72,6 +75,7 @@ $ vi VERSION.txt
 ....
 5.  Make sure everything is commit'd and pushed to github.com/eclipse/jetty.project
 +
+[source, screen]
 ....
 
 $ git commit -m "Updating VERSION.txt top section" VERSION.txt
@@ -84,6 +88,7 @@ $ git push origin release-9
 NOTE: This step updates the <version> elements in the pom.xml files, does a test build with these new versions, and then commits the pom.xml changes to your local git repo.
 The `eclipse-release` profile is required on the prepare in order to bring in the jetty aggregates as that profile defines a module which is ignored otherwise.
 +
+[source, screen]
 ....
 
 $ mvn release:prepare -DreleaseVersion=9.0.0.v20130322 \
@@ -97,6 +102,7 @@ $ mvn release:prepare -DreleaseVersion=9.0.0.v20130322 \
 +
 NOTE: This step performs the release and deploys it to a oss.sonatype.org staging repository.
 +
+[source, screen]
 ....
 
 $ mvn release:perform
@@ -110,6 +116,7 @@ Do not date this line.
 +
 Make sure everything is commit'd and pushed to github.com/eclipse/jetty.project
 +
+[source, screen]
 ....
 
 $ vi VERSION.txt
@@ -125,6 +132,7 @@ $ git push origin release-9
 * Release the staging repository to maven central on oss.sonatype.org
 * Merge back the changes in release-9 to master
 +
+[source, screen]
 ....
 
 $ git checkout master
@@ -143,6 +151,7 @@ If you don't know if you have access to this then you probably don't and will ne
 
 To build and deploy the aggregate javadoc and jxr bits:
 
+[source, screen]
 ....
 
 $ cd target/checkout
@@ -170,6 +179,7 @@ To localize the scripts to your environment:
 
 Once these are setup you can deploy a release to eclipse with the following incantation:
 
+[source, screen]
 ....
 
 $ ./promote-to-eclipse.sh 9.0.0.v20130322
@@ -185,6 +195,7 @@ On the eclipse side of it they will also adjust the xref and javadoc documentati
 Since we are not allowed to have symbolic links on the download site we have to log into the machine manually and remove the previous stable directory and update it with a new release.
 Maintaining the conventions we use on the site will allow all 'stable' links to be stable and not needed to update to the latest major Jetty build version:
 
+[source, screen]
 ....
 
 $ ssh <user>@build.eclipse.org
@@ -198,6 +209,7 @@ $ ./index.sh
 
 This needs to be done for all Eclipse Jetty releases (regardless of version). In addition we have to work to reduce the footprint of jetty on the primary eclipse download resources so we want to move older releases to the eclipse archive site.
 
+[source, screen]
 ....
 
 $ cd ~/downloads/jetty

jetty-documentation/src/main/asciidoc/reference/contributing/source-build.adoc

@@ -53,6 +53,7 @@ Jetty uses http://maven.apache.org/[Apache Maven 3] for managing its build and p
 
 Building Jetty should simply be a matter of changing into the relevant directory and executing the following commands:
 
+[source, screen]
 ....
 
 $ git clone https://github.com/eclipse/jetty.project.git

jetty-documentation/src/main/asciidoc/reference/platforms/cloudfoundry.adoc

@@ -44,6 +44,7 @@ For the time being I'll leave this buildpack under my personal github account an
 To show how incredibly easy it is to use the Jetty buildpack with cloudfoundry, this is all the more you need to do to deploy your application.
 Refer to the CloudFoundry http://docs.cloudfoundry.com/[documentation] to get started, get the `cf` utilities installed and an environment configured.
 
+[source, screen]
 ....
 $ cf push snifftest --buildpack=git://github.com/jmcc0nn3ll/jetty-buildpack.git
 

jetty-documentation/src/main/docbkx-resources/css/highlighter/darkula.css

@@ -0,0 +1,152 @@
+/*
+
+Darkula color scheme from the JetBrains family of IDEs
+
+*/
+
+
+.hljs {
+  display: block;
+  overflow-x: auto;
+  padding: 0.5em;
+  background: #2b2b2b;
+  -webkit-text-size-adjust: none;
+}
+
+.hljs,
+.hljs-tag,
+.hljs-title,
+.css .hljs-rule,
+.css .hljs-value,
+.aspectj .hljs-function,
+.css .hljs-function .hljs-preprocessor,
+.hljs-pragma {
+  color: #bababa;
+}
+
+.hljs-strongemphasis,
+.hljs-strong,
+.hljs-emphasis {
+  color: #a8a8a2;
+}
+
+.hljs-bullet,
+.hljs-blockquote,
+.hljs-horizontal_rule,
+.hljs-number,
+.hljs-regexp,
+.alias .hljs-keyword,
+.hljs-literal,
+.hljs-hexcolor {
+  color: #6896ba;
+}
+
+.hljs-tag .hljs-value,
+.hljs-code,
+.css .hljs-class,
+.hljs-class .hljs-title:last-child {
+  color: #a6e22e;
+}
+
+.hljs-link_url {
+  font-size: 80%;
+}
+
+.hljs-emphasis,
+.hljs-strongemphasis,
+.hljs-class .hljs-title:last-child,
+.hljs-typename {
+  font-style: italic;
+}
+
+.hljs-keyword,
+.ruby .hljs-class .hljs-keyword:first-child,
+.ruby .hljs-function .hljs-keyword,
+.hljs-function,
+.hljs-change,
+.hljs-winutils,
+.hljs-flow,
+.nginx .hljs-title,
+.tex .hljs-special,
+.hljs-header,
+.hljs-attribute,
+.hljs-symbol,
+.hljs-symbol .hljs-string,
+.hljs-tag .hljs-title,
+.hljs-value,
+.alias .hljs-keyword:first-child,
+.css .hljs-tag,
+.css .unit,
+.css .hljs-important {
+  color: #cb7832;
+}
+
+.hljs-function .hljs-keyword,
+.hljs-class .hljs-keyword:first-child,
+.hljs-aspect .hljs-keyword:first-child,
+.hljs-constant,
+.hljs-typename,
+.css .hljs-attribute {
+  color: #cb7832;
+}
+
+.hljs-variable,
+.hljs-params,
+.hljs-class .hljs-title,
+.hljs-aspect .hljs-title {
+  color: #b9b9b9;
+}
+
+.hljs-string,
+.css .hljs-id,
+.hljs-subst,
+.hljs-type,
+.ruby .hljs-class .hljs-parent,
+.hljs-built_in,
+.django .hljs-template_tag,
+.django .hljs-variable,
+.smalltalk .hljs-class,
+.django .hljs-filter .hljs-argument,
+.smalltalk .hljs-localvars,
+.smalltalk .hljs-array,
+.hljs-attr_selector,
+.hljs-pseudo,
+.hljs-addition,
+.hljs-stream,
+.hljs-envvar,
+.apache .hljs-tag,
+.apache .hljs-cbracket,
+.tex .hljs-command,
+.hljs-prompt,
+.hljs-link_label,
+.hljs-link_url,
+.hljs-name {
+  color: #e0c46c;
+}
+
+.hljs-comment,
+.hljs-annotation,
+.hljs-pi,
+.hljs-doctype,
+.hljs-deletion,
+.hljs-shebang,
+.apache .hljs-sqbracket,
+.tex .hljs-formula {
+  color: #7f7f7f;
+}
+
+.hljs-decorator {
+  color: #bab429;
+}
+
+.coffeescript .javascript,
+.javascript .xml,
+.tex .hljs-formula,
+.xml .javascript,
+.xml .vbscript,
+.xml .css,
+.xml .hljs-cdata,
+.xml .php,
+.php .xml {
+  opacity: 0.5;
+}

jetty-documentation/src/main/docbkx-resources/css/highlighter/foundation.css

@@ -0,0 +1,135 @@
+/*
+Description: Foundation 4 docs style for highlight.js
+Author: Dan Allen <dan.j.allen@gmail.com>
+Website: http://foundation.zurb.com/docs/
+Version: 1.0
+Date: 2013-04-02
+*/
+
+.hljs {
+  display: block;
+  overflow-x: auto;
+  padding: 0.5em;
+  background: #eee;
+  -webkit-text-size-adjust: none;
+}
+
+.hljs-header,
+.hljs-decorator,
+.hljs-annotation {
+  color: #000077;
+}
+
+.hljs-horizontal_rule,
+.hljs-link_url,
+.hljs-emphasis,
+.hljs-attribute {
+  color: #070;
+}
+
+.hljs-emphasis {
+  font-style: italic;
+}
+
+.hljs-link_label,
+.hljs-strong,
+.hljs-value,
+.hljs-string,
+.scss .hljs-value .hljs-string {
+  color: #d14;
+}
+
+.hljs-strong {
+  font-weight: bold;
+}
+
+.hljs-blockquote,
+.hljs-comment {
+  color: #998;
+  font-style: italic;
+}
+
+.asciidoc .hljs-title,
+.hljs-function .hljs-title {
+  color: #900;
+}
+
+.hljs-class {
+  color: #458;
+}
+
+.hljs-id,
+.hljs-pseudo,
+.hljs-constant,
+.hljs-hexcolor {
+  color: teal;
+}
+
+.hljs-variable {
+  color: #336699;
+}
+
+.hljs-bullet {
+  color: #997700;
+}
+
+.hljs-pi,
+.hljs-doctype {
+  color: #3344bb;
+}
+
+.hljs-code,
+.hljs-number {
+  color: #099;
+}
+
+.hljs-important {
+  color: #f00;
+}
+
+.smartquote,
+.hljs-label {
+  color: #970;
+}
+
+.hljs-preprocessor,
+.hljs-pragma {
+  color: #579;
+}
+
+.hljs-reserved,
+.hljs-keyword,
+.scss .hljs-value {
+  color: #000;
+}
+
+.hljs-regexp {
+  background-color: #fff0ff;
+  color: #880088;
+}
+
+.hljs-symbol {
+  color: #990073;
+}
+
+.hljs-symbol .hljs-string {
+  color: #a60;
+}
+
+.hljs-tag {
+  color: #007700;
+}
+
+.hljs-at_rule,
+.hljs-at_rule .hljs-keyword {
+  color: #088;
+}
+
+.hljs-at_rule .hljs-preprocessor {
+  color: #808;
+}
+
+.scss .hljs-tag,
+.scss .hljs-attribute {
+  color: #339;
+}

jetty-documentation/src/main/docbkx-resources/css/highlighter/zenburn.css

@@ -0,0 +1,118 @@
+/*
+
+Zenburn style from voldmar.ru (c) Vladimir Epifanov <voldmar@voldmar.ru>
+based on dark.css by Ivan Sagalaev
+
+*/
+
+.hljs {
+  display: block;
+  overflow-x: auto;
+  padding: 0.5em;
+  background: #3f3f3f;
+  color: #dcdcdc;
+  -webkit-text-size-adjust: none;
+}
+
+.hljs-keyword,
+.hljs-tag,
+.css .hljs-class,
+.css .hljs-id,
+.lisp .hljs-title,
+.nginx .hljs-title,
+.hljs-request,
+.hljs-status,
+.clojure .hljs-attribute {
+  color: #e3ceab;
+}
+
+.django .hljs-template_tag,
+.django .hljs-variable,
+.django .hljs-filter .hljs-argument {
+  color: #dcdcdc;
+}
+
+.hljs-number,
+.hljs-date {
+  color: #8cd0d3;
+}
+
+.dos .hljs-envvar,
+.dos .hljs-stream,
+.hljs-variable,
+.apache .hljs-sqbracket,
+.hljs-name {
+  color: #efdcbc;
+}
+
+.dos .hljs-flow,
+.diff .hljs-change,
+.python .exception,
+.python .hljs-built_in,
+.hljs-literal,
+.tex .hljs-special {
+  color: #efefaf;
+}
+
+.diff .hljs-chunk,
+.hljs-subst {
+  color: #8f8f8f;
+}
+
+.dos .hljs-keyword,
+.hljs-decorator,
+.hljs-title,
+.hljs-type,
+.diff .hljs-header,
+.ruby .hljs-class .hljs-parent,
+.apache .hljs-tag,
+.nginx .hljs-built_in,
+.tex .hljs-command,
+.hljs-prompt {
+  color: #efef8f;
+}
+
+.dos .hljs-winutils,
+.ruby .hljs-symbol,
+.ruby .hljs-symbol .hljs-string,
+.ruby .hljs-string {
+  color: #dca3a3;
+}
+
+.diff .hljs-deletion,
+.hljs-string,
+.hljs-tag .hljs-value,
+.hljs-preprocessor,
+.hljs-pragma,
+.hljs-built_in,
+.smalltalk .hljs-class,
+.smalltalk .hljs-localvars,
+.smalltalk .hljs-array,
+.css .hljs-rule .hljs-value,
+.hljs-attr_selector,
+.hljs-pseudo,
+.apache .hljs-cbracket,
+.tex .hljs-formula,
+.coffeescript .hljs-attribute {
+  color: #cc9393;
+}
+
+.hljs-shebang,
+.diff .hljs-addition,
+.hljs-comment,
+.hljs-annotation,
+.hljs-pi,
+.hljs-doctype {
+  color: #7f9f7f;
+}
+
+.coffeescript .javascript,
+.javascript .xml,
+.tex .hljs-formula,
+.xml .javascript,
+.xml .vbscript,
+.xml .css,
+.xml .hljs-cdata {
+  opacity: 0.5;
+}
+

jetty-documentation/src/main/docbkx-stylesheet/html/docbook.xsl

@@ -77,7 +77,7 @@ xmlns:date="http://exslt.org/dates-and-times"
     -->
     <xsl:element name="link">
       <xsl:attribute name="rel">stylesheet</xsl:attribute>
-      <xsl:attribute name="href">css/highlighter/github.css</xsl:attribute>
+      <xsl:attribute name="href">css/highlighter/foundation.css</xsl:attribute>
     </xsl:element>
     <xsl:element name="script">
       <xsl:attribute name="src">js/highlight.pack.js</xsl:attribute>
@@ -157,7 +157,7 @@ xmlns:date="http://exslt.org/dates-and-times"
       </h5>
       <p>
  private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ...
- scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery
+ scalability guidance for your apps and Ajax/Comet projects ... development services for sponsored feature development
       </p>
    </div>
 
@@ -220,45 +220,29 @@ xmlns:date="http://exslt.org/dates-and-times"
     </script>
   </xsl:template>
 
-
-  <xsl:template match="d:screen">
-    <xsl:element name="div">
-      <xsl:attribute name="class">screenexample</xsl:attribute>
-      <xsl:element name="pre">
-        <xsl:attribute name="class">screen</xsl:attribute>
-        <!--<xsl:value-of select="text()"/>-->
-        <xsl:apply-templates/>
-      </xsl:element>
-    </xsl:element>
-  </xsl:template>
-
  <!-- 
    - synxtax highlighting 
    -->
   <xsl:template match="d:programlisting">
-    <pre>
+    <xsl:choose>
-      <code>
+      <xsl:when test="@language = 'screen'">
-        <xsl:value-of select="text()"/>
+      <xsl:element name="div">
-      </code>
+        <xsl:attribute name="class">screenexample</xsl:attribute>
-    </pre>
+        <xsl:element name="pre">
-    <!--
+          <xsl:attribute name="class">screen</xsl:attribute>
-
+            <xsl:value-of select="text()"/>
-      <xsl:variable name="startinglinenumber">
+          <xsl:apply-templates/>
-        <xsl:choose>
+        </xsl:element>
-          <xsl:when test="@startinglinenumber">; first-line: <xsl:value-of select="@startinglinenumber"/></xsl:when>
+      </xsl:element>
-          <xsl:otherwise></xsl:otherwise>
+      </xsl:when>
-        </xsl:choose>
+      <xsl:otherwise>
-      </xsl:variable>
+        <pre>
-
+          <code>
-      <xsl:variable name="linenumbering">
+            <xsl:value-of select="text()"/>
-        <xsl:choose>
+          </code>
-          <xsl:when test="@linenumbering='unnumbered'">; gutter: false</xsl:when>
+        </pre>
-          <xsl:otherwise></xsl:otherwise>
+      </xsl:otherwise>
-        </xsl:choose>
+    </xsl:choose>
-      </xsl:variable>
-
-      <xsl:variable name="brushstyle">;toolbar: false<xsl:copy-of select="$highlight"/><xsl:copy-of select="$startinglinenumber"/><xsl:copy-of select="$linenumbering"/></xsl:variable>
-    -->
   </xsl:template>
   
 

jetty-io/src/main/java/org/eclipse/jetty/io/ChannelEndPoint.java

@@ -122,7 +122,7 @@ public abstract class ChannelEndPoint extends AbstractEndPoint implements Manage
         }
     };
 
-    private final Runnable _runFillableCompleteWrite = new RejectableRunnable("runFillableCompleteWrite")
+    private final Runnable _runCompleteWriteFillable = new RejectableRunnable("runCompleteWriteFillable")
     {
         @Override
         public void run()
@@ -333,7 +333,7 @@ public abstract class ChannelEndPoint extends AbstractEndPoint implements Manage
         }
 
         // return task to complete the job
-        Runnable task= readable ? (writable ? _runFillableCompleteWrite : _runFillable)
+        Runnable task= readable ? (writable ? _runCompleteWriteFillable : _runFillable)
                 : (writable ? _runCompleteWrite : null);
 
         if (LOG.isDebugEnabled())

jetty-io/src/main/java/org/eclipse/jetty/io/ManagedSelector.java

@@ -78,11 +78,17 @@ public class ManagedSelector extends AbstractLifeCycle implements Runnable, Dump
         setStopTimeout(5000);
     }
 
+    public ExecutionStrategy getExecutionStrategy()
+    {
+        return _strategy;
+    }
+
     @Override
     protected void doStart() throws Exception
     {
         super.doStart();
         _selector = _selectorManager.newSelector();
+        _selectorManager.execute(this);
     }
 
     public int size()

jetty-io/src/main/java/org/eclipse/jetty/io/SelectorManager.java

@@ -29,12 +29,11 @@ import java.nio.channels.ServerSocketChannel;
 import java.nio.channels.SocketChannel;
 import java.util.concurrent.Executor;
 
-import org.eclipse.jetty.util.TypeUtil;
-import org.eclipse.jetty.util.component.AbstractLifeCycle;
 import org.eclipse.jetty.util.component.ContainerLifeCycle;
 import org.eclipse.jetty.util.component.Dumpable;
 import org.eclipse.jetty.util.log.Log;
 import org.eclipse.jetty.util.log.Logger;
+import org.eclipse.jetty.util.thread.ExecutionStrategy;
 import org.eclipse.jetty.util.thread.Scheduler;
 
 /**
@@ -43,7 +42,7 @@ import org.eclipse.jetty.util.thread.Scheduler;
  * <p>{@link SelectorManager} subclasses implement methods to return protocol-specific
  * {@link EndPoint}s and {@link Connection}s.</p>
  */
-public abstract class SelectorManager extends AbstractLifeCycle implements Dumpable
+public abstract class SelectorManager extends ContainerLifeCycle implements Dumpable
 {
     public static final int DEFAULT_CONNECT_TIMEOUT = 15000;
     protected static final Logger LOG = Log.getLogger(SelectorManager.class);
@@ -52,6 +51,7 @@ public abstract class SelectorManager extends AbstractLifeCycle implements Dumpa
     private final Scheduler scheduler;
     private final ManagedSelector[] _selectors;
     private long _connectTimeout = DEFAULT_CONNECT_TIMEOUT;
+    private ExecutionStrategy.Factory _executionFactory = ExecutionStrategy.Factory.getDefault();
     private long _selectorIndex;
 
     protected SelectorManager(Executor executor, Scheduler scheduler)
@@ -98,6 +98,24 @@ public abstract class SelectorManager extends AbstractLifeCycle implements Dumpa
         _connectTimeout = milliseconds;
     }
 
+    /**
+     * @return the {@link ExecutionStrategy.Factory} used by {@link ManagedSelector}
+     */
+    public ExecutionStrategy.Factory getExecutionStrategyFactory()
+    {
+        return _executionFactory;
+    }
+
+    /**
+     * @param _executionFactory the {@link ExecutionStrategy.Factory} used by {@link ManagedSelector}
+     */
+    public void setExecutionStrategyFactory(ExecutionStrategy.Factory _executionFactory)
+    {
+        if (isRunning())
+            throw new IllegalStateException("Cannot change " + ExecutionStrategy.Factory.class.getSimpleName() + " after start()");
+        this._executionFactory = _executionFactory;
+    }
+
     /**
      * @return the selector priority delta
      * @deprecated not implemented
@@ -251,14 +269,13 @@ public abstract class SelectorManager extends AbstractLifeCycle implements Dumpa
     @Override
     protected void doStart() throws Exception
     {
-        super.doStart();
         for (int i = 0; i < _selectors.length; i++)
         {
             ManagedSelector selector = newSelector(i);
             _selectors[i] = selector;
-            selector.start();
+            addBean(selector);
-            execute(selector);
         }
+        super.doStart();
     }
 
     /**
@@ -269,15 +286,15 @@ public abstract class SelectorManager extends AbstractLifeCycle implements Dumpa
      */
     protected ManagedSelector newSelector(int id)
     {
-        return new ManagedSelector(this, id);
+        return new ManagedSelector(this, id, getExecutionStrategyFactory());
     }
 
     @Override
     protected void doStop() throws Exception
     {
-        for (ManagedSelector selector : _selectors)
-            selector.stop();
         super.doStop();
+        for (ManagedSelector selector : _selectors)
+            removeBean(selector);
     }
 
     /**
@@ -297,6 +314,7 @@ public abstract class SelectorManager extends AbstractLifeCycle implements Dumpa
      */
     protected void endPointClosed(EndPoint endpoint)
     {
+        endpoint.onClose();
     }
 
     /**
@@ -341,12 +359,12 @@ public abstract class SelectorManager extends AbstractLifeCycle implements Dumpa
     {
         return ((SocketChannel)channel).finishConnect();
     }
-    
+
     protected boolean isConnectionPending(SelectableChannel channel)
     {
         return ((SocketChannel)channel).isConnectionPending();
     }
-    
+
     protected SelectableChannel doAccept(SelectableChannel server) throws IOException
     {
         return ((ServerSocketChannel)server).accept();
@@ -370,7 +388,7 @@ public abstract class SelectorManager extends AbstractLifeCycle implements Dumpa
     {
         return Selector.open();
     }
-    
+
     /**
      * <p>Factory method to create {@link EndPoint}.</p>
      * <p>This method is invoked as a result of the registration of a channel via {@link #connect(SelectableChannel, Object)}
@@ -395,18 +413,4 @@ public abstract class SelectorManager extends AbstractLifeCycle implements Dumpa
      * @throws IOException if unable to create new connection
      */
     public abstract Connection newConnection(SelectableChannel channel, EndPoint endpoint, Object attachment) throws IOException;
-
-    @Override
-    public String dump()
-    {
-        return ContainerLifeCycle.dump(this);
-    }
-
-    @Override
-    public void dump(Appendable out, String indent) throws IOException
-    {
-        ContainerLifeCycle.dumpObject(out, this);
-        ContainerLifeCycle.dump(out, indent, TypeUtil.asList(_selectors));
-    }
-    
 }

jetty-server/src/main/java/org/eclipse/jetty/server/HttpChannel.java

@@ -592,6 +592,7 @@ public class HttpChannel implements Runnable, HttpOutput.Interceptor
         {
             // The bad message cannot be handled in the current state, so throw
             // to hopefull somebody that can handle
+            abort(e);
             throw new BadMessageException(status,reason);
         }
 

jetty-server/src/main/java/org/eclipse/jetty/server/HttpChannelOverHttp.java

@@ -248,6 +248,7 @@ public class HttpChannelOverHttp extends HttpChannel implements HttpParser.Reque
         {
             // Need to call onRequest, so RequestLog can reports as much as possible
             onRequest(_metadata);
+            getRequest().getHttpInput().earlyEOF();
         }
         catch (Exception e)
         {

jetty-server/src/main/java/org/eclipse/jetty/server/ServerConnector.java

@@ -44,6 +44,7 @@ import org.eclipse.jetty.util.annotation.ManagedAttribute;
 import org.eclipse.jetty.util.annotation.ManagedObject;
 import org.eclipse.jetty.util.annotation.Name;
 import org.eclipse.jetty.util.ssl.SslContextFactory;
+import org.eclipse.jetty.util.thread.ExecutionStrategy;
 import org.eclipse.jetty.util.thread.Scheduler;
 
 /**
@@ -74,7 +75,6 @@ import org.eclipse.jetty.util.thread.Scheduler;
  * The default number of selectors is equal to the number of processors available to the JVM,
  * which should allow optimal performance even if all the connections used are performing
  * significant non-blocking work in the callback tasks.
- *
  */
 @ManagedObject("HTTP connector using NIO ByteChannels and Selectors")
 public class ServerConnector extends AbstractNetworkConnector
@@ -87,24 +87,21 @@ public class ServerConnector extends AbstractNetworkConnector
     private volatile boolean _reuseAddress = true;
     private volatile int _lingerTime = -1;
 
-
+    /**
-    /* ------------------------------------------------------------ */
-    /** HTTP Server Connection.
      * <p>Construct a ServerConnector with a private instance of {@link HttpConnectionFactory} as the only factory.</p>
-     * @param server The {@link Server} this connector will accept connection for. 
+     * @param server The {@link Server} this connector will accept connection for.
      */
     public ServerConnector(
         @Name("server") Server server)
     {
         this(server,null,null,null,-1,-1,new HttpConnectionFactory());
     }
-    
+
-    /* ------------------------------------------------------------ */
+    /**
-    /** HTTP Server Connection.
      * <p>Construct a ServerConnector with a private instance of {@link HttpConnectionFactory} as the only factory.</p>
-     * @param server The {@link Server} this connector will accept connection for. 
+     * @param server The {@link Server} this connector will accept connection for.
-     * @param acceptors 
+     * @param acceptors
-     *          the number of acceptor threads to use, or -1 for a default value. Acceptors accept new TCP/IP connections.  If 0, then 
+     *          the number of acceptor threads to use, or -1 for a default value. Acceptors accept new TCP/IP connections.  If 0, then
      *          the selector threads are used to accept connections.
      * @param selectors
      *          the number of selector threads, or &lt;=0 for a default value. Selectors notice and schedule established connection that can make IO progress.
@@ -116,13 +113,12 @@ public class ServerConnector extends AbstractNetworkConnector
     {
         this(server,null,null,null,acceptors,selectors,new HttpConnectionFactory());
     }
-    
+
-    /* ------------------------------------------------------------ */
+    /**
-    /** HTTP Server Connection.
      * <p>Construct a ServerConnector with a private instance of {@link HttpConnectionFactory} as the only factory.</p>
-     * @param server The {@link Server} this connector will accept connection for. 
+     * @param server The {@link Server} this connector will accept connection for.
-     * @param acceptors 
+     * @param acceptors
-     *          the number of acceptor threads to use, or -1 for a default value. Acceptors accept new TCP/IP connections.  If 0, then 
+     *          the number of acceptor threads to use, or -1 for a default value. Acceptors accept new TCP/IP connections.  If 0, then
      *          the selector threads are used to accept connections.
      * @param selectors
      *          the number of selector threads, or &lt;=0 for a default value. Selectors notice and schedule established connection that can make IO progress.
@@ -137,10 +133,9 @@ public class ServerConnector extends AbstractNetworkConnector
         this(server,null,null,null,acceptors,selectors,factories);
     }
 
-    /* ------------------------------------------------------------ */
+    /**
-    /** Generic Server Connection with default configuration.
      * <p>Construct a Server Connector with the passed Connection factories.</p>
-     * @param server The {@link Server} this connector will accept connection for. 
+     * @param server The {@link Server} this connector will accept connection for.
      * @param factories Zero or more {@link ConnectionFactory} instances used to create and configure connections.
      */
     public ServerConnector(
@@ -150,11 +145,10 @@ public class ServerConnector extends AbstractNetworkConnector
         this(server,null,null,null,-1,-1,factories);
     }
 
-    /* ------------------------------------------------------------ */
+    /**
-    /** HTTP Server Connection.
      * <p>Construct a ServerConnector with a private instance of {@link HttpConnectionFactory} as the primary protocol</p>.
-     * @param server The {@link Server} this connector will accept connection for. 
+     * @param server The {@link Server} this connector will accept connection for.
-     * @param sslContextFactory If non null, then a {@link SslConnectionFactory} is instantiated and prepended to the 
+     * @param sslContextFactory If non null, then a {@link SslConnectionFactory} is instantiated and prepended to the
      * list of HTTP Connection Factory.
      */
     public ServerConnector(
@@ -164,14 +158,13 @@ public class ServerConnector extends AbstractNetworkConnector
         this(server,null,null,null,-1,-1,AbstractConnectionFactory.getFactories(sslContextFactory,new HttpConnectionFactory()));
     }
 
-    /* ------------------------------------------------------------ */
+    /**
-    /** HTTP Server Connection.
      * <p>Construct a ServerConnector with a private instance of {@link HttpConnectionFactory} as the primary protocol</p>.
-     * @param server The {@link Server} this connector will accept connection for. 
+     * @param server The {@link Server} this connector will accept connection for.
-     * @param sslContextFactory If non null, then a {@link SslConnectionFactory} is instantiated and prepended to the 
+     * @param sslContextFactory If non null, then a {@link SslConnectionFactory} is instantiated and prepended to the
      * list of HTTP Connection Factory.
-     * @param acceptors 
+     * @param acceptors
-     *          the number of acceptor threads to use, or -1 for a default value. Acceptors accept new TCP/IP connections.  If 0, then 
+     *          the number of acceptor threads to use, or -1 for a default value. Acceptors accept new TCP/IP connections.  If 0, then
      *          the selector threads are used to accept connections.
      * @param selectors
      *          the number of selector threads, or &lt;=0 for a default value. Selectors notice and schedule established connection that can make IO progress.
@@ -185,10 +178,9 @@ public class ServerConnector extends AbstractNetworkConnector
         this(server,null,null,null,acceptors,selectors,AbstractConnectionFactory.getFactories(sslContextFactory,new HttpConnectionFactory()));
     }
 
-    /* ------------------------------------------------------------ */
+    /**
-    /** Generic SSL Server Connection.
+     * @param server The {@link Server} this connector will accept connection for.
-     * @param server The {@link Server} this connector will accept connection for. 
+     * @param sslContextFactory If non null, then a {@link SslConnectionFactory} is instantiated and prepended to the
-     * @param sslContextFactory If non null, then a {@link SslConnectionFactory} is instantiated and prepended to the 
      * list of ConnectionFactories, with the first factory being the default protocol for the SslConnectionFactory.
      * @param factories Zero or more {@link ConnectionFactory} instances used to create and configure connections.
      */
@@ -200,22 +192,22 @@ public class ServerConnector extends AbstractNetworkConnector
         this(server, null, null, null, -1, -1, AbstractConnectionFactory.getFactories(sslContextFactory, factories));
     }
 
-    /** Generic Server Connection.
+    /**
-     * @param server    
+     * @param server
-     *          The server this connector will be accept connection for.  
+     *          The server this connector will be accept connection for.
-     * @param executor  
+     * @param executor
      *          An executor used to run tasks for handling requests, acceptors and selectors.
      *          If null then use the servers executor
-     * @param scheduler 
+     * @param scheduler
      *          A scheduler used to schedule timeouts. If null then use the servers scheduler
      * @param bufferPool
      *          A ByteBuffer pool used to allocate buffers.  If null then create a private pool with default configuration.
-     * @param acceptors 
+     * @param acceptors
-     *          the number of acceptor threads to use, or -1 for a default value. Acceptors accept new TCP/IP connections.  If 0, then 
+     *          the number of acceptor threads to use, or -1 for a default value. Acceptors accept new TCP/IP connections.  If 0, then
      *          the selector threads are used to accept connections.
      * @param selectors
      *          the number of selector threads, or &lt;=0 for a default value. Selectors notice and schedule established connection that can make IO progress.
-     * @param factories 
+     * @param factories
      *          Zero or more {@link ConnectionFactory} instances used to create and configure connections.
      */
     public ServerConnector(
@@ -277,7 +269,7 @@ public class ServerConnector extends AbstractNetworkConnector
     {
         _manager.setSelectorPriorityDelta(selectorPriorityDelta);
     }
-    
+
     /**
      * @return whether this connector uses a channel inherited from the JVM.
      * @see System#inheritedChannel()
@@ -384,7 +376,7 @@ public class ServerConnector extends AbstractNetworkConnector
             accepted(channel);
         }
     }
-    
+
     private void accepted(SocketChannel channel) throws IOException
     {
         channel.configureBlocking(false);
@@ -486,6 +478,22 @@ public class ServerConnector extends AbstractNetworkConnector
         _reuseAddress = reuseAddress;
     }
 
+    /**
+     * @return the ExecutionStrategy factory to use for SelectorManager
+     */
+    public ExecutionStrategy.Factory getExecutionStrategyFactory()
+    {
+        return _manager.getExecutionStrategyFactory();
+    }
+
+    /**
+     * @param executionFactory the ExecutionStrategy factory to use for SelectorManager
+     */
+    public void setExecutionStrategyFactory(ExecutionStrategy.Factory executionFactory)
+    {
+        _manager.setExecutionStrategyFactory(executionFactory);
+    }
+
     protected class ServerConnectorManager extends SelectorManager
     {
         public ServerConnectorManager(Executor executor, Scheduler scheduler, int selectors)

jetty-server/src/test/java/org/eclipse/jetty/server/ThreadStarvationTest.java

@@ -18,169 +18,259 @@
 
 package org.eclipse.jetty.server;
 
-import static org.hamcrest.Matchers.containsString;
-import static org.junit.Assert.assertEquals;
-import static org.junit.Assert.assertThat;
-
 import java.io.IOException;
 import java.io.InputStream;
 import java.io.OutputStream;
 import java.net.Socket;
+import java.nio.charset.StandardCharsets;
+import java.util.concurrent.CountDownLatch;
 
 import javax.servlet.ServletException;
 import javax.servlet.http.HttpServletRequest;
 import javax.servlet.http.HttpServletResponse;
 
+import org.eclipse.jetty.io.ManagedSelector;
 import org.eclipse.jetty.server.handler.AbstractHandler;
-import org.eclipse.jetty.toolchain.test.AdvancedRunner;
 import org.eclipse.jetty.toolchain.test.TestTracker;
 import org.eclipse.jetty.util.IO;
-import org.junit.Before;
+import org.eclipse.jetty.util.thread.ExecutionStrategy;
+import org.eclipse.jetty.util.thread.QueuedThreadPool;
+import org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume;
+import org.eclipse.jetty.util.thread.strategy.ProduceExecuteConsume;
+import org.junit.After;
+import org.junit.Assert;
 import org.junit.Rule;
 import org.junit.Test;
-import org.junit.runner.RunWith;
 
-@RunWith(AdvancedRunner.class)
+import static org.hamcrest.Matchers.containsString;
-public class ThreadStarvationTest extends HttpServerTestFixture
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.assertFalse;
+import static org.junit.Assert.assertThat;
+import static org.junit.Assert.assertTrue;
+
+public class ThreadStarvationTest
 {
-    ServerConnector _connector;
-    
     @Rule
     public TestTracker tracker = new TestTracker();
+    private QueuedThreadPool _threadPool;
+    private Server _server;
+    private ServerConnector _connector;
+    private int _availableThreads;
 
-    @Before
+    private Server prepareServer(Handler handler)
-    public void init() throws Exception
     {
-        _threadPool.setMinThreads(4);
+        int threads = 4;
-        _threadPool.setMaxThreads(4);
+        _threadPool = new QueuedThreadPool();
-        _threadPool.setDetailedDump(false);
+        _threadPool.setMinThreads(threads);
-        _connector = new ServerConnector(_server,1,1);
+        _threadPool.setMaxThreads(threads);
-        _connector.setIdleTimeout(10000);
+        _threadPool.setDetailedDump(true);
+        _server = new Server(_threadPool);
+        int acceptors = 1;
+        int selectors = 1;
+        _connector = new ServerConnector(_server, acceptors, selectors);
+        _server.addConnector(_connector);
+        _server.setHandler(handler);
+        _availableThreads = threads - acceptors - selectors;
+        return _server;
+    }
+
+    @After
+    public void dispose() throws Exception
+    {
+        _server.stop();
     }
 
     @Test
     public void testReadInput() throws Exception
     {
-        startServer(_connector,new ReadHandler());
+        prepareServer(new ReadHandler()).start();
-        System.err.println(_threadPool.dump());
-        
-        Socket client=newSocket(_serverURI.getHost(),_serverURI.getPort());
-        client.setSoTimeout(10000);
 
-        OutputStream os=client.getOutputStream();
+        Socket client = new Socket("localhost", _connector.getLocalPort());
-        InputStream is=client.getInputStream();
 
-        os.write((
+        OutputStream os = client.getOutputStream();
-                "GET / HTTP/1.0\r\n"+
+        InputStream is = client.getInputStream();
-                "host: "+_serverURI.getHost()+":"+_serverURI.getPort()+"\r\n"+
+
-                "content-length: 10\r\n" +
+        String request = "" +
+                "GET / HTTP/1.0\r\n" +
+                "Host: localhost\r\n" +
+                "Content-Length: 10\r\n" +
                 "\r\n" +
-                "0123456789\r\n").getBytes("utf-8"));
+                "0123456789\r\n";
+        os.write(request.getBytes(StandardCharsets.UTF_8));
         os.flush();
 
         String response = IO.toString(is);
         assertEquals(-1, is.read());
-        assertThat(response,containsString("200 OK"));
+        assertThat(response, containsString("200 OK"));
-        assertThat(response,containsString("Read Input 10"));
+        assertThat(response, containsString("Read Input 10"));
-
     }
-    
+
     @Test
-    public void testEWYKStarvation() throws Exception
+    public void testEPCStarvation() throws Exception
     {
-        System.setProperty("org.eclipse.jetty.io.ManagedSelector$SelectorProducer.ExecutionStrategy","org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume");
+        testStarvation(new ExecuteProduceConsume.Factory());
-        startServer(_connector,new ReadHandler());
-        
-        Socket[] client = new Socket[3];
-        OutputStream[] os = new OutputStream[client.length];
-        InputStream[] is = new InputStream[client.length];
-        
-        for (int i=0;i<client.length;i++)
-        {
-            client[i]=newSocket(_serverURI.getHost(),_serverURI.getPort());
-            client[i].setSoTimeout(10000);
-
-            os[i]=client[i].getOutputStream();
-            is[i]=client[i].getInputStream();
-
-            os[i].write((
-                    "PUT / HTTP/1.0\r\n"+
-                            "host: "+_serverURI.getHost()+":"+_serverURI.getPort()+"\r\n"+
-                            "content-length: 10\r\n" +
-                    "\r\n1").getBytes("utf-8"));
-            os[i].flush();
-        }
-        Thread.sleep(500);
-        System.err.println(_threadPool.dump());
-
-        for (int i=0;i<client.length;i++)
-        {
-            os[i].write(("234567890\r\n").getBytes("utf-8"));
-            os[i].flush();
-        }
-
-        Thread.sleep(500);
-        System.err.println(_threadPool.dump());
-
-        for (int i=0;i<client.length;i++)
-        {
-            String response = IO.toString(is[i]);
-            assertEquals(-1, is[i].read());
-            assertThat(response,containsString("200 OK"));
-            assertThat(response,containsString("Read Input 10"));
-        }
     }
-    
 
     @Test
     public void testPECStarvation() throws Exception
     {
-        System.setProperty("org.eclipse.jetty.io.ManagedSelector$SelectorProducer.ExecutionStrategy","org.eclipse.jetty.util.thread.strategy.ProduceExecuteConsume");
+        testStarvation(new ProduceExecuteConsume.Factory());
+    }
 
-        startServer(_connector,new ReadHandler());
+    private void testStarvation(ExecutionStrategy.Factory executionFactory) throws Exception
+    {
+        prepareServer(new ReadHandler());
+        _connector.setExecutionStrategyFactory(executionFactory);
+        _server.start();
         System.err.println(_threadPool.dump());
-        
+
-        Socket[] client = new Socket[3];
+        Socket[] client = new Socket[_availableThreads + 1];
         OutputStream[] os = new OutputStream[client.length];
         InputStream[] is = new InputStream[client.length];
-        
+
-        for (int i=0;i<client.length;i++)
+        for (int i = 0; i < client.length; i++)
         {
-            client[i]=newSocket(_serverURI.getHost(),_serverURI.getPort());
+            client[i] = new Socket("localhost", _connector.getLocalPort());
             client[i].setSoTimeout(10000);
 
-            os[i]=client[i].getOutputStream();
+            os[i] = client[i].getOutputStream();
-            is[i]=client[i].getInputStream();
+            is[i] = client[i].getInputStream();
 
-            os[i].write((
+            String request = "" +
-                    "PUT / HTTP/1.0\r\n"+
+                    "PUT / HTTP/1.0\r\n" +
-                            "host: "+_serverURI.getHost()+":"+_serverURI.getPort()+"\r\n"+
+                    "host: localhost\r\n" +
-                            "content-length: 10\r\n" +
+                    "content-length: 10\r\n" +
-                    "\r\n1").getBytes("utf-8"));
+                    "\r\n" +
+                    "1";
+            os[i].write(request.getBytes(StandardCharsets.UTF_8));
             os[i].flush();
         }
+
         Thread.sleep(500);
         System.err.println(_threadPool.dump());
 
-        for (int i=0;i<client.length;i++)
+        for (int i = 0; i < client.length; i++)
         {
-            os[i].write(("234567890\r\n").getBytes("utf-8"));
+            os[i].write(("234567890\r\n").getBytes(StandardCharsets.UTF_8));
             os[i].flush();
         }
 
         Thread.sleep(500);
         System.err.println(_threadPool.dump());
 
-        for (int i=0;i<client.length;i++)
+        for (int i = 0; i < client.length; i++)
         {
             String response = IO.toString(is[i]);
             assertEquals(-1, is[i].read());
-            assertThat(response,containsString("200 OK"));
+            assertThat(response, containsString("200 OK"));
-            assertThat(response,containsString("Read Input 10"));
+            assertThat(response, containsString("Read Input 10"));
         }
-        
     }
-    
+
+    @Test
+    public void testEPCExitsLowThreadsMode() throws Exception
+    {
+        prepareServer(new ReadHandler());
+        Assert.assertEquals(2, _availableThreads);
+        _connector.setExecutionStrategyFactory(new ExecuteProduceConsume.Factory());
+        _server.start();
+        System.err.println(_server.dump());
+
+        // Two idle threads in the pool here.
+        // The server will accept the socket in normal mode.
+        Socket client = new Socket("localhost", _connector.getLocalPort());
+        client.setSoTimeout(10000);
+
+        Thread.sleep(500);
+
+        // Now steal one thread.
+        CountDownLatch latch = new CountDownLatch(1);
+        _threadPool.execute(() ->
+        {
+            try
+            {
+                latch.await();
+            }
+            catch (InterruptedException ignored)
+            {
+            }
+        });
+
+        InputStream is = client.getInputStream();
+        OutputStream os = client.getOutputStream();
+
+        String request = "" +
+                "PUT / HTTP/1.0\r\n" +
+                "Host: localhost\r\n" +
+                "Content-Length: 10\r\n" +
+                "\r\n" +
+                "1";
+        os.write(request.getBytes(StandardCharsets.UTF_8));
+        os.flush();
+
+        Thread.sleep(500);
+        System.err.println(_threadPool.dump());
+
+        // Request did not send the whole body, Handler
+        // is blocked reading, zero idle threads here,
+        // EPC is in low threads mode.
+        for (ManagedSelector selector : _connector.getSelectorManager().getBeans(ManagedSelector.class))
+        {
+            ExecuteProduceConsume executionStrategy = (ExecuteProduceConsume)selector.getExecutionStrategy();
+            assertTrue(executionStrategy.isLowOnThreads());
+        }
+
+        // Release the stolen thread.
+        latch.countDown();
+        Thread.sleep(500);
+
+        // Send the rest of the body to unblock the reader thread.
+        // This will be run directly by the selector thread,
+        // which therefore will remain in low threads mode.
+        os.write("234567890".getBytes(StandardCharsets.UTF_8));
+        os.flush();
+
+        Thread.sleep(500);
+        System.err.println(_threadPool.dump());
+
+        // Back to two idle threads here, but we are still in
+        // low threads mode because the SelectorProducer has
+        // not returned from the low threads mode.
+
+        String response = IO.toString(is);
+        assertThat(response, containsString("200 OK"));
+        assertThat(response, containsString("Read Input 10"));
+
+        // Send another request.
+        // Accepting a new connection will exit the low threads mode.
+        client = new Socket("localhost", _connector.getLocalPort());
+        client.setSoTimeout(10000);
+
+        Thread.sleep(500);
+        System.err.println(_threadPool.dump());
+
+        for (ManagedSelector selector : _connector.getSelectorManager().getBeans(ManagedSelector.class))
+        {
+            ExecuteProduceConsume executionStrategy = (ExecuteProduceConsume)selector.getExecutionStrategy();
+            assertFalse(executionStrategy.isLowOnThreads());
+        }
+
+        is = client.getInputStream();
+        os = client.getOutputStream();
+        request = "" +
+                "PUT / HTTP/1.0\r\n" +
+                "Host: localhost\r\n" +
+                "Content-Length: 10\r\n" +
+                "\r\n" +
+                "1234567890";
+
+        os.write(request.getBytes(StandardCharsets.UTF_8));
+        os.flush();
+
+        response = IO.toString(is);
+        assertThat(response, containsString("200 OK"));
+        assertThat(response, containsString("Read Input 10"));
+    }
 
     protected static class ReadHandler extends AbstractHandler
     {
@@ -192,13 +282,13 @@ public class ThreadStarvationTest extends HttpServerTestFixture
 
             int l = request.getContentLength();
             int r = 0;
-            while (r<l)
+            while (r < l)
             {
-                if (request.getInputStream().read()>=0)
+                if (request.getInputStream().read() >= 0)
                     r++;
             }
-            
+
-            response.getOutputStream().write(("Read Input "+r+"\r\n").getBytes());
+            response.getOutputStream().write(("Read Input " + r + "\r\n").getBytes());
         }
     }
 }

jetty-servlet/src/test/java/org/eclipse/jetty/servlet/PostServletTest.java

@@ -18,26 +18,20 @@
 
 package org.eclipse.jetty.servlet;
 
-import static org.hamcrest.Matchers.containsString;
-import static org.hamcrest.Matchers.not;
-import static org.junit.Assert.assertThat;
-
-import java.io.IOException;
-import java.nio.charset.StandardCharsets;
 import java.util.concurrent.TimeUnit;
 
-import javax.servlet.ServletInputStream;
 import javax.servlet.http.HttpServlet;
 import javax.servlet.http.HttpServletRequest;
 import javax.servlet.http.HttpServletResponse;
 
 import org.eclipse.jetty.server.LocalConnector;
 import org.eclipse.jetty.server.Server;
-import org.eclipse.jetty.server.LocalConnector.LocalEndPoint;
 import org.eclipse.jetty.util.log.Log;
 import org.eclipse.jetty.util.log.Logger;
 import org.eclipse.jetty.util.log.StacklessLogging;
+import org.hamcrest.Matchers;
 import org.junit.After;
+import org.junit.Assert;
 import org.junit.Before;
 import org.junit.Test;
 
@@ -51,25 +45,20 @@ public class PostServletTest
         {
             try
             {
-                byte[] buffer = new byte[4096];
+                response.flushBuffer();
-                
+                request.getInputStream().read();
-                ServletInputStream in = request.getInputStream();
-
-                int l = in.read(buffer);
-                while (l>0)
-                {
-                    String s=new String(buffer,0,l,StandardCharsets.ISO_8859_1);
-                    // System.err.println("READ: "+s);
-                    if (s.toLowerCase().contains("flush"))
-                        response.flushBuffer();
-                        
-                    l = in.read(buffer);
-                }
-                
             }
-            catch (IOException e0)
+            catch (Exception e0)
             {
-                LOG.warn(e0);
+                try
+                {
+                    // this read-call should fail immediately
+                    request.getInputStream().read();
+                }
+                catch (Exception e1)
+                {
+                    LOG.warn(e1.toString());
+                }
             }
         }
     }
@@ -114,39 +103,37 @@ public class PostServletTest
         req.append("6\r\n");
         req.append("World\n");
         req.append("\r\n");
-        req.append("0\r\n"); 
+        req.append("0\r\n");
         req.append("\r\n");
 
         String resp = connector.getResponses(req.toString());
 
-        assertThat("resp", resp, containsString("HTTP/1.1 200 OK"));
+        Assert.assertThat("resp", resp, Matchers.containsString("HTTP/1.1 200 OK"));
     }
-    
+
     @Test
     public void testBadPost() throws Exception
     {
-        StringBuilder req = new StringBuilder();
+        StringBuilder req = new StringBuilder(16*1024);
         req.append("POST /post HTTP/1.1\r\n");
         req.append("Host: localhost\r\n");
-        req.append("Connection: close\r\n");
         req.append("Transfer-Encoding: chunked\r\n");
         req.append("\r\n");
-        req.append("6\r\n");
+        // intentionally bad (not a valid chunked char here)
-        req.append("Hello ");
+        for (int i=1024;i-->0;)
+            req.append("xxxxxxxxxxxx");
         req.append("\r\n");
-        req.append("x\r\n");
-        req.append("World\n");
-        req.append("\r\n");
-        req.append("0\r\n"); 
         req.append("\r\n");
 
         try (StacklessLogging scope = new StacklessLogging(ServletHandler.class))
         {
             String resp = connector.getResponses(req.toString());
-            assertThat("resp", resp, containsString("HTTP/1.1 400 "));
+            Assert.assertThat("resp", resp, Matchers.containsString("HTTP/1.1 200 "));
+            Assert.assertThat("resp", resp, Matchers.containsString("chunked"));
+            Assert.assertThat("resp", resp, Matchers.not(Matchers.containsString("\r\n0\r\n")));
         }
     }
-    
+
     @Test
     public void testBadSplitPost() throws Exception
     {
@@ -162,23 +149,23 @@ public class PostServletTest
 
         try (StacklessLogging scope = new StacklessLogging(ServletHandler.class))
         {
-            LocalEndPoint endp=connector.executeRequest(req.toString());
+            LocalConnector.LocalEndPoint endp=connector.executeRequest(req.toString());
             req.setLength(0);
 
             Thread.sleep(1000);
             req.append("x\r\n");
             req.append("World\n");
             req.append("\r\n");
-            req.append("0\r\n"); 
+            req.append("0\r\n");
             req.append("\r\n");
             endp.addInput(req.toString());
-            
+
             endp.waitUntilClosedOrIdleFor(1,TimeUnit.SECONDS);
             String resp = endp.takeOutputString();
-            assertThat("resp", resp, containsString("HTTP/1.1 400 "));
+            Assert.assertThat("resp", resp, Matchers.containsString("HTTP/1.1 400 "));
         }
     }
-    
+
     @Test
     public void testBadFlushedPost() throws Exception
     {
@@ -193,22 +180,22 @@ public class PostServletTest
 
         try (StacklessLogging scope = new StacklessLogging(ServletHandler.class))
         {
-            LocalEndPoint endp=connector.executeRequest(req.toString());
+            LocalConnector.LocalEndPoint endp=connector.executeRequest(req.toString());
             req.setLength(0);
 
             Thread.sleep(1000);
             req.append("x\r\n");
             req.append("World\n");
             req.append("\r\n");
-            req.append("0\r\n"); 
+            req.append("0\r\n");
             req.append("\r\n");
             endp.addInput(req.toString());
-            
+
             endp.waitUntilClosedOrIdleFor(1,TimeUnit.SECONDS);
             String resp = endp.takeOutputString();
-            assertThat("resp", resp, containsString("HTTP/1.1 200 "));
+            Assert.assertThat("resp", resp, Matchers.containsString("HTTP/1.1 200 "));
-            assertThat("resp", resp, containsString("Transfer-Encoding: chunked"));
+            Assert.assertThat("resp", resp, Matchers.containsString("Transfer-Encoding: chunked"));
-            assertThat("resp", resp, not(containsString("\r\n0\r\n")));
+            Assert.assertThat("resp", resp, Matchers.not(Matchers.containsString("\r\n0\r\n")));
         }
     }
 }

jetty-util/src/main/java/org/eclipse/jetty/util/thread/strategy/ExecuteProduceConsume.java

@@ -19,7 +19,6 @@
 package org.eclipse.jetty.util.thread.strategy;
 
 import java.util.concurrent.Executor;
-import java.util.concurrent.RejectedExecutionException;
 
 import org.eclipse.jetty.util.log.Log;
 import org.eclipse.jetty.util.log.Logger;
@@ -50,32 +49,33 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
     private final Locker _locker = new Locker();
     private final Runnable _runExecute = new RunExecute();
     private final Producer _producer;
-    private boolean _idle=true;
+    private final ThreadPool _threadPool;
+    private boolean _idle = true;
     private boolean _execute;
     private boolean _producing;
     private boolean _pending;
-    private final ThreadPool _threadpool;
+    private boolean _lowThreads;
 
     public ExecuteProduceConsume(Producer producer, Executor executor)
     {
         super(executor);
         this._producer = producer;
-        _threadpool = (executor instanceof ThreadPool)?((ThreadPool)executor):null;
+        _threadPool = executor instanceof ThreadPool ? (ThreadPool)executor : null;
     }
 
     @Deprecated
     public ExecuteProduceConsume(Producer producer, Executor executor, ExecutionStrategy lowResourceStrategy)
     {
-        this(producer,executor);
+        this(producer, executor);
     }
 
     @Override
     public void execute()
     {
         if (LOG.isDebugEnabled())
-            LOG.debug("{} execute",this);
+            LOG.debug("{} execute", this);
 
-        boolean produce=false;
+        boolean produce = false;
         try (Lock locked = _locker.lock())
         {
             // If we are idle and a thread is not producing
@@ -85,15 +85,15 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
                     throw new IllegalStateException();
 
                 // Then this thread will do the producing
-                produce=_producing=true;
+                produce = _producing = true;
                 // and we are no longer idle
-                _idle=false;
+                _idle = false;
             }
             else
             {
                 // Otherwise, lets tell the producing thread
                 // that it should call produce again before going idle
-                _execute=true;
+                _execute = true;
             }
         }
 
@@ -105,14 +105,14 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
     public void dispatch()
     {
         if (LOG.isDebugEnabled())
-            LOG.debug("{} spawning",this);
+            LOG.debug("{} spawning", this);
-        boolean dispatch=false;
+        boolean dispatch = false;
         try (Lock locked = _locker.lock())
         {
             if (_idle)
-                dispatch=true;
+                dispatch = true;
             else
-                _execute=true;
+                _execute = true;
         }
         if (dispatch)
             execute(_runExecute);
@@ -122,26 +122,36 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
     public void run()
     {
         if (LOG.isDebugEnabled())
-            LOG.debug("{} run",this);
+            LOG.debug("{} run", this);
-        boolean produce=false;
+        boolean produce = false;
         try (Lock locked = _locker.lock())
         {
-            _pending=false;
+            _pending = false;
             if (!_idle && !_producing)
             {
-                produce=_producing=true;
+                produce = _producing = true;
             }
         }
 
         if (produce)
-        {
-            // If we are low on threads, this could be the last thread, so we must not consume. 
-            // So call produceExecuteConsume instead
-            if (_threadpool!=null && _threadpool.isLowOnThreads() && !produceExecuteConsume())
-                return;
-
             produceConsume();
+    }
+
+    private void produceConsume()
+    {
+        if (_threadPool != null && _threadPool.isLowOnThreads())
+        {
+            // If we are low on threads we must not produce and consume
+            // in the same thread, but produce and execute to consume.
+            if (!produceExecuteConsume())
+                return;
         }
+        executeProduceConsume();
+    }
+
+    public boolean isLowOnThreads()
+    {
+        return _lowThreads;
     }
 
     /**
@@ -150,55 +160,70 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
     private boolean produceExecuteConsume()
     {
         if (LOG.isDebugEnabled())
-            LOG.debug("{} Low Resources",this);
+            LOG.debug("{} enter low threads mode", this);
-        while (_threadpool.isLowOnThreads())
+        _lowThreads = true;
+        try
         {
-            Runnable task = _producer.produce();
+            boolean idle = false;
-            if (LOG.isDebugEnabled())
+            while (_threadPool.isLowOnThreads())
-                LOG.debug("{} produced {}", _producer, task);
-
-            if (task == null)
             {
-                // No task, so we are now idle
+                Runnable task = _producer.produce();
-                try (Lock locked = _locker.lock())
+                if (LOG.isDebugEnabled())
-                {
+                    LOG.debug("{} produced {}", _producer, task);
-                    if (LOG.isDebugEnabled())
-                        LOG.debug("{} Idle Low Resources",this);
-                    _producing=false;
-                    _idle=false;
-                }
-                return false;
-            }
 
-            // Execute the task.
+                if (task == null)
-            execute(task);
+                {
+                    // No task, so we are now idle
+                    try (Lock locked = _locker.lock())
+                    {
+                        if (_execute)
+                        {
+                            _execute = false;
+                            _producing = true;
+                            _idle = false;
+                            continue;
+                        }
+
+                        _producing = false;
+                        idle = _idle = true;
+                        break;
+                    }
+                }
+
+                // Execute the task.
+                execute(task);
+            }
+            return !idle;
+        }
+        finally
+        {
+            _lowThreads = false;
+            if (LOG.isDebugEnabled())
+                LOG.debug("{} exit low threads mode", this);
         }
-        if (LOG.isDebugEnabled())
-            LOG.debug("{} No longer Low Resources",this);
-        return true;
     }
-    
+
-    private void produceConsume()
+    private void executeProduceConsume()
     {
         if (LOG.isDebugEnabled())
-            LOG.debug("{} produce enter",this);
+            LOG.debug("{} produce enter", this);
 
         while (true)
         {
             // If we got here, then we are the thread that is producing.
             if (LOG.isDebugEnabled())
-                LOG.debug("{} producing",this);
+                LOG.debug("{} producing", this);
 
             Runnable task = _producer.produce();
 
             if (LOG.isDebugEnabled())
-                LOG.debug("{} produced {}",this,task);
+                LOG.debug("{} produced {}", this, task);
 
-            boolean dispatch=false;
+            boolean dispatch = false;
             try (Lock locked = _locker.lock())
             {
                 // Finished producing
-                _producing=false;
+                _producing = false;
 
                 // Did we produced a task?
                 if (task == null)
@@ -207,14 +232,14 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
                     // Could another one just have been queued with an execute?
                     if (_execute)
                     {
-                        _idle=false;
+                        _idle = false;
-                        _producing=true;
+                        _producing = true;
-                        _execute=false;
+                        _execute = false;
                         continue;
                     }
 
                     // ... and no additional calls to execute, so we are idle
-                    _idle=true;
+                    _idle = true;
                     break;
                 }
 
@@ -223,10 +248,10 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
                 if (!_pending)
                 {
                     // dispatch one
-                    dispatch=_pending=true;
+                    dispatch = _pending = true;
                 }
 
-                _execute=false;
+                _execute = false;
             }
 
             // If we became pending
@@ -234,18 +259,18 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
             {
                 // Spawn a new thread to continue production by running the produce loop.
                 if (LOG.isDebugEnabled())
-                    LOG.debug("{} dispatch",this);
+                    LOG.debug("{} dispatch", this);
                 if (!execute(this))
-                    task=null;
+                    task = null;
             }
 
             // Run the task.
             if (LOG.isDebugEnabled())
-                LOG.debug("{} run {}",this,task);
+                LOG.debug("{} run {}", this, task);
             if (task != null)
                 task.run();
             if (LOG.isDebugEnabled())
-                LOG.debug("{} ran {}",this,task);
+                LOG.debug("{} ran {}", this, task);
 
             // Once we have run the task, we can try producing again.
             try (Lock locked = _locker.lock())
@@ -253,15 +278,14 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
                 // Is another thread already producing or we are now idle?
                 if (_producing || _idle)
                     break;
-                _producing=true;
+                _producing = true;
             }
         }
 
         if (LOG.isDebugEnabled())
-            LOG.debug("{} produce exit",this);
+            LOG.debug("{} produce exit", this);
     }
 
-    
     public Boolean isIdle()
     {
         try (Lock locked = _locker.lock())
@@ -276,10 +300,10 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
         builder.append("EPC ");
         try (Lock locked = _locker.lock())
         {
-            builder.append(_idle?"Idle/":"");
+            builder.append(_idle ? "Idle/" : "");
-            builder.append(_producing?"Prod/":"");
+            builder.append(_producing ? "Prod/" : "");
-            builder.append(_pending?"Pend/":"");
+            builder.append(_pending ? "Pend/" : "");
-            builder.append(_execute?"Exec/":"");
+            builder.append(_execute ? "Exec/" : "");
         }
         builder.append(_producer);
         return builder.toString();

jetty-util/src/main/java/org/eclipse/jetty/util/thread/strategy/ProduceConsume.java

@@ -23,6 +23,7 @@ import java.util.concurrent.Executor;
 import org.eclipse.jetty.util.log.Log;
 import org.eclipse.jetty.util.log.Logger;
 import org.eclipse.jetty.util.thread.ExecutionStrategy;
+import org.eclipse.jetty.util.thread.Locker;
 
 /**
  * <p>A strategy where the caller thread iterates over task production, submitting each
@@ -32,6 +33,7 @@ public class ProduceConsume implements ExecutionStrategy, Runnable
 {
     private static final Logger LOG = Log.getLogger(ExecuteProduceConsume.class);
 
+    private final Locker _locker = new Locker();
     private final Producer _producer;
     private final Executor _executor;
     private State _state = State.IDLE;
@@ -45,11 +47,19 @@ public class ProduceConsume implements ExecutionStrategy, Runnable
     @Override
     public void execute()
     {
-        synchronized (this)
+        try (Locker.Lock lock = _locker.lock())
         {
-            _state = _state == State.IDLE ? State.PRODUCE : State.EXECUTE;
+            switch(_state)
-            if (_state == State.EXECUTE)
+            {
-                return;
+                case IDLE:
+                    _state= State.PRODUCE;
+                    break;
+
+                case PRODUCE:
+                case EXECUTE:
+                    _state= State.EXECUTE;
+                    return;
+            }
         }
 
         // Iterate until we are complete.
@@ -62,12 +72,19 @@ public class ProduceConsume implements ExecutionStrategy, Runnable
 
             if (task == null)
             {
-                synchronized (this)
+                try (Locker.Lock lock = _locker.lock())
                 {
-                    _state = _state == State.PRODUCE ? State.IDLE : State.PRODUCE;
+                    switch(_state)
-                    if (_state == State.PRODUCE)
+                    {
-                        continue;
+                        case IDLE:
-                    return;
+                            throw new IllegalStateException();
+                        case PRODUCE:
+                            _state= State.IDLE;
+                            return;
+                        case EXECUTE:
+                            _state= State.PRODUCE;
+                            continue;
+                    }
                 }
             }
 

jetty-util/src/test/java/org/eclipse/jetty/util/thread/strategy/ExecuteProduceConsumeTest.java

@@ -27,15 +27,12 @@ import java.util.concurrent.Executor;
 import org.eclipse.jetty.util.BlockingArrayQueue;
 import org.eclipse.jetty.util.ConcurrentArrayQueue;
 import org.eclipse.jetty.util.thread.ExecutionStrategy.Producer;
+import org.hamcrest.Matchers;
 import org.junit.After;
 import org.junit.Assert;
 import org.junit.Before;
 import org.junit.Test;
 
-import static org.hamcrest.Matchers.equalTo;
-import static org.junit.Assert.assertEquals;
-import static org.junit.Assert.assertThat;
-
 public class ExecuteProduceConsumeTest
 {
     private static final Runnable NULLTASK = () -> {};
@@ -80,8 +77,8 @@ public class ExecuteProduceConsumeTest
     public void after()
     {
         // All done and checked
-        assertThat(_produce.size(),equalTo(0));
+        Assert.assertThat(_produce.size(), Matchers.equalTo(0));
-        assertThat(_executions.size(),equalTo(0));
+        Assert.assertThat(_executions.size(), Matchers.equalTo(0));
     }
 
     @Test
@@ -98,7 +95,7 @@ public class ExecuteProduceConsumeTest
         _produce.add(t0);
         _produce.add(NULLTASK);
         _ewyk.execute();
-        assertThat(t0.hasRun(),equalTo(true));
+        Assert.assertThat(t0.hasRun(), Matchers.equalTo(true));
         Assert.assertEquals(_ewyk,_executions.poll());
     }
 
@@ -115,7 +112,7 @@ public class ExecuteProduceConsumeTest
         _ewyk.execute();
 
         for (Task task : tasks)
-            assertThat(task.hasRun(), equalTo(true));
+            Assert.assertThat(task.hasRun(), Matchers.equalTo(true));
         Assert.assertEquals(_ewyk,_executions.poll());
     }
 
@@ -137,13 +134,13 @@ public class ExecuteProduceConsumeTest
 
         // wait for execute thread to block in
         t0.awaitRun();
-        assertEquals(thread,t0.getThread());
+        Assert.assertEquals(thread,t0.getThread());
 
         // Should have dispatched only one helper
-        assertEquals(_ewyk,_executions.poll());
+        Assert.assertEquals(_ewyk,_executions.poll());
         // which is make us idle
         _ewyk.run();
-        assertThat(_ewyk.isIdle(),equalTo(true));
+        Assert.assertThat(_ewyk.isIdle(), Matchers.equalTo(true));
 
 
         // unblock task
@@ -178,7 +175,7 @@ public class ExecuteProduceConsumeTest
         t0.unblock();
         // will run to completion because are become idle
         thread.join();
-        assertThat(_ewyk.isIdle(),equalTo(true));
+        Assert.assertThat(_ewyk.isIdle(), Matchers.equalTo(true));
 
         // because we are idle, dispatched thread is noop
         _ewyk.run();
@@ -201,7 +198,7 @@ public class ExecuteProduceConsumeTest
 
         // wait for execute thread to block in task
         t0.awaitRun();
-        assertEquals(thread0,t0.getThread());
+        Assert.assertEquals(thread0,t0.getThread());
 
         // Should have dispatched another helper
         Assert.assertEquals(_ewyk,_executions.poll());
@@ -215,7 +212,7 @@ public class ExecuteProduceConsumeTest
             Thread.yield();
 
         // thread1 is blocked in producing
-        assertEquals(thread1,_producer);
+        Assert.assertEquals(thread1,_producer);
 
         // because we are producing, any other dispatched threads are noops
         _ewyk.run();
@@ -229,7 +226,7 @@ public class ExecuteProduceConsumeTest
 
         // task will be run by thread1
         t1.awaitRun();
-        assertEquals(thread1,t1.getThread());
+        Assert.assertEquals(thread1,t1.getThread());
 
         // and another thread will have been requested
         Assert.assertEquals(_ewyk,_executions.poll());
@@ -240,7 +237,7 @@ public class ExecuteProduceConsumeTest
         // Now thread1 is producing again
         while(_producer==null)
             Thread.yield();
-        assertEquals(thread1,_producer);
+        Assert.assertEquals(thread1,_producer);
 
         // If we unblock t0, it will decide it is not needed
         t0.unblock();
@@ -254,7 +251,7 @@ public class ExecuteProduceConsumeTest
 
         // Which will eventually idle the producer
         thread1.join();
-        assertEquals(null,_producer);
+        Assert.assertEquals(null,_producer);
     }
 
     @Test
@@ -274,7 +271,7 @@ public class ExecuteProduceConsumeTest
 
         // wait for execute thread to block in task
         t0.awaitRun();
-        assertEquals(thread0,t0.getThread());
+        Assert.assertEquals(thread0,t0.getThread());
 
         // Should have dispatched another helper
         Assert.assertEquals(_ewyk,_executions.poll());
@@ -291,21 +288,21 @@ public class ExecuteProduceConsumeTest
         // but because there was a pending execute it will try producing again
         while(_producer==null)
             Thread.yield();
-        assertEquals(thread0,_producer);
+        Assert.assertEquals(thread0,_producer);
 
         // and will see new tasks
         final Task t1 = new Task(true);
         _produce.add(t1);
         t1.awaitRun();
-        assertThat(t1.getThread(),equalTo(thread0));
+        Assert.assertThat(t1.getThread(), Matchers.equalTo(thread0));
 
         // Should NOT have dispatched another helper, because the last is still pending
-        assertThat(_executions.size(),equalTo(0));
+        Assert.assertThat(_executions.size(), Matchers.equalTo(0));
 
         // When the dispatched thread turns up, it will see the second idle
         _produce.add(NULLTASK);
         _ewyk.run();
-        assertThat(_ewyk.isIdle(),equalTo(true));
+        Assert.assertThat(_ewyk.isIdle(), Matchers.equalTo(true));
 
         // So that when t1 completes it does not produce again.
         t1.unblock();

tests/test-http-client-transport/src/test/java/org/eclipse/jetty/http/client/HttpClientLoadTest.java

@@ -202,6 +202,10 @@ public class HttpClientLoadTest extends AbstractTest
     {
         start(new LoadHandler());
 
+        client.setByteBufferPool(new LeakTrackingByteBufferPool(new MappedByteBufferPool.Tagged()));
+        client.setMaxConnectionsPerDestination(32768);
+        client.setMaxRequestsQueuedPerDestination(1024 * 1024);
+
         int runs = 1;
         int iterations = 256;
         IntStream.range(0, 16).parallel().forEach(i ->
@@ -220,7 +224,9 @@ public class HttpClientLoadTest extends AbstractTest
         final Thread testThread = Thread.currentThread();
         Scheduler.Task task = client.getScheduler().schedule(() ->
         {
-            logger.warn("Interrupting test, it is taking too long{}{}", System.lineSeparator(), client.dump());
+            logger.warn("Interrupting test, it is taking too long{}{}{}{}",
+                    System.lineSeparator(), server.dump(),
+                    System.lineSeparator(), client.dump());
             testThread.interrupt();
         }, iterations * factor, TimeUnit.MILLISECONDS);
 
@@ -254,10 +260,10 @@ public class HttpClientLoadTest extends AbstractTest
 
         // Choose randomly whether to close the connection on the client or on the server
         boolean clientClose = false;
-        if (!ssl && random.nextBoolean())
+        if (!ssl && random.nextInt(100) < 5)
             clientClose = true;
         boolean serverClose = false;
-        if (!ssl && random.nextBoolean())
+        if (!ssl && random.nextInt(100) < 5)
             serverClose = true;
 
         int maxContentLength = 64 * 1024;
@@ -330,7 +336,11 @@ public class HttpClientLoadTest extends AbstractTest
             }
         });
         if (!await(requestLatch, 5, TimeUnit.SECONDS))
-            logger.warn("Request {} took too long", requestId);
+        {
+            logger.warn("Request {} took too long{}{}{}{}", requestId,
+                    System.lineSeparator(), server.dump(),
+                    System.lineSeparator(), client.dump());
+        }
     }
 
     private boolean await(CountDownLatch latch, long time, TimeUnit unit)