Merge branch 'jetty-9.3.x' into pr/576

# Conflicts:
#
jetty-documentation/src/main/asciidoc/administration/logging/default-log
ging-with-stderrlog.adoc

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/default-logging-with-stderrlog.adoc

@@ -82,9 +82,10 @@ There are a number of properties that can be defined in the configuration that w
   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:
+  * 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
@@ -92,9 +93,10 @@ There are a number of properties that can be defined in the configuration that w
 2014-06-03 14:36:17.880:INFO:oejs.ServerConnector:main: Started ServerConnector@34f2d11a{HTTP/1.1}{0.0.0.0:8080}
 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

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

@@ -22,6 +22,7 @@ This is accomplished by configuring Jetty for logging to http://logging.apache.o
 
 A convenient replacement `logging` module has been created to bootstrap your `${jetty.base}` directory for logging with log4j.
 
+[source, screen]
 ....
 [mybase]$ mkdir modules
 [mybase]$ cd modules

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

@@ -32,6 +32,7 @@ ____
 
 A convenient replacement `logging` module has been created to bootstrap your `${jetty.base}` directory for logging with `java.util.logging`.
 
+[source, screen]
 ....
 [mybase]$ mkdir modules
 [mybase]$ cd modules

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

@@ -24,6 +24,7 @@ If you want to use the built-in native `JavaUtilLog` implementation, see #exampl
 
 A convenient replacement `logging` module has been created to bootstrap your `${jetty.base}` directory for logging with `java.util.logging`.
 
+[source, screen]
 ....
 [mybase]$ mkdir modules
 [mybase]$ cd modules

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

@@ -35,6 +35,7 @@ See https://github.com/jetty-project/jetty-webapp-logging/blob/master/src/main/j
 
 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.
 
+[source, screen]
 ....
 [mybase]$ mkdir modules
 [mybase]$ cd modules

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

@@ -22,6 +22,7 @@ This is accomplished by configuring Jetty for logging to `Logback`, which uses h
 
 A convenient replacement `logging` module has been created to bootstrap the `${jetty.base}` directory for logging with logback.
 
+[source, screen]
 ....
 [mybase]$ mkdir modules
 [mybase]$ cd modules

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

@@ -86,6 +86,7 @@ It also requires including the other Slf4j binding JARs in the classpath, along
 
 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.
 
+[source, screen]
 ....
 [mybase]$ mkdir modules
 [mybase]$ cd modules

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

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

@@ -641,6 +641,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-servlet/src/test/java/org/eclipse/jetty/servlet/PostServletTest.java

@@ -1,145 +1,140 @@
-//
+//
-//  ========================================================================
+//  ========================================================================
-//  Copyright (c) 1995-2016 Mort Bay Consulting Pty. Ltd.
+//  Copyright (c) 1995-2016 Mort Bay Consulting Pty. Ltd.
-//  ------------------------------------------------------------------------
+//  ------------------------------------------------------------------------
-//  All rights reserved. This program and the accompanying materials
+//  All rights reserved. This program and the accompanying materials
-//  are made available under the terms of the Eclipse Public License v1.0
+//  are made available under the terms of the Eclipse Public License v1.0
-//  and Apache License v2.0 which accompanies this distribution.
+//  and Apache License v2.0 which accompanies this distribution.
-//
+//
-//      The Eclipse Public License is available at
+//      The Eclipse Public License is available at
-//      http://www.eclipse.org/legal/epl-v10.html
+//      http://www.eclipse.org/legal/epl-v10.html
-//
+//
-//      The Apache License v2.0 is available at
+//      The Apache License v2.0 is available at
-//      http://www.opensource.org/licenses/apache2.0.php
+//      http://www.opensource.org/licenses/apache2.0.php
-//
+//
-//  You may elect to redistribute this code under either of these licenses.
+//  You may elect to redistribute this code under either of these licenses.
-//  ========================================================================
+//  ========================================================================
-//
+//
-
+
-package org.eclipse.jetty.servlet;
+package org.eclipse.jetty.servlet;
-
+
-import static org.hamcrest.Matchers.containsString;
+import static org.hamcrest.Matchers.containsString;
-import static org.junit.Assert.assertThat;
+import static org.hamcrest.Matchers.not;
-
+import static org.junit.Assert.assertThat;
-import java.io.BufferedReader;
+
-import java.io.IOException;
+import java.io.IOException;
-import java.nio.charset.StandardCharsets;
+import java.util.concurrent.TimeUnit;
-import java.util.concurrent.TimeUnit;
+
-
+import javax.servlet.http.HttpServlet;
-import javax.servlet.ServletInputStream;
+import javax.servlet.http.HttpServletRequest;
-import javax.servlet.http.HttpServlet;
+import javax.servlet.http.HttpServletResponse;
-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;
+import org.eclipse.jetty.util.log.Log;
-import org.eclipse.jetty.server.Server;
+import org.eclipse.jetty.util.log.Logger;
-import org.eclipse.jetty.util.log.Log;
+import org.eclipse.jetty.util.log.StacklessLogging;
-import org.eclipse.jetty.util.log.Logger;
+import org.junit.After;
-import org.eclipse.jetty.util.log.StacklessLogging;
+import org.junit.Before;
-import org.junit.After;
+import org.junit.Ignore;
-import org.junit.Before;
+import org.junit.Test;
-import org.junit.Ignore;
+
-import org.junit.Test;
+public class PostServletTest
-
+{
-public class PostServletTest
+    private static final Logger LOG = Log.getLogger(PostServletTest.class);
-{
+
-    private static final Logger LOG = Log.getLogger(PostServletTest.class);
+    public static class BasicReadPostServlet extends HttpServlet
-
+    {
-    public static class BasicReadPostServlet extends HttpServlet
+        protected void doPost(HttpServletRequest request, HttpServletResponse response)
-    {
+        {
-        protected void doPost(HttpServletRequest request, HttpServletResponse response)
+            try
-        {
+            {
-            try
+                response.flushBuffer();
-            {
+                request.getInputStream().read();
-                byte[] buffer = new byte[4096];
+            }
-                
+            catch (Exception e0)
-                ServletInputStream in = request.getInputStream();
+            {
-
+                try
-                int l = in.read(buffer);
+                {
-                while (l>0)
+                    // this read-call should fail immediately
-                {
+                    request.getInputStream().read();
-                    // System.err.println("READ: "+new String(buffer,0,l,StandardCharsets.ISO_8859_1));
+                }
-                    l = in.read(buffer);
+                catch (Exception e1)
-                }
+                {
-                
+                    LOG.warn(e1.toString());
-            }
+                }
-            catch (IOException e0)
+            }
-            {
+        }
-                LOG.warn(e0);
+    }
-            }
+
-        }
+    private Server server;
-    }
+    private LocalConnector connector;
-
+
-    private Server server;
+    @Before
-    private LocalConnector connector;
+    public void startServer() throws Exception
-
+    {
-    @Before
+        server = new Server();
-    public void startServer() throws Exception
+        connector = new LocalConnector(server);
-    {
+        server.addConnector(connector);
-        server = new Server();
+
-        connector = new LocalConnector(server);
+        ServletContextHandler context = new ServletContextHandler();
-        server.addConnector(connector);
+        context.setContextPath("/");
-
+        context.addServlet(BasicReadPostServlet.class, "/post");
-        ServletContextHandler context = new ServletContextHandler();
+
-        context.setContextPath("/");
+        server.setHandler(context);
-        context.addServlet(BasicReadPostServlet.class, "/post");
+
-
+        server.start();
-        server.setHandler(context);
+    }
-
+
-        server.start();
+    @After
-    }
+    public void stopServer() throws Exception
-
+    {
-    @After
+        this.server.stop();
-    public void stopServer() throws Exception
+    }
-    {
+
-        this.server.stop();
+    @Test
-    }
+    public void testGoodPost() throws Exception
-
+    {
-    @Test
+        StringBuilder req = new StringBuilder();
-    public void testGoodPost() throws Exception
+        req.append("POST /post HTTP/1.1\r\n");
-    {
+        req.append("Host: localhost\r\n");
-        StringBuilder req = new StringBuilder();
+        req.append("Connection: close\r\n");
-        req.append("POST /post HTTP/1.1\r\n");
+        req.append("Transfer-Encoding: chunked\r\n");
-        req.append("Host: localhost\r\n");
+        req.append("\r\n");
-        req.append("Connection: close\r\n");
+        req.append("6\r\n");
-        req.append("Transfer-Encoding: chunked\r\n");
+        req.append("Hello ");
-        req.append("\r\n");
+        req.append("\r\n");
-        req.append("6\r\n");
+        req.append("6\r\n");
-        req.append("Hello ");
+        req.append("World\n");
-        req.append("\r\n");
+        req.append("\r\n");
-        req.append("6\r\n");
+        req.append("0\r\n");
-        req.append("World\n");
+        req.append("\r\n");
-        req.append("\r\n");
+
-        req.append("0\r\n"); 
+        String resp = connector.getResponses(req.toString());
-        req.append("\r\n");
+
-
+        assertThat("resp", resp, containsString("HTTP/1.1 200 OK"));
-        String resp = connector.getResponses(req.toString());
+    }
-
+
-        assertThat("resp", resp, containsString("HTTP/1.1 200 OK"));
+    @Test
-    }
+    public void testBadPost() throws Exception
-    
+    {
-    @Test
+        StringBuilder req = new StringBuilder(16*1024);
-    public void testBadPost() throws Exception
+        req.append("POST /post HTTP/1.1\r\n");
-    {
+        req.append("Host: localhost\r\n");
-        StringBuilder req = new StringBuilder();
+        req.append("Transfer-Encoding: chunked\r\n");
-        req.append("POST /post HTTP/1.1\r\n");
+        req.append("\r\n");
-        req.append("Host: localhost\r\n");
+        // intentionally bad (not a valid chunked char here)
-        req.append("Connection: close\r\n");
+        for (int i=1024;i-->0;)
-        req.append("Transfer-Encoding: chunked\r\n");
+            req.append("xxxxxxxxxxxx");
-        req.append("\r\n");
+        req.append("\r\n");
-        req.append("6\r\n");
+        req.append("\r\n");
-        req.append("Hello ");
+
-        req.append("\r\n");
+        try (StacklessLogging scope = new StacklessLogging(ServletHandler.class))
-        req.append("x\r\n");
+        {
-        req.append("World\n");
+            String resp = connector.getResponses(req.toString());
-        req.append("\r\n");
+            assertThat("resp", resp, containsString("HTTP/1.1 200 "));
-        req.append("0\r\n"); 
+            assertThat("resp", resp, containsString("chunked"));
-        req.append("\r\n");
+            assertThat("resp", resp, not(containsString("\r\n0\r\n")));
-
+        }
-        try (StacklessLogging scope = new StacklessLogging(ServletHandler.class))
+    }
-        {
+}
-            String resp = connector.getResponses(req.toString());
-            assertThat("resp", resp, containsString("HTTP/1.1 500 "));
-        }
-    }
-}