diff --git a/jetty-documentation/pom.xml b/jetty-documentation/pom.xml
index 2518c076397..e68949d7cea 100644
--- a/jetty-documentation/pom.xml
+++ b/jetty-documentation/pom.xml
@@ -52,8 +52,8 @@
book
index.adoc
+ attributes+
- ${project.version}
true
true
true
@@ -62,6 +62,7 @@
http://download.eclipse.org/jetty/stable-9/xref
${basedir}/..
https://github.com/eclipse/jetty.project/master
+ ${project.version}
diff --git a/jetty-documentation/src/main/asciidoc/administration/alpn/alpn.adoc b/jetty-documentation/src/main/asciidoc/administration/alpn/alpn.adoc
index 35ff824aca1..bd01944e43c 100644
--- a/jetty-documentation/src/main/asciidoc/administration/alpn/alpn.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/alpn/alpn.adoc
@@ -42,7 +42,7 @@ This section provides the detail required for unusual deployments or developing
To enable ALPN support, start the JVM as follows:
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
java -Xbootclasspath/p: ...
----
@@ -75,7 +75,7 @@ Refer to `ALPN` Javadocs and to the examples below for further details about cli
[[alpn-client-example]]
==== Client Example
-[source,java]
+[source, java, subs="{sub-order}"]
----
SSLContext sslContext = ...;
final SSLSocket sslSocket = (SSLSocket)context.getSocketFactory().createSocket("localhost", server.getLocalPort());
@@ -121,7 +121,7 @@ The ALPN implementation calls `ALPN.ClientProvider` methods `supports()`, `proto
The example for SSLEngine is identical, and you just need to replace the SSLSocket instance with an SSLEngine instance.
-[source,java]
+[source, java, subs="{sub-order}"]
----
final SSLSocket sslSocket = ...;
ALPN.put(sslSocket, new ALPN.ServerProvider()
@@ -159,7 +159,7 @@ Failing to do so will cause a memory leak.
You can write and run unit tests that use the ALPN implementation.
The solution that we use with Maven is to specify an additional command line argument to the Surefire plugin:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -257,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ hg clone http://hg.openjdk.java.net/jdk7u/jdk7u jdk7u # OpenJDK 7
$ hg clone http://hg.openjdk.java.net/jdk8u/jdk8u jdk8u # OpenJDK 8
@@ -268,7 +268,7 @@ $ ./get_source.sh
To update the source to a specific tag, use the following command:
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
$ ./make/scripts/hgforest.sh update
diff --git a/jetty-documentation/src/main/asciidoc/administration/annotations/quick-annotations-setup.adoc b/jetty-documentation/src/main/asciidoc/administration/annotations/quick-annotations-setup.adoc
index c9a3c388c09..a3a51bd7c29 100644
--- a/jetty-documentation/src/main/asciidoc/administration/annotations/quick-annotations-setup.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/annotations/quick-annotations-setup.adoc
@@ -37,7 +37,7 @@ Here is an example application that sets up the standard test-spec.war webapp fr
It can be found in the jetty git repository in the examples/embedded project.
Note that the test-spec.war uses not only annotations, but also link:#jndi[JNDI], so this example also enables their processing (via the link:#jndi-configuration-classes[org.eclipse.jetty.plus.webapp.EnvConfiguration], link:#jndi-configuration-classes[org.eclipse.jetty.plus.webapp.PlusConfiguration] and their related jars).
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/ServerWithAnnotations.java[]
----
diff --git a/jetty-documentation/src/main/asciidoc/administration/annotations/using-annotations-embedded.adoc b/jetty-documentation/src/main/asciidoc/administration/annotations/using-annotations-embedded.adoc
index 67d72eac66d..b16857e8887 100644
--- a/jetty-documentation/src/main/asciidoc/administration/annotations/using-annotations-embedded.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/annotations/using-annotations-embedded.adoc
@@ -35,7 +35,7 @@ This example also uses the @Resource annotation which involves JNDI, so we would
Here is the embedding code:
-[source,java]
+[source, java, subs="{sub-order}"]
----
import org.eclipse.jetty.security.HashLoginService;
import org.eclipse.jetty.server.Server;
@@ -97,7 +97,7 @@ On lines 30, 33 and 37 we set up some JNDI resources that we will be able to ref
With the setup above, we can create a servlet that uses annotations and Jetty will honour the annotations when the webapp is deployed:
-[source,java]
+[source, java, subs="{sub-order}"]
----
import javax.annotation.security.DeclareRoles;
import javax.annotation.security.RunAs;
diff --git a/jetty-documentation/src/main/asciidoc/administration/annotations/using-annotations.adoc b/jetty-documentation/src/main/asciidoc/administration/annotations/using-annotations.adoc
index d9708ac05a6..5a2fb4a795e 100644
--- a/jetty-documentation/src/main/asciidoc/administration/annotations/using-annotations.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/annotations/using-annotations.adoc
@@ -123,7 +123,7 @@ If you need ServletContainerInitializers called in a specific order that is diff
You may optionally use the wildcard character "*" *once* in the list.
It will match all ServletContainerInitializers not explicitly named in the list. Here's an example, setting the context attribute in code (although you can also do the link:#intro-jetty-configuration-webapps[same in xml]):
-[source,java]
+[source, java, subs="{sub-order}"]
----
WebAppContext context = new WebAppContext();
context.setAttribute("org.eclipse.jetty.containerInitializerOrder",
@@ -142,7 +142,7 @@ In this case, you can define the `org.eclipse.jetty.containerInitializerExclusio
This is a regular expression that defines http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html[patterns] of classnames that you want to exclude.
Here's an example, setting the context attribute in code, although you may do exactly the link:#intro-jetty-configuration-webapps[same in xml]:
-[source,java]
+[source, java, subs="{sub-order}"]
----
WebAppContext context = new WebAppContext();
context.setAttribute("org.eclipse.jetty.containerInitializerExclusionPattern",
diff --git a/jetty-documentation/src/main/asciidoc/administration/extras/cross-origin-filter.adoc b/jetty-documentation/src/main/asciidoc/administration/extras/cross-origin-filter.adoc
index 72a6fdf61ba..770ef866cf0 100644
--- a/jetty-documentation/src/main/asciidoc/administration/extras/cross-origin-filter.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/extras/cross-origin-filter.adoc
@@ -77,7 +77,7 @@ exposedHeaders::
A typical configuration could be:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/administration/extras/debug-handler.adoc b/jetty-documentation/src/main/asciidoc/administration/extras/debug-handler.adoc
index 86469ab0e63..ffd2fa3f5fb 100644
--- a/jetty-documentation/src/main/asciidoc/administration/extras/debug-handler.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/extras/debug-handler.adoc
@@ -38,7 +38,7 @@ For example in start.ini.
==== Embedded usage
-[source,java]
+[source, java, subs="{sub-order}"]
----
Server server = new Server(8080);
RolloverFileOutputStream outputStream = new RolloverFileOutputStream("MeinLogPfad/yyyy_mm_dd.request.log", true,10);
diff --git a/jetty-documentation/src/main/asciidoc/administration/extras/default-handler.adoc b/jetty-documentation/src/main/asciidoc/administration/extras/default-handler.adoc
index d1087892800..664408ecc03 100644
--- a/jetty-documentation/src/main/asciidoc/administration/extras/default-handler.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/extras/default-handler.adoc
@@ -38,7 +38,7 @@ _____
The DefaultHandler will also handle serving out the flav.ico file should a request make it through all of the other handlers without being resolved.
_____
-[source,java]
+[source, java, subs="{sub-order}"]
----
Server server = new Server(8080);
diff --git a/jetty-documentation/src/main/asciidoc/administration/extras/dos-filter.adoc b/jetty-documentation/src/main/asciidoc/administration/extras/dos-filter.adoc
index 1f2ca7029be..1c6620e84b8 100644
--- a/jetty-documentation/src/main/asciidoc/administration/extras/dos-filter.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/extras/dos-filter.adoc
@@ -54,7 +54,7 @@ Place the configuration in a webapp's web.xml or jetty-web.xml.
The default configuration allows 25 requests per connection at a time, servicing more important requests first, and queuing up the rest.
This example allow 30 requests at a time:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/administration/extras/moved-context-handler.adoc b/jetty-documentation/src/main/asciidoc/administration/extras/moved-context-handler.adoc
index 3e40d61ad5a..232f4a8032f 100644
--- a/jetty-documentation/src/main/asciidoc/administration/extras/moved-context-handler.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/extras/moved-context-handler.adoc
@@ -46,7 +46,7 @@ You create a new context xml file in $JETTY_HOME/contexts and configure the Move
Here's an example.
This is a permanent redirection, which also preserves pathinfo and query strings on the redirect:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/administration/extras/qos-filter.adoc b/jetty-documentation/src/main/asciidoc/administration/extras/qos-filter.adoc
index 35da1e96c2f..3ea60458c30 100644
--- a/jetty-documentation/src/main/asciidoc/administration/extras/qos-filter.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/extras/qos-filter.adoc
@@ -83,7 +83,7 @@ Place the configuration in a webapp's web.xml or jetty-web.xml.
The default configuration processes ten requests at a time, servicing more important requests first, and queuing up the rest.
This example processes fifty requests at a time:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -129,7 +129,7 @@ managedAttr::
You can use the `` syntax to map the QoSFilter to a servlet, either by using the servlet name, or by using a URL pattern.
In this example, a URL pattern applies the QoSFilter to every request within the web application context:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -153,7 +153,7 @@ To customize the priority, subclass QoSFilter and then override the getPriority(
You can then use this subclass as your QoS filter.
Here's a trivial example:
-[source,java]
+[source, java, subs="{sub-order}"]
----
public class ParsePriorityQoSFilter extends QoSFilter
diff --git a/jetty-documentation/src/main/asciidoc/administration/extras/resource-handler.adoc b/jetty-documentation/src/main/asciidoc/administration/extras/resource-handler.adoc
index 149221b4d00..b5d532d7fb7 100644
--- a/jetty-documentation/src/main/asciidoc/administration/extras/resource-handler.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/extras/resource-handler.adoc
@@ -50,7 +50,7 @@ The default css is called jetty-dir.css and is located in the jetty-util package
The following is an example of a split fileserver, able to serve static content from multiple directory locations.
Since this handler does not return 404's on content you are able to iteratively try multiple resource handlers to resolve content.
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/SplitFileServer.java[]
----
diff --git a/jetty-documentation/src/main/asciidoc/administration/extras/rewrite-handler.adoc b/jetty-documentation/src/main/asciidoc/administration/extras/rewrite-handler.adoc
index 69b6a91a887..a5fccd7173f 100644
--- a/jetty-documentation/src/main/asciidoc/administration/extras/rewrite-handler.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/extras/rewrite-handler.adoc
@@ -29,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ java -jar start.jar --add-to-startd=rewrite
@@ -45,7 +45,7 @@ _____
The rewrite module enables the following jetty xml config file on the execution path:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
include::{SRCDIR}/jetty-rewrite/src/main/config/etc/jetty-rewrite.xml[]
----
@@ -54,7 +54,7 @@ As the commented out code shows, you configure the RewriteHandler by adding vari
There is an example of link:#rewrite-rules[rules] configuration in the standard distribution in the `demo-base/etc/demo-rewrite-rules.xml` file:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
include::{SRCDIR}/tests/test-webapps/test-jetty-webapp/src/main/config/demo-base/etc/demo-rewrite-rules.xml[]
----
@@ -63,7 +63,7 @@ include::{SRCDIR}/tests/test-webapps/test-jetty-webapp/src/main/config/demo-base
This is an example for embedded Jetty, which does something similar to the configuration file example above:
-[source,java]
+[source, java, subs="{sub-order}"]
----
Server server = new Server();
diff --git a/jetty-documentation/src/main/asciidoc/administration/extras/shutdown-handler.adoc b/jetty-documentation/src/main/asciidoc/administration/extras/shutdown-handler.adoc
index ed3dc44d7d8..a3bdfa3c358 100644
--- a/jetty-documentation/src/main/asciidoc/administration/extras/shutdown-handler.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/extras/shutdown-handler.adoc
@@ -34,7 +34,7 @@ If _exitJvm is set to true a hard System.exit() call is being made.
This is an example of how you can setup this handler directly with the Server, it can be added as a part of handler chain or collection as well.
-[source,java]
+[source, java, subs="{sub-order}"]
----
Server server = new Server(8080);
@@ -49,7 +49,7 @@ This is an example of how you can setup this handler directly with the Server, i
And this is an example that you can use to call the shutdown handler from within java.
-[source,java]
+[source, java, subs="{sub-order}"]
----
public static void attemptShutdown(int port, String shutdownCookie) {
diff --git a/jetty-documentation/src/main/asciidoc/administration/extras/statistics-handler.adoc b/jetty-documentation/src/main/asciidoc/administration/extras/statistics-handler.adoc
index 872e2f95851..f8a6366745c 100644
--- a/jetty-documentation/src/main/asciidoc/administration/extras/statistics-handler.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/extras/statistics-handler.adoc
@@ -55,7 +55,7 @@ To learn how to turn on connector statistics please see Jetty Statistics tutoria
The following example shows how to turn on connector statistics in jetty xml.
This example comes from within `jetty-http.xml`.
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -95,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ java -jar start.jar OPTIONS=default etc/jetty.xml etc/jetty-stats.xml
@@ -104,7 +104,7 @@ $ java -jar start.jar OPTIONS=default etc/jetty.xml etc/jetty-stats.xml
Alternately, if you are making multiple changes to the Jetty configuration, you could include statistics handler configuration into your own jetty xml configuration.
The following fragment shows how to configure a top level statistics handler:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/administration/fastcgi/configuring-fastcgi.adoc b/jetty-documentation/src/main/asciidoc/administration/fastcgi/configuring-fastcgi.adoc
index f4e07a1648c..a31d264e80a 100644
--- a/jetty-documentation/src/main/asciidoc/administration/fastcgi/configuring-fastcgi.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/fastcgi/configuring-fastcgi.adoc
@@ -29,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ mkdir -p /usr/jetty/wordpress
$ cd /usr/jetty/wordpress
@@ -44,7 +44,7 @@ Typically this is done by deploying a `*.war` file in the `$JETTY_BASE/webapps`
Therefore you just need to deploy a Jetty XML file that configures the web application directly.
Copy and paste the following content as `$JETTY_BASE/webapps/jetty-wordpress.xml`
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -135,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ cd $JETTY_BASE
$ java -jar /opt/jetty/start.jar
@@ -149,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ cd $JETTY_BASE
$ java -jar $JETTY_HOME/start.jar --add-to-start=http2
@@ -170,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ cd $JETTY_BASE
$ java -jar $JETTY_HOME/start.jar
diff --git a/jetty-documentation/src/main/asciidoc/administration/http2/configuring-push.adoc b/jetty-documentation/src/main/asciidoc/administration/http2/configuring-push.adoc
index 58200766413..5676e4e41bc 100644
--- a/jetty-documentation/src/main/asciidoc/administration/http2/configuring-push.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/http2/configuring-push.adoc
@@ -22,7 +22,7 @@ This will reduce the amount of round-trips necessary to retrieve all the resourc
HTTP/2 Push can be automated in your application by simply configuring a link:{JDURL}/org/eclipse/jetty/servlets/PushCacheFilter.html[`PushCacheFilter`] in your `web.xml`, in this way:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/administration/http2/enabling-http2.adoc b/jetty-documentation/src/main/asciidoc/administration/http2/enabling-http2.adoc
index ea4e6bde1fe..c4d32420ebf 100644
--- a/jetty-documentation/src/main/asciidoc/administration/http2/enabling-http2.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/http2/enabling-http2.adoc
@@ -19,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ JETTY_BASE=http2-demo
$ mkdir $JETTY_BASE
diff --git a/jetty-documentation/src/main/asciidoc/administration/jmx/jetty-jconsole.adoc b/jetty-documentation/src/main/asciidoc/administration/jmx/jetty-jconsole.adoc
index 8ff58b06436..e0fbec23063 100644
--- a/jetty-documentation/src/main/asciidoc/administration/jmx/jetty-jconsole.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/jmx/jetty-jconsole.adoc
@@ -29,7 +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]
+[source, screen, subs="{sub-order}"]
....
[mybase]$ java /opt/jetty-dist/start.jar --add-to-start=jmx
INFO: jmx-remote initialised in ${jetty.base}/start.ini (appended)
@@ -61,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ export MAVEN_OPTS=-Dcom.sun.management.jmxremote
diff --git a/jetty-documentation/src/main/asciidoc/administration/jmx/jetty-jmx-annotations.adoc b/jetty-documentation/src/main/asciidoc/administration/jmx/jetty-jmx-annotations.adoc
index 5021ea644cf..2227f4118bc 100644
--- a/jetty-documentation/src/main/asciidoc/administration/jmx/jetty-jmx-annotations.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/jmx/jetty-jmx-annotations.adoc
@@ -100,7 +100,7 @@ description::
The following is an example of each of the annotations mentioned above in practice.
-[source,java]
+[source, java, subs="{sub-order}"]
----
package com.acme;
diff --git a/jetty-documentation/src/main/asciidoc/administration/jmx/using-jmx.adoc b/jetty-documentation/src/main/asciidoc/administration/jmx/using-jmx.adoc
index bbb9ae78a14..a16b3bc3a68 100644
--- a/jetty-documentation/src/main/asciidoc/administration/jmx/using-jmx.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/jmx/using-jmx.adoc
@@ -33,7 +33,7 @@ This implementation allows you to wrap an arbitrary POJO in an MBean and annotat
See xref:jetty-jmx-annotations[].
TheMBeanContainer implementation of the Container.Listener interface coordinates creation of MBeans.
-The Jetty Server and it's components use a link:{JDURL}/org/eclipse/jetty/util/component/Container.html[Container] to maintain a containment tree of components and to support notification of changes to that tree.
+The Jetty Server and it's components use a link:{JDURL}/org/eclipse/jetty/util/component/Container.html[Container] to maintain a containment tree of components and to support notification of changes to that tree.
The MBeanContainer class listens for Container events and creates and destroys MBeans as required to wrap all Jetty components.
You can access the MBeans that Jetty publishes both through built-in Java VM connector via JConsole, or by registering a remote JMX connector and using a remote JMX agent to monitor Jetty.
@@ -76,7 +76,7 @@ If you are having difficulties validate that the section in the jetty.home/start
When running Jetty embedded into an application, create and configure an MBeanContainer instance as follows:
-[source,java]
+[source, java]
----
Server server = new Server();
@@ -100,12 +100,12 @@ Because logging is initialized prior to the MBeanContainer (even before the Serv
If you are using the link:#jetty-maven-plugin[jetty maven plugin] you should copy the `etc/jetty-jmx.xml` file into your webapp project somewhere, such as `src/etc,` then add a `` element to the plugin ``:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
jetty-maven-plugin
- @project.version@
+ {VERSION}
10
src/etc/jetty-jmx.xml
@@ -114,6 +114,7 @@ If you are using the link:#jetty-maven-plugin[jetty maven plugin] you should cop
----
+
[[enabling-jmxconnectorserver-for-remote-access]]
==== Enabling JMXConnectorServer for Remote Access
@@ -124,7 +125,7 @@ Unfortunately, this solution does not play well with firewalls and it is not fle
* Use Jetty's `ConnectorServer` class.
To enable use of this class, uncomment the correspondent portion in `etc/jetty-jmx.xml,` like this:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -151,7 +152,7 @@ For a complete guide to controlling authentication and authorization in JMX, see
To restrict access to the JMXConnectorServer, you can use this configuration, where the `jmx.password` and `jmx.access` files have the format specified in the blog entry above:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/administration/jndi/jndi-configuration.adoc b/jetty-documentation/src/main/asciidoc/administration/jndi/jndi-configuration.adoc
index fb8cf3563cd..12c92e49eea 100644
--- a/jetty-documentation/src/main/asciidoc/administration/jndi/jndi-configuration.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/jndi/jndi-configuration.adoc
@@ -25,7 +25,7 @@ runtime that you either cannot or cannot conveniently code into a
`web.xml env-entry`. In such cases, you can use `org.eclipse.jetty.plus.jndi.EnvEntry`, and even override an entry of
the same name in ` web.xml`.
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -66,7 +66,7 @@ application is __not portable__.
To use the `env-entry` configured above, use code in your
`servlet/filter/etc.`, such as:
-[source,java]
+[source, java, subs="{sub-order}"]
----
import javax.naming.InitialContext;
@@ -121,7 +121,7 @@ relational database, but you can use any implementation of a
`javax.sql.DataSource`. This example configures it as scoped to a web
app with the id of __wac__:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -147,7 +147,7 @@ from application lookups as `
Here's an example `web.xml` declaration for the datasource above:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
jdbc/myds
@@ -158,7 +158,7 @@ Here's an example `web.xml` declaration for the datasource above:
To look up your DataSource in your `servlet/filter/etc.`:
-[source,java]
+[source, java, subs="{sub-order}"]
----
import javax.naming.InitialContext;
import javax.sql.DataSource;
@@ -192,7 +192,7 @@ factories. You just need to ensure the implementation Jars are available
on Jetty's classpath. Here is an example of binding an
http://activemq.apache.org[ActiveMQ] in-JVM connection factory:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -209,7 +209,7 @@ http://activemq.apache.org[ActiveMQ] in-JVM connection factory:
The entry in `web.xml` would be:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
jms/connectionFactory
@@ -226,7 +226,7 @@ TODO: put in an example of a QUEUE from progress demo
Jetty also provides infrastructure for access to `javax.mail.Sessions`
from within an application:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -276,7 +276,7 @@ link:{JDURL}/org/eclipse/jetty/plus/jndi/Transaction.html[JNDI
Transaction] object in a Jetty config file. The following example
configures the http://www.atomikos.com/[Atomikos] transaction manager:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -293,7 +293,7 @@ you use for it in `web.xml`. For example:
In a context xml file:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -311,7 +311,7 @@ In a context xml file:
In `web.xml`:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
jdbc/mydatasource
@@ -333,7 +333,7 @@ to the `jdbc/mydatasource` resource as `
In a context xml file declare `jdbc/mydatasource`:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -353,7 +353,7 @@ Then in a `WEB-INF/jetty-env.xml` file, link the name
`jdbc/mydatasource` to the name you want to reference it as in
`web.xml`, which in this case is `jdbc/mydatasource1`:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
[
@@ -130,7 +130,7 @@ From a context xml file, you reference the Server instance as a Ref:
From a `WEB-INF/jetty-web.xml` file, you can reference the Server instance directly:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/administration/sessions/session-clustering-infinispan.adoc b/jetty-documentation/src/main/asciidoc/administration/sessions/session-clustering-infinispan.adoc
index 5ada3f1b7fb..de13bbb4fe4 100644
--- a/jetty-documentation/src/main/asciidoc/administration/sessions/session-clustering-infinispan.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/sessions/session-clustering-infinispan.adoc
@@ -63,7 +63,7 @@ The Infinispan module will have installed file called `$\{jetty.home}/etc/jetty-
This file configures an instance of the `InfinispanSessionIdManager` that will be shared across all webapps deployed on that server.
It looks like this:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
include::{SRCDIR}/jetty-infinispan/src/main/config/etc/jetty-infinispan.xml[]
----
@@ -89,7 +89,7 @@ The basic difference is how you get a reference to the Jetty `org.eclipse.jetty.
From a context xml file, you reference the Server instance as a Ref:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -128,7 +128,7 @@ From a context xml file, you reference the Server instance as a Ref:
From a `WEB-INF/jetty-web.xml` file, you can reference the Server instance directly:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/administration/sessions/session-clustering-jdbc.adoc b/jetty-documentation/src/main/asciidoc/administration/sessions/session-clustering-jdbc.adoc
index 2280f980eb0..969de5945dd 100644
--- a/jetty-documentation/src/main/asciidoc/administration/sessions/session-clustering-jdbc.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/sessions/session-clustering-jdbc.adoc
@@ -44,7 +44,7 @@ When using the jetty distribution, to enable jdbc session persistence, you will
You will also find the following properties, either in your base's start.d/jdbc-session.ini file or appended to your start.ini, depending on how you enabled the module:
-[source,java]
+[source, java, subs="{sub-order}"]
----
## Unique identifier for this node in the cluster
jetty.jdbcSession.workerName=node1
@@ -78,7 +78,7 @@ The jdbc-session module will have installed file called `$\{jetty.home}/etc/jett
This file configures an instance of the `JDBCSessionIdManager` that will be shared across all webapps deployed on that server.
It looks like this:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
include::{SRCDIR}/jetty-server/src/main/config/etc/jetty-jdbc-sessions.xml[]
----
@@ -87,7 +87,7 @@ As well as uncommenting and setting up appropriate values for the properties dis
As Jetty configuration files are direct mappings of XML to Java, it is straight forward to do this in code:
-[source,java]
+[source, java, subs="{sub-order}"]
----
Server server = new Server();
...
@@ -127,7 +127,7 @@ These classes have getter/setter methods for the table name and all columns.
Here's an example of changing the name of `JettySessionsId` table and its single column.
This example will use java code, but as explained above, you may also do this via a Jetty xml configuration file:
-[source,java]
+[source, java, subs="{sub-order}"]
----
JDBCSessionIdManager idManager = new JDBCSessionIdManager(server);
@@ -140,7 +140,7 @@ idManager.setSessionIdTableSchema(idTableSchema);
In a similar fashion, you can change the names of the table and columns for the `JettySessions` table.
*Note* that both the `SessionIdTableSchema` and the `SessionTableSchema` instances are set on the `JDBCSessionIdManager` class.
-[source,java]
+[source, java, subs="{sub-order}"]
----
JDBCSessionIdManager idManager = new JDBCSessionIdManager(server);
@@ -170,7 +170,7 @@ The basic difference is how you get a reference to the Jetty `org.eclipse.jetty.
From a context xml file, you reference the Server instance as a Ref:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
][
@@ -190,7 +190,7 @@ From a context xml file, you reference the Server instance as a Ref:
From a `WEB-INF/jetty-web.xml` file, you can reference the Server instance directly:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -211,7 +211,7 @@ From a `WEB-INF/jetty-web.xml` file, you can reference the Server instance direc
If you're embedding this in code:
-[source,java]
+[source, java, subs="{sub-order}"]
----
//assuming you have already set up the JDBCSessionIdManager as shown earlier
diff --git a/jetty-documentation/src/main/asciidoc/administration/sessions/session-clustering-mongodb.adoc b/jetty-documentation/src/main/asciidoc/administration/sessions/session-clustering-mongodb.adoc
index 47cc1659436..03b0eec2a13 100644
--- a/jetty-documentation/src/main/asciidoc/administration/sessions/session-clustering-mongodb.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/sessions/session-clustering-mongodb.adoc
@@ -51,7 +51,7 @@ To do that, you can use `--skip-file-validation=nosql` argument to start.jar on
You will also find the following properties, either in your base's `start.d/nosql.ini` file or appended to your `start.ini`, depending on how you enabled the module:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
## Unique identifier for this node in the cluster
jetty.nosqlSession.workerName=node1
@@ -75,7 +75,7 @@ The nosql module will have installed file called `$\{jetty.home}/etc/jetty-nosql
This file configures an instance of the `MongoSessionIdManager` that will be shared across all webapps deployed on that server.
It looks like this:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
include::{SRCDIR}/jetty-nosql/src/main/config/etc/jetty-nosql.xml[]
----
@@ -84,7 +84,7 @@ The `MongoSessionIdManager` needs access to a MongoDB cluster, and the `jetty-no
If you need to configure something else, you will need to edit this file.
Here's an example of a more complex setup to use a remote MongoDB instance:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -128,7 +128,7 @@ Here's an example of a more complex setup to use a remote MongoDB instance:
As Jetty configuration files are direct mappings of XML to Java, it is straight forward to do this in code:
-[source,java]
+[source, java, subs="{sub-order}"]
----
Server server = new Server();
@@ -184,7 +184,7 @@ The basic difference is how you get a reference to the Jetty `org.eclipse.jetty.
From a context xml file, you reference the Server instance as a Ref:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
][
@@ -205,7 +205,7 @@ From a context xml file, you reference the Server instance as a Ref:
From a `WEB-INF/jetty-web.xml` file, you can reference the Server instance directly:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -225,7 +225,7 @@ From a `WEB-INF/jetty-web.xml` file, you can reference the Server instance direc
If you're embedding this in code:
-[source,java]
+[source, java, subs="{sub-order}"]
----
//assuming you have already set up the MongoSessionIdManager as shown earlier
//and have a reference to the Server instance:
diff --git a/jetty-documentation/src/main/asciidoc/administration/sessions/setting-session-characteristics.adoc b/jetty-documentation/src/main/asciidoc/administration/sessions/setting-session-characteristics.adoc
index eaaf3c7bd2a..d7ba8e2cb53 100644
--- a/jetty-documentation/src/main/asciidoc/administration/sessions/setting-session-characteristics.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/sessions/setting-session-characteristics.adoc
@@ -72,7 +72,7 @@ The following sections provide examples of how to apply the init parameters.
You can set these parameters as context parameters in a web application's `WEB-INF/web.xml` file:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -101,7 +101,7 @@ You can set these parameters as context parameters in a web application's `WEB-I
You can configure init parameters on a web application, either in code, or in a Jetty context xml file equivalent:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -128,7 +128,7 @@ You can configure init parameters on a web application, either in code, or in a
You can configure init parameters directly on a `SessionManager` instance, either in code or the equivalent in xml:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -163,7 +163,7 @@ For full details, consult the http://docs.oracle.com/javaee/6/api/javax/servlet/
Below is an example of this implementation: a `ServletContextListener` retrieves the `SessionCookieConfig` and sets up some new values when the context is being initialized:
-[source,java]
+[source, java, subs="{sub-order}"]
----
import javax.servlet.SessionCookieConfig;
import javax.servlet.ServletContextEvent;
@@ -203,7 +203,7 @@ public class TestListener implements ServletContextListener
You can also use `web.xml` to configure the session handling characteristics instead: here's an example doing exactly the same as above instead of using code:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
);
----
You may also set the tracking mode in `web.xml`, e.g.:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -73,7 +73,7 @@ For example, the Wicket web framework requires the servlet environment to be ava
Using `SessionManager.setLazyLoad(true)`, Jetty loads sessions lazily either when it receives the first request for a session, or the session scavenger runs for the first time, whichever happens first.
Here's how the configuration looks in XML:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -91,7 +91,7 @@ Here's how the configuration looks in XML:
To enable session persistence for the Jetty Maven plugin, set up the `HashSessionManager` in the configuration section like so:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
diff --git a/jetty-documentation/src/main/asciidoc/administration/startup/screen-empty-base-listconfig.adoc b/jetty-documentation/src/main/asciidoc/administration/startup/screen-empty-base-listconfig.adoc
index 672c2e609df..753ff2d97e9 100644
--- a/jetty-documentation/src/main/asciidoc/administration/startup/screen-empty-base-listconfig.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/startup/screen-empty-base-listconfig.adoc
@@ -14,7 +14,7 @@
// You may elect to redistribute this code under either of these licenses.
// ========================================================================
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
[mybase]$ java -jar /opt/jetty-distribution/start.jar --list-config
@@ -34,7 +34,7 @@ Java Environment:
Jetty Environment:
-----------------
- jetty.version = @project.version@
+ jetty.version = {VERSION}
jetty.home = /opt/jetty-distribution
jetty.base = /home/jetty/mybase
diff --git a/jetty-documentation/src/main/asciidoc/administration/startup/screen-empty-base.adoc b/jetty-documentation/src/main/asciidoc/administration/startup/screen-empty-base.adoc
index f06d03eecc0..bd28f5d04a6 100644
--- a/jetty-documentation/src/main/asciidoc/administration/startup/screen-empty-base.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/startup/screen-empty-base.adoc
@@ -14,7 +14,7 @@
// You may elect to redistribute this code under either of these licenses.
// ========================================================================
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
WARNING: Nothing to start, exiting ...
diff --git a/jetty-documentation/src/main/asciidoc/administration/startup/screen-http-webapp-deploy-listconfig.adoc b/jetty-documentation/src/main/asciidoc/administration/startup/screen-http-webapp-deploy-listconfig.adoc
index 82cb757616c..42232330bff 100644
--- a/jetty-documentation/src/main/asciidoc/administration/startup/screen-http-webapp-deploy-listconfig.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/startup/screen-http-webapp-deploy-listconfig.adoc
@@ -14,7 +14,7 @@
// You may elect to redistribute this code under either of these licenses.
// ========================================================================
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
[mybase]$ java -jar /opt/jetty-distribution/start.jar --list-config
@@ -34,7 +34,7 @@ Java Environment:
Jetty Environment:
-----------------
- jetty.version = @project.version@
+ jetty.version = {VERSION}
jetty.home = /opt/jetty-distribution
jetty.base = /home/jetty/mybase
@@ -64,15 +64,15 @@ Note: order presented here is how they would appear on the classpath.
changes to the --module=name command line options will be reflected here.
0: 3.1.0 | ${jetty.home}/lib/servlet-api-3.1.jar
1: 3.1.0.M0 | ${jetty.home}/lib/jetty-schemas-3.1.jar
- 2: @project.version@ | ${jetty.home}/lib/jetty-http-@project.version@.jar
- 3: @project.version@ | ${jetty.home}/lib/jetty-server-@project.version@.jar
- 4: @project.version@ | ${jetty.home}/lib/jetty-xml-@project.version@.jar
- 5: @project.version@ | ${jetty.home}/lib/jetty-util-@project.version@.jar
- 6: @project.version@ | ${jetty.home}/lib/jetty-io-@project.version@.jar
- 7: @project.version@ | ${jetty.home}/lib/jetty-security-@project.version@.jar
- 8: @project.version@ | ${jetty.home}/lib/jetty-servlet-@project.version@.jar
- 9: @project.version@ | ${jetty.home}/lib/jetty-webapp-@project.version@.jar
-10: @project.version@ | ${jetty.home}/lib/jetty-deploy-@project.version@.jar
+ 2: {VERSION} | ${jetty.home}/lib/jetty-http-{VERSION}.jar
+ 3: {VERSION} | ${jetty.home}/lib/jetty-server-{VERSION}.jar
+ 4: {VERSION} | ${jetty.home}/lib/jetty-xml-{VERSION}.jar
+ 5: {VERSION} | ${jetty.home}/lib/jetty-util-{VERSION}.jar
+ 6: {VERSION} | ${jetty.home}/lib/jetty-io-{VERSION}.jar
+ 7: {VERSION} | ${jetty.home}/lib/jetty-security-{VERSION}.jar
+ 8: {VERSION} | ${jetty.home}/lib/jetty-servlet-{VERSION}.jar
+ 9: {VERSION} | ${jetty.home}/lib/jetty-webapp-{VERSION}.jar
+10: {VERSION} | ${jetty.home}/lib/jetty-deploy-{VERSION}.jar
Jetty Active XMLs:
------------------
diff --git a/jetty-documentation/src/main/asciidoc/administration/startup/screen-http-webapp-deploy.adoc b/jetty-documentation/src/main/asciidoc/administration/startup/screen-http-webapp-deploy.adoc
index a6450a9f3b2..7a3287e04a3 100644
--- a/jetty-documentation/src/main/asciidoc/administration/startup/screen-http-webapp-deploy.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/startup/screen-http-webapp-deploy.adoc
@@ -14,7 +14,7 @@
// You may elect to redistribute this code under either of these licenses.
// ========================================================================
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
[mybase]$ java -jar /opt/jetty-distribution/start.jar --add-to-start=http,webapp,deploy
diff --git a/jetty-documentation/src/main/asciidoc/administration/startup/screen-list-modules.adoc b/jetty-documentation/src/main/asciidoc/administration/startup/screen-list-modules.adoc
index 3df66ec75e0..d5e945d1e58 100644
--- a/jetty-documentation/src/main/asciidoc/administration/startup/screen-list-modules.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/startup/screen-list-modules.adoc
@@ -14,7 +14,7 @@
// You may elect to redistribute this code under either of these licenses.
// ========================================================================
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
[mybase]$ java -jar /opt/jetty-distribution/start.jar --list-modules
diff --git a/jetty-documentation/src/main/asciidoc/administration/startup/start-jar.adoc b/jetty-documentation/src/main/asciidoc/administration/startup/start-jar.adoc
index e62531e1bd3..2a85fee05be 100644
--- a/jetty-documentation/src/main/asciidoc/administration/startup/start-jar.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/startup/start-jar.adoc
@@ -21,10 +21,10 @@ 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]
+[source, screen, subs="{sub-order}"]
....
-[jetty-distribution-@project.version@]$ java -jar start.jar
-2013-09-23 11:27:06.654:INFO:oejs.Server:main: jetty-@project.version@
+[jetty-distribution-{VERSION}]$ java -jar start.jar
+2013-09-23 11:27:06.654:INFO:oejs.Server:main: jetty-{VERSION}
...
....
@@ -175,7 +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]
+[source, screen, subs="{sub-order}"]
....
# generate module.dot
$ java -jar start.jar --module=websocket --write-module-graph=modules.dot
diff --git a/jetty-documentation/src/main/asciidoc/administration/startup/startup-base-vs-home.adoc b/jetty-documentation/src/main/asciidoc/administration/startup/startup-base-vs-home.adoc
index 4cf1619ca76..54e8648b069 100644
--- a/jetty-documentation/src/main/asciidoc/administration/startup/startup-base-vs-home.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/startup/startup-base-vs-home.adoc
@@ -61,9 +61,9 @@ enables the various demonstration webapps and server configurations.
How to use the demo-base directory as a Jetty Base directory.
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
-[jetty-distribution-@project.version@]$ ls -la
+[jetty-distribution-{VERSION}]$ ls -la
total 496
drwxrwxr-x 11 user group 4096 Oct 8 15:23 ./
drwxr-xr-x 14 user group 4096 Oct 8 13:04 ../
@@ -82,11 +82,11 @@ drwxrwxr-x 2 user group 4096 Oct 8 06:54 start.d/
-rw-rw-r-- 1 user group 71921 Sep 30 19:55 start.jar
-rw-rw-r-- 1 user group 336468 Sep 30 19:55 VERSION.txt
drwxrwxr-x 2 user group 4096 Oct 8 06:54 webapps/
-[jetty-distribution-@project.version@]$ cd demo-base
+[jetty-distribution-{VERSION}]$ cd demo-base
[demo-base]$ java -jar $JETTY_HOME/start.jar
2013-10-16 09:08:47.800:WARN::main: demo test-realm is deployed. DO NOT USE IN PRODUCTION!
-2013-10-16 09:08:47.802:INFO:oejs.Server:main: jetty-@project.version@
-2013-10-16 09:08:47.817:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/home/user/jetty-distribution-@project.version@/demo-base/webapps/] at interval 1
+2013-10-16 09:08:47.802:INFO:oejs.Server:main: jetty-{VERSION}
+2013-10-16 09:08:47.817:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/home/user/jetty-distribution-{VERSION}/demo-base/webapps/] at interval 1
2013-10-16 09:08:48.072:WARN::main: async-rest webapp is deployed. DO NOT USE IN PRODUCTION!
...
....
@@ -97,7 +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]
+[source, screen, subs="{sub-order}"]
....
[my-base]$ java -jar $JETTY_HOME/start.jar --list-config
@@ -114,9 +114,9 @@ Java Environment:
Jetty Environment:
-----------------
- jetty.home=/home/user/jetty-distribution-@project.version@
- jetty.base=/home/user/jetty-distribution-@project.version@/demo-base
- jetty.version=@project.version@
+ jetty.home=/home/user/jetty-distribution-{VERSION}
+ jetty.base=/home/user/jetty-distribution-{VERSION}/demo-base
+ jetty.version={VERSION}
JVM Arguments:
--------------
@@ -124,8 +124,8 @@ JVM Arguments:
System Properties:
------------------
- jetty.base = /home/user/jetty-distribution-@project.version@/demo-base
- jetty.home = /home/user/jetty-distribution-@project.version@
+ jetty.base = /home/user/jetty-distribution-{VERSION}/demo-base
+ jetty.home = /home/user/jetty-distribution-{VERSION}
Properties:
-----------
@@ -152,26 +152,26 @@ Jetty Server Classpath:
Version Information on 42 entries in the classpath.
Note: order presented here is how they would appear on the classpath.
changes to the --module=name command line options will be reflected here.
- 0: @project.version@ | ${jetty.home}/lib/jetty-client-@project.version@.jar
+ 0: {VERSION} | ${jetty.home}/lib/jetty-client-{VERSION}.jar
1: 1.4.1.v201005082020 | ${jetty.base}/lib/ext/javax.mail.glassfish-1.4.1.v201005082020.jar
- 2: @project.version@ | ${jetty.base}/lib/ext/test-mock-resources-@project.version@.jar
+ 2: {VERSION} | ${jetty.base}/lib/ext/test-mock-resources-{VERSION}.jar
3: (dir) | ${jetty.home}/resources
4: 3.1.0 | ${jetty.home}/lib/servlet-api-3.1.jar
5: 3.1.RC0 | ${jetty.home}/lib/jetty-schemas-3.1.jar
- 6: @project.version@ | ${jetty.home}/lib/jetty-http-@project.version@.jar
- 7: @project.version@ | ${jetty.home}/lib/jetty-continuation-@project.version@.jar
- 8: @project.version@ | ${jetty.home}/lib/jetty-server-@project.version@.jar
- 9: @project.version@ | ${jetty.home}/lib/jetty-xml-@project.version@.jar
-10: @project.version@ | ${jetty.home}/lib/jetty-util-@project.version@.jar
-11: @project.version@ | ${jetty.home}/lib/jetty-io-@project.version@.jar
-12: @project.version@ | ${jetty.home}/lib/jetty-jaas-@project.version@.jar
-13: @project.version@ | ${jetty.home}/lib/jetty-jndi-@project.version@.jar
+ 6: {VERSION} | ${jetty.home}/lib/jetty-http-{VERSION}.jar
+ 7: {VERSION} | ${jetty.home}/lib/jetty-continuation-{VERSION}.jar
+ 8: {VERSION} | ${jetty.home}/lib/jetty-server-{VERSION}.jar
+ 9: {VERSION} | ${jetty.home}/lib/jetty-xml-{VERSION}.jar
+10: {VERSION} | ${jetty.home}/lib/jetty-util-{VERSION}.jar
+11: {VERSION} | ${jetty.home}/lib/jetty-io-{VERSION}.jar
+12: {VERSION} | ${jetty.home}/lib/jetty-jaas-{VERSION}.jar
+13: {VERSION} | ${jetty.home}/lib/jetty-jndi-{VERSION}.jar
14: 1.1.0.v201105071233 | ${jetty.home}/lib/jndi/javax.activation-1.1.0.v201105071233.jar
15: 1.4.1.v201005082020 | ${jetty.home}/lib/jndi/javax.mail.glassfish-1.4.1.v201005082020.jar
16: 1.2 | ${jetty.home}/lib/jndi/javax.transaction-api-1.2.jar
-17: @project.version@ | ${jetty.home}/lib/jetty-rewrite-@project.version@.jar
-18: @project.version@ | ${jetty.home}/lib/jetty-security-@project.version@.jar
-19: @project.version@ | ${jetty.home}/lib/jetty-servlet-@project.version@.jar
+17: {VERSION} | ${jetty.home}/lib/jetty-rewrite-{VERSION}.jar
+18: {VERSION} | ${jetty.home}/lib/jetty-security-{VERSION}.jar
+19: {VERSION} | ${jetty.home}/lib/jetty-servlet-{VERSION}.jar
20: 3.0.0 | ${jetty.home}/lib/jsp/javax.el-3.0.0.jar
21: 1.2.0.v201105211821 | ${jetty.home}/lib/jsp/javax.servlet.jsp.jstl-1.2.0.v201105211821.jar
22: 2.3.2 | ${jetty.home}/lib/jsp/javax.servlet.jsp-2.3.2.jar
@@ -179,21 +179,21 @@ Note: order presented here is how they would appear on the classpath.
24: 2.3.3 | ${jetty.home}/lib/jsp/jetty-jsp-jdt-2.3.3.jar
25: 1.2.0.v201112081803 | ${jetty.home}/lib/jsp/org.apache.taglibs.standard.glassfish-1.2.0.v201112081803.jar
26: 3.8.2.v20130121-145325 | ${jetty.home}/lib/jsp/org.eclipse.jdt.core-3.8.2.v20130121.jar
-27: @project.version@ | ${jetty.home}/lib/jetty-plus-@project.version@.jar
-28: @project.version@ | ${jetty.home}/lib/jetty-webapp-@project.version@.jar
-29: @project.version@ | ${jetty.home}/lib/jetty-annotations-@project.version@.jar
+27: {VERSION} | ${jetty.home}/lib/jetty-plus-{VERSION}.jar
+28: {VERSION} | ${jetty.home}/lib/jetty-webapp-{VERSION}.jar
+29: {VERSION} | ${jetty.home}/lib/jetty-annotations-{VERSION}.jar
30: 4.1 | ${jetty.home}/lib/annotations/asm-4.1.jar
31: 4.1 | ${jetty.home}/lib/annotations/asm-commons-4.1.jar
32: 1.2 | ${jetty.home}/lib/annotations/javax.annotation-api-1.2.jar
-33: @project.version@ | ${jetty.home}/lib/jetty-deploy-@project.version@.jar
+33: {VERSION} | ${jetty.home}/lib/jetty-deploy-{VERSION}.jar
34: 1.0 | ${jetty.home}/lib/websocket/javax.websocket-api-1.0.jar
-35: @project.version@ | ${jetty.home}/lib/websocket/javax-websocket-client-impl-@project.version@.jar
-36: @project.version@ | ${jetty.home}/lib/websocket/javax-websocket-server-impl-@project.version@.jar
-37: @project.version@ | ${jetty.home}/lib/websocket/websocket-api-@project.version@.jar
-38: @project.version@ | ${jetty.home}/lib/websocket/websocket-client-@project.version@.jar
-39: @project.version@ | ${jetty.home}/lib/websocket/websocket-common-@project.version@.jar
-40: @project.version@ | ${jetty.home}/lib/websocket/websocket-server-@project.version@.jar
-41: @project.version@ | ${jetty.home}/lib/websocket/websocket-servlet-@project.version@.jar
+35: {VERSION} | ${jetty.home}/lib/websocket/javax-websocket-client-impl-{VERSION}.jar
+36: {VERSION} | ${jetty.home}/lib/websocket/javax-websocket-server-impl-{VERSION}.jar
+37: {VERSION} | ${jetty.home}/lib/websocket/websocket-api-{VERSION}.jar
+38: {VERSION} | ${jetty.home}/lib/websocket/websocket-client-{VERSION}.jar
+39: {VERSION} | ${jetty.home}/lib/websocket/websocket-common-{VERSION}.jar
+40: {VERSION} | ${jetty.home}/lib/websocket/websocket-server-{VERSION}.jar
+41: {VERSION} | ${jetty.home}/lib/websocket/websocket-servlet-{VERSION}.jar
Jetty Active XMLs:
------------------
@@ -223,7 +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]
+[source, screen, subs="{sub-order}"]
....
[my-base]$ cat start.ini
# Enable security via jaas, and configure it
@@ -282,14 +282,14 @@ 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]
+[source, screen, subs="{sub-order}"]
....
-[jetty-distribution-@project.version@]$ pwd
-/home/user/jetty-distribution-@project.version@
-[jetty-distribution-@project.version@]$ java -jar start.jar \
- jetty.home=/home/user/jetty-distribution-@project.version@ \
+[jetty-distribution-{VERSION}]$ pwd
+/home/user/jetty-distribution-{VERSION}
+[jetty-distribution-{VERSION}]$ java -jar start.jar \
+ jetty.home=/home/user/jetty-distribution-{VERSION} \
jetty.base=/home/user/my-base
-2013-10-16 09:08:47.802:INFO:oejs.Server:main: jetty-@project.version@
+2013-10-16 09:08:47.802:INFO:oejs.Server:main: jetty-{VERSION}
2013-10-16 09:08:47.817:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/home/user/my-base/webapps/] at interval 1
...
....
@@ -300,12 +300,12 @@ 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]
+[source, screen, subs="{sub-order}"]
....
-[jetty-distribution-@project.version@]$ pwd
-/home/user/jetty-distribution-@project.version@
-[jetty-distribution-@project.version@]$ java -jar start.jar jetty.base=/home/user/my-base
-2013-10-16 09:08:47.802:INFO:oejs.Server:main: jetty-@project.version@
+[jetty-distribution-{VERSION}]$ pwd
+/home/user/jetty-distribution-{VERSION}
+[jetty-distribution-{VERSION}]$ java -jar start.jar jetty.base=/home/user/my-base
+2013-10-16 09:08:47.802:INFO:oejs.Server:main: jetty-{VERSION}
2013-10-16 09:08:47.817:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/home/user/my-base/webapps/] at interval 1
...
....
@@ -318,13 +318,13 @@ 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]
+[source, screen, subs="{sub-order}"]
....
-[jetty-distribution-@project.version@]$ pwd
-/home/user/jetty-distribution-@project.version@
-[jetty-distribution-@project.version@]$ cd /home/user/my-base
-[my-base]$ java -jar /home/user/jetty-distribution-@project.version@/start.jar
-2013-10-16 09:08:47.802:INFO:oejs.Server:main: jetty-@project.version@
+[jetty-distribution-{VERSION}]$ pwd
+/home/user/jetty-distribution-{VERSION}
+[jetty-distribution-{VERSION}]$ cd /home/user/my-base
+[my-base]$ java -jar /home/user/jetty-distribution-{VERSION}/start.jar
+2013-10-16 09:08:47.802:INFO:oejs.Server:main: jetty-{VERSION}
2013-10-16 09:08:47.817:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/home/user/my-base/webapps/] at interval 1
...
....
diff --git a/jetty-documentation/src/main/asciidoc/administration/startup/startup-classpath.adoc b/jetty-documentation/src/main/asciidoc/administration/startup/startup-classpath.adoc
index 3665c09e3fa..6fa80a685bf 100644
--- a/jetty-documentation/src/main/asciidoc/administration/startup/startup-classpath.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/startup/startup-classpath.adoc
@@ -67,7 +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]
+[source, screen, subs="{sub-order}"]
....
[demo-base]$ java -jar $JETTY_HOME/start.jar --list-classpath
@@ -76,26 +76,26 @@ Jetty Server Classpath:
Version Information on 42 entries in the classpath.
Note: order presented here is how they would appear on the classpath.
changes to the --module=name command line options will be reflected here.
- 0: @project.version@ | ${jetty.home}/lib/jetty-client-@project.version@.jar
+ 0: {VERSION} | ${jetty.home}/lib/jetty-client-{VERSION}.jar
1: 1.4.1.v201005082020 | ${jetty.base}/lib/ext/javax.mail.glassfish-1.4.1.v201005082020.jar
- 2: @project.version@ | ${jetty.base}/lib/ext/test-mock-resources-@project.version@.jar
+ 2: {VERSION} | ${jetty.base}/lib/ext/test-mock-resources-{VERSION}.jar
3: (dir) | ${jetty.home}/resources
4: 3.1.0 | ${jetty.home}/lib/servlet-api-3.1.jar
5: 3.1.RC0 | ${jetty.home}/lib/jetty-schemas-3.1.jar
- 6: @project.version@ | ${jetty.home}/lib/jetty-http-@project.version@.jar
- 7: @project.version@ | ${jetty.home}/lib/jetty-continuation-@project.version@.jar
- 8: @project.version@ | ${jetty.home}/lib/jetty-server-@project.version@.jar
- 9: @project.version@ | ${jetty.home}/lib/jetty-xml-@project.version@.jar
-10: @project.version@ | ${jetty.home}/lib/jetty-util-@project.version@.jar
-11: @project.version@ | ${jetty.home}/lib/jetty-io-@project.version@.jar
-12: @project.version@ | ${jetty.home}/lib/jetty-jaas-@project.version@.jar
-13: @project.version@ | ${jetty.home}/lib/jetty-jndi-@project.version@.jar
+ 6: {VERSION} | ${jetty.home}/lib/jetty-http-{VERSION}.jar
+ 7: {VERSION} | ${jetty.home}/lib/jetty-continuation-{VERSION}.jar
+ 8: {VERSION} | ${jetty.home}/lib/jetty-server-{VERSION}.jar
+ 9: {VERSION} | ${jetty.home}/lib/jetty-xml-{VERSION}.jar
+10: {VERSION} | ${jetty.home}/lib/jetty-util-{VERSION}.jar
+11: {VERSION} | ${jetty.home}/lib/jetty-io-{VERSION}.jar
+12: {VERSION} | ${jetty.home}/lib/jetty-jaas-{VERSION}.jar
+13: {VERSION} | ${jetty.home}/lib/jetty-jndi-{VERSION}.jar
14: 1.1.0.v201105071233 | ${jetty.home}/lib/jndi/javax.activation-1.1.0.v201105071233.jar
15: 1.4.1.v201005082020 | ${jetty.home}/lib/jndi/javax.mail.glassfish-1.4.1.v201005082020.jar
16: 1.2 | ${jetty.home}/lib/jndi/javax.transaction-api-1.2.jar
-17: @project.version@ | ${jetty.home}/lib/jetty-rewrite-@project.version@.jar
-18: @project.version@ | ${jetty.home}/lib/jetty-security-@project.version@.jar
-19: @project.version@ | ${jetty.home}/lib/jetty-servlet-@project.version@.jar
+17: {VERSION} | ${jetty.home}/lib/jetty-rewrite-{VERSION}.jar
+18: {VERSION} | ${jetty.home}/lib/jetty-security-{VERSION}.jar
+19: {VERSION} | ${jetty.home}/lib/jetty-servlet-{VERSION}.jar
20: 3.0.0 | ${jetty.home}/lib/jsp/javax.el-3.0.0.jar
21: 1.2.0.v201105211821 | ${jetty.home}/lib/jsp/javax.servlet.jsp.jstl-1.2.0.v201105211821.jar
22: 2.3.2 | ${jetty.home}/lib/jsp/javax.servlet.jsp-2.3.2.jar
@@ -103,21 +103,21 @@ Note: order presented here is how they would appear on the classpath.
24: 2.3.3 | ${jetty.home}/lib/jsp/jetty-jsp-jdt-2.3.3.jar
25: 1.2.0.v201112081803 | ${jetty.home}/lib/jsp/org.apache.taglibs.standard.glassfish-1.2.0.v201112081803.jar
26: 3.8.2.v20130121-145325 | ${jetty.home}/lib/jsp/org.eclipse.jdt.core-3.8.2.v20130121.jar
-27: @project.version@ | ${jetty.home}/lib/jetty-plus-@project.version@.jar
-28: @project.version@ | ${jetty.home}/lib/jetty-webapp-@project.version@.jar
-29: @project.version@ | ${jetty.home}/lib/jetty-annotations-@project.version@.jar
+27: {VERSION} | ${jetty.home}/lib/jetty-plus-{VERSION}.jar
+28: {VERSION} | ${jetty.home}/lib/jetty-webapp-{VERSION}.jar
+29: {VERSION} | ${jetty.home}/lib/jetty-annotations-{VERSION}.jar
30: 4.1 | ${jetty.home}/lib/annotations/asm-4.1.jar
31: 4.1 | ${jetty.home}/lib/annotations/asm-commons-4.1.jar
32: 1.2 | ${jetty.home}/lib/annotations/javax.annotation-api-1.2.jar
-33: @project.version@ | ${jetty.home}/lib/jetty-deploy-@project.version@.jar
+33: {VERSION} | ${jetty.home}/lib/jetty-deploy-{VERSION}.jar
34: 1.0 | ${jetty.home}/lib/websocket/javax.websocket-api-1.0.jar
-35: @project.version@ | ${jetty.home}/lib/websocket/javax-websocket-client-impl-@project.version@.jar
-36: @project.version@ | ${jetty.home}/lib/websocket/javax-websocket-server-impl-@project.version@.jar
-37: @project.version@ | ${jetty.home}/lib/websocket/websocket-api-@project.version@.jar
-38: @project.version@ | ${jetty.home}/lib/websocket/websocket-client-@project.version@.jar
-39: @project.version@ | ${jetty.home}/lib/websocket/websocket-common-@project.version@.jar
-40: @project.version@ | ${jetty.home}/lib/websocket/websocket-server-@project.version@.jar
-41: @project.version@ | ${jetty.home}/lib/websocket/websocket-servlet-@project.version@.jar
+35: {VERSION} | ${jetty.home}/lib/websocket/javax-websocket-client-impl-{VERSION}.jar
+36: {VERSION} | ${jetty.home}/lib/websocket/javax-websocket-server-impl-{VERSION}.jar
+37: {VERSION} | ${jetty.home}/lib/websocket/websocket-api-{VERSION}.jar
+38: {VERSION} | ${jetty.home}/lib/websocket/websocket-client-{VERSION}.jar
+39: {VERSION} | ${jetty.home}/lib/websocket/websocket-common-{VERSION}.jar
+40: {VERSION} | ${jetty.home}/lib/websocket/websocket-server-{VERSION}.jar
+41: {VERSION} | ${jetty.home}/lib/websocket/websocket-servlet-{VERSION}.jar
....
Of note is that an attempt is made to list the internally declared
diff --git a/jetty-documentation/src/main/asciidoc/administration/startup/startup-overview.adoc b/jetty-documentation/src/main/asciidoc/administration/startup/startup-overview.adoc
index 4168eedc8f6..29df8b8da5d 100644
--- a/jetty-documentation/src/main/asciidoc/administration/startup/startup-overview.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/startup/startup-overview.adoc
@@ -87,10 +87,10 @@ XML Files::
The simplest way to start Jetty is via the `start.jar` mechanism using
the following Java command line:
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
-[user]$ cd jetty-distribution-@project.version@
-[jetty-distribution-@project.version@]$ java -jar start.jar --module=http jetty.http.port=8080
+[user]$ cd jetty-distribution-{VERSION}
+[jetty-distribution-{VERSION}]$ java -jar start.jar --module=http jetty.http.port=8080
....
This command uses the `start.jar` mechanism to bootstrap the classpath,
@@ -98,9 +98,9 @@ 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]
+[source, screen, subs="{sub-order}"]
....
-[jetty-distribution-@project.version@]$ cat modules/http.mod
+[jetty-distribution-{VERSION}]$ cat modules/http.mod
[depend]
server
@@ -121,9 +121,9 @@ 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]
+[source, screen, subs="{sub-order}"]
....
-[jetty-distribution-@project.version@]$ cat modules/server.mod
+[jetty-distribution-{VERSION}]$ cat modules/server.mod
[lib]
lib/servlet-api-3.1.jar
lib/jetty-http-${jetty.version}.jar
@@ -148,9 +148,9 @@ line required to start Jetty.
Another way to see this is by asking Jetty what its configuration looks
like:
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
-[jetty-distribution-@project.version@]$ java -jar start.jar --module=http jetty.http.port=9099 --list-config
+[jetty-distribution-{VERSION}]$ java -jar start.jar --module=http jetty.http.port=9099 --list-config
Java Environment:
-----------------
@@ -165,9 +165,9 @@ Java Environment:
Jetty Environment:
-----------------
- jetty.home=/opt/jetty/jetty-distribution-@project.version@
- jetty.base=/opt/jetty/jetty-distribution-@project.version@
- jetty.version=@project.version@
+ jetty.home=/opt/jetty/jetty-distribution-{VERSION}
+ jetty.base=/opt/jetty/jetty-distribution-{VERSION}
+ jetty.version={VERSION}
JVM Arguments:
--------------
@@ -175,8 +175,8 @@ JVM Arguments:
System Properties:
------------------
- jetty.home = /opt/jetty/jetty-distribution-@project.version@
- jetty.base = /opt/jetty/jetty-distribution-@project.version@
+ jetty.home = /opt/jetty/jetty-distribution-{VERSION}
+ jetty.base = /opt/jetty/jetty-distribution-{VERSION}
Properties:
-----------
@@ -189,11 +189,11 @@ Note: order presented here is how they would appear on the classpath.
changes to the --module=name command line options will be reflected here.
0: 3.1.0 | ${jetty.home}/lib/servlet-api-3.1.jar
1: 3.1.RC0 | ${jetty.home}/lib/jetty-schemas-3.1.jar
- 2: @project.version@ | ${jetty.home}/lib/jetty-http-@project.version@.jar
- 3: @project.version@ | ${jetty.home}/lib/jetty-server-@project.version@.jar
- 4: @project.version@ | ${jetty.home}/lib/jetty-xml-@project.version@.jar
- 5: @project.version@ | ${jetty.home}/lib/jetty-util-@project.version@.jar
- 6: @project.version@ | ${jetty.home}/lib/jetty-io-@project.version@.jar
+ 2: {VERSION} | ${jetty.home}/lib/jetty-http-{VERSION}.jar
+ 3: {VERSION} | ${jetty.home}/lib/jetty-server-{VERSION}.jar
+ 4: {VERSION} | ${jetty.home}/lib/jetty-xml-{VERSION}.jar
+ 5: {VERSION} | ${jetty.home}/lib/jetty-util-{VERSION}.jar
+ 6: {VERSION} | ${jetty.home}/lib/jetty-io-{VERSION}.jar
Jetty Active XMLs:
------------------
@@ -210,14 +210,14 @@ using a traditional Java command line.
The following is the equivalent `java` command line for what the
`start.jar` bootstrap above performs.
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
-[user]$ cd jetty-distribution-@project.version@
-[jetty-distribution-@project.version@]$ echo jetty.http.port=8080 > /tmp/jetty.properties
-[jetty-distribution-@project.version@]$ export JETTY_HOME=`pwd`
-[jetty-distribution-@project.version@]$ export JETTY_BASE=`pwd`
-[jetty-distribution-@project.version@]$ export JETTY_VERSION="${project.version}"
-[jetty-distribution-@project.version@]$ java -Djetty.home=$JETTY_HOME \
+[user]$ cd jetty-distribution-{VERSION}
+[jetty-distribution-{VERSION}]$ echo jetty.http.port=8080 > /tmp/jetty.properties
+[jetty-distribution-{VERSION}]$ export JETTY_HOME=`pwd`
+[jetty-distribution-{VERSION}]$ export JETTY_BASE=`pwd`
+[jetty-distribution-{VERSION}]$ export JETTY_VERSION="${project.version}"
+[jetty-distribution-{VERSION}]$ java -Djetty.home=$JETTY_HOME \
-Djetty.base=$JETTY_BASE \
-cp \
$JETTY_HOME/lib/servlet-api-3.1.jar\
@@ -242,10 +242,10 @@ 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]
+[source, screen, subs="{sub-order}"]
....
-[user]$ cd jetty-distribution-@project.version@
-[jetty-distribution-@project.version@]$ mkdir example-base
+[user]$ cd jetty-distribution-{VERSION}
+[jetty-distribution-{VERSION}]$ mkdir example-base
[example-base]$ cd example-base
[example-base]$ ls -la
total 8
@@ -266,7 +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]
+[source, screen, subs="{sub-order}"]
....
[example-base]$ java -jar $JETTY_HOME/start.jar
....
diff --git a/jetty-documentation/src/main/asciidoc/administration/startup/startup-unix-service.adoc b/jetty-documentation/src/main/asciidoc/administration/startup/startup-unix-service.adoc
index 971614eeedf..a8107272430 100644
--- a/jetty-documentation/src/main/asciidoc/administration/startup/startup-unix-service.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/startup/startup-unix-service.adoc
@@ -27,27 +27,27 @@ 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]
+[source, screen, subs="{sub-order}"]
....
-[/opt/jetty]# tar -zxf /home/user/downloads/jetty-distribution-@project.version@.tar.gz
-[/opt/jetty]# cd jetty-distribution-@project.version@/
-[/opt/jetty/jetty-distribution-@project.version@]# ls
+[/opt/jetty]# tar -zxf /home/user/downloads/jetty-distribution-{VERSION}.tar.gz
+[/opt/jetty]# cd jetty-distribution-{VERSION}/
+[/opt/jetty/jetty-distribution-{VERSION}]# ls
bin lib modules resources start.jar
demo-base license-eplv10-aslv20.html notice.html start.d VERSION.txt
etc logs README.TXT start.ini webapps
-[/opt/jetty/jetty-distribution-@project.version@]# cp bin/jetty.sh /etc/init.d/jetty
-[/opt/jetty/jetty-distribution-@project.version@]# echo JETTY_HOME=`pwd` > /etc/default/jetty
-[/opt/jetty/jetty-distribution-@project.version@]# cat /etc/default/jetty
-JETTY_HOME=/opt/jetty/jetty-distribution-@project.version@
+[/opt/jetty/jetty-distribution-{VERSION}]# cp bin/jetty.sh /etc/init.d/jetty
+[/opt/jetty/jetty-distribution-{VERSION}]# echo JETTY_HOME=`pwd` > /etc/default/jetty
+[/opt/jetty/jetty-distribution-{VERSION}]# cat /etc/default/jetty
+JETTY_HOME=/opt/jetty/jetty-distribution-{VERSION}
-[/opt/jetty/jetty-distribution-@project.version@]# service jetty start
+[/opt/jetty/jetty-distribution-{VERSION}]# service jetty start
Starting Jetty: OK Wed Nov 20 10:26:53 MST 2013
....
From this simple demonstration we can see that Jetty started
successfully as a Unix Service from the
-`/opt/jetty/jetty-distribution-@project.version@` directory.
+`/opt/jetty/jetty-distribution-{VERSION}` directory.
This looks all fine and dandy, however you are running a default Jetty
on the root user id.
@@ -62,7 +62,7 @@ The techniques outlined here assume an installation on Linux
Prepare some empty directories to work with.
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
# mkdir -p /opt/jetty
# mkdir -p /opt/web/mybase
@@ -89,7 +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]
+[source, screen, subs="{sub-order}"]
....
# apt-get install openjdk-7-jdk
....
@@ -97,7 +97,7 @@ you have it installed.
Or download Java 7 from:
http://www.oracle.com/technetwork/java/javase/downloads/index.html
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
# java -version
java version "1.6.0_27"
@@ -129,7 +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]
+[source, screen, subs="{sub-order}"]
....
# useradd --user-group --shell /bin/false --home-dir /opt/jetty/temp jetty
....
@@ -143,11 +143,11 @@ link:#jetty-downloading[Official Eclipse Download Site]
Unpack it into place.
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
-[/opt/jetty]# tar -zxf /home/user/Downloads/jetty-distribution-@project.version@.tar.gz
+[/opt/jetty]# tar -zxf /home/user/Downloads/jetty-distribution-{VERSION}.tar.gz
[/opt/jetty]# ls -F
-jetty-distribution-@project.version@/
+jetty-distribution-{VERSION}/
[/opt/jetty]# mkdir /opt/jetty/temp
....
@@ -171,11 +171,11 @@ ____
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]
+[source, screen, subs="{sub-order}"]
....
# cd /opt/web/mybase/
[/opt/web/mybase]# ls
-[/opt/web/mybase]# java -jar /opt/jetty/jetty-distribution-@project.version@/start.jar \
+[/opt/web/mybase]# java -jar /opt/jetty/jetty-distribution-{VERSION}/start.jar \
--add-to-start=deploy,http,logging
WARNING: deploy initialised in ${jetty.base}/start.ini (appended)
WARNING: deploy enabled in ${jetty.base}/start.ini
@@ -211,7 +211,7 @@ up and configuring a `${jetty.base}` directory.
Copy your war file into place.
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
# cp /home/user/projects/mywebsite.war /opt/web/mybase/webapps/
....
@@ -223,7 +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]
+[source, screen, subs="{sub-order}"]
....
# grep jetty.http.port /opt/web/mybase/start.ini
jetty.port=80
@@ -232,7 +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]
+[source, screen, subs="{sub-order}"]
....
# chown --recursive jetty /opt/jetty
# chown --recursive jetty /opt/web/mybase
@@ -241,53 +241,53 @@ 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]
+[source, screen, subs="{sub-order}"]
....
-# 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
+# cp /opt/jetty/jetty-distribution-{VERSION}/bin/jetty.sh /etc/init.d/jetty
+# echo "JETTY_HOME=/opt/jetty/jetty-distribution-{VERSION}" > /etc/default/jetty
# echo "JETTY_BASE=/opt/web/mybase" >> /etc/default/jetty
# echo "TMPDIR=/opt/jetty/temp" >> /etc/default/jetty
....
Test out the configuration
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
# service jetty status
Checking arguments to Jetty:
START_INI = /opt/web/mybase/start.ini
-JETTY_HOME = /opt/jetty/jetty-distribution-@project.version@
+JETTY_HOME = /opt/jetty/jetty-distribution-{VERSION}
JETTY_BASE = /opt/web/mybase
-JETTY_CONF = /opt/jetty/jetty-distribution-@project.version@/etc/jetty.conf
+JETTY_CONF = /opt/jetty/jetty-distribution-{VERSION}/etc/jetty.conf
JETTY_PID = /var/run/jetty.pid
-JETTY_START = /opt/jetty/jetty-distribution-@project.version@/start.jar
+JETTY_START = /opt/jetty/jetty-distribution-{VERSION}/start.jar
JETTY_LOGS = /opt/web/mybase/logs
CLASSPATH =
JAVA = /usr/bin/java
JAVA_OPTIONS = -Djetty.state=/opt/web/mybase/jetty.state
-Djetty.logs=/opt/web/mybase/logs
- -Djetty.home=/opt/jetty/jetty-distribution-@project.version@
+ -Djetty.home=/opt/jetty/jetty-distribution-{VERSION}
-Djetty.base=/opt/web/mybase
-Djava.io.tmpdir=/opt/jetty/temp
JETTY_ARGS = jetty-logging.xml jetty-started.xml
RUN_CMD = /usr/bin/java
-Djetty.state=/opt/web/mybase/jetty.state
-Djetty.logs=/opt/web/mybase/logs
- -Djetty.home=/opt/jetty/jetty-distribution-@project.version@
+ -Djetty.home=/opt/jetty/jetty-distribution-{VERSION}
-Djetty.base=/opt/web/mybase
-Djava.io.tmpdir=/opt/jetty/temp
- -jar /opt/jetty/jetty-distribution-@project.version@/start.jar
+ -jar /opt/jetty/jetty-distribution-{VERSION}/start.jar
jetty-logging.xml
jetty-started.xml
....
You now have a configured `${jetty.base}` in `/opt/web/mybase` and a
-jetty-distribution in `/opt/jetty/jetty-distribution-@project.version@`,
+jetty-distribution in `/opt/jetty/jetty-distribution-{VERSION}`,
along with the service level files necessary to start the service.
Go ahead, start it.
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
# service jetty start
Starting Jetty: OK Wed Nov 20 12:35:28 MST 2013
diff --git a/jetty-documentation/src/main/asciidoc/administration/startup/startup-windows-service.adoc b/jetty-documentation/src/main/asciidoc/administration/startup/startup-windows-service.adoc
index 45976590b86..3bfd779d9b1 100644
--- a/jetty-documentation/src/main/asciidoc/administration/startup/startup-windows-service.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/startup/startup-windows-service.adoc
@@ -29,7 +29,7 @@ The techniques outlined here are based on Windows 7 (64-bit), using JDK
Prepare some empty directories to work with.
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
C:\> mkdir opt
C:\> cd opt
@@ -78,7 +78,7 @@ C:\opt\temp::
Or download Java 7 from:
http://www.oracle.com/technetwork/java/javase/downloads/index.html
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
C:\opt>java -version
java version "1.7.0_45"
@@ -90,13 +90,13 @@ Grab a copy of the ZIP distribution from the
link:#jetty-downloading[Official Eclipse Download Site]
Open it up the downloaded Zip in Windows Explorer and drag the contents
-of the `jetty-distribution-@project.version@` directory into place at
+of the `jetty-distribution-{VERSION}` directory into place at
`C:\opt\jetty`
Once you are complete, the contents of the `C:\opt\jetty` directory
should look like this:
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
C:\opt\jetty>dir
Volume in drive C has no label.
@@ -143,7 +143,7 @@ file.
Once you are complete, the contents of `C:\opt` directory should look
like this:
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
C:\opt> dir
Volume in drive C has no label.
@@ -168,7 +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]
+[source, screen, subs="{sub-order}"]
....
C:\opt\myappbase>java -jar ..\jetty\start.jar --add-to-start=deploy,http,logging
@@ -221,7 +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]
+[source, screen, subs="{sub-order}"]
....
C:\opt\myappbase> copy C:\projects\mywebsite.war webapps\
....
diff --git a/jetty-documentation/src/main/asciidoc/administration/tuning/high-load.adoc b/jetty-documentation/src/main/asciidoc/administration/tuning/high-load.adoc
index c5680060ac3..366eda6278f 100644
--- a/jetty-documentation/src/main/asciidoc/administration/tuning/high-load.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/tuning/high-load.adoc
@@ -50,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ sysctl -w net.core.rmem_max=16777216
$ sysctl -w net.core.wmem_max=16777216
@@ -65,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ sysctl -w net.core.somaxconn=4096
@@ -74,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ sysctl -w net.core.netdev_max_backlog=16384
@@ -88,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ sysctl -w net.ipv4.ip_local_port_range="1024 65535"
@@ -112,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ sysctl net.ipv4.tcp_available_congestion_control
@@ -121,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ sysctl -w net.ipv4.tcp_congestion_control=cubic
diff --git a/jetty-documentation/src/main/asciidoc/administration/tuning/limit-load.adoc b/jetty-documentation/src/main/asciidoc/administration/tuning/limit-load.adoc
index 892a8fcb590..5266b9de026 100644
--- a/jetty-documentation/src/main/asciidoc/administration/tuning/limit-load.adoc
+++ b/jetty-documentation/src/main/asciidoc/administration/tuning/limit-load.adoc
@@ -24,7 +24,7 @@ To achieve optimal fair handling for all users of a server, it can be necessary
An instance of link:{JDURL}/org/eclipse/jetty/server/LowResourcesMonitor.html[LowResourcesMonitor] may be added to a Jetty Server to monitor for low resources situations and to take action to limit the number of idle connections on the server.
To configure the low resources monitor, you can uncomment the jetty-lowresources.xml line from the start.ini configuration file, which has the effect of including the following XML configuration:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
include::{SRCDIR}/jetty-server/src/main/config/etc/jetty-lowresources.xml[]
----
diff --git a/jetty-documentation/src/main/asciidoc/configuring/connectors/configuring-connectors.adoc b/jetty-documentation/src/main/asciidoc/configuring/connectors/configuring-connectors.adoc
index 401552b5aa0..1c1a789284f 100644
--- a/jetty-documentation/src/main/asciidoc/configuring/connectors/configuring-connectors.adoc
+++ b/jetty-documentation/src/main/asciidoc/configuring/connectors/configuring-connectors.adoc
@@ -54,7 +54,7 @@ Most other settings are for expert configuration only.
The services a link:{JDURL}/org/eclipse/jetty/server/ServerConnector.html[`ServerConnector`] instance uses are set by constructor injection and once instantiated cannot be changed.
Most of the services may be defaulted with null or 0 values so that a reasonable default is used, thus for most purposes only the Server and the connection factories need to be passed to the connector constructor. In Jetty XML (that is, in link:{SRCDIR}/jetty-server/src/main/config/etc/jetty-http.xml[`jetty-http.xml`]), you can do this by:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
]FORM Authentication demo
@@ -181,7 +181,7 @@ example of an xml file that defines an in-memory type of LoginService
called the
link:{JDURL}/org/eclipse/jetty/security/HashLoginService.html[HashLoginService]:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -205,7 +205,7 @@ telling the context the name of the LoginService, or passing it the
LoginService instance. Here's an example of doing both of these, using a
link:#deployable-descriptor-file[context xml file]:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -231,7 +231,7 @@ Alternatively, you can define a LoginService for just a single web
application. Here's how to define the same HashLoginService, but inside
a link:#deployable-descriptor-file[context xml file]:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -331,7 +331,7 @@ guest: guest,read-only
You configure the HashLoginService with a name and a reference to the
location of the properties file:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
-
@@ -348,7 +348,7 @@ You can also configure it to check the properties file regularly for
changes and reload when changes are detected. The reloadInterval is in
seconds:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -450,7 +450,7 @@ prefix.
You define a JDBCLoginService with the name of the realm and the
location of the properties file describing the database:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/configuring/security/configuring-form-size.adoc b/jetty-documentation/src/main/asciidoc/configuring/security/configuring-form-size.adoc
index 5953316cf74..fc828c053c8 100644
--- a/jetty-documentation/src/main/asciidoc/configuring/security/configuring-form-size.adoc
+++ b/jetty-documentation/src/main/asciidoc/configuring/security/configuring-form-size.adoc
@@ -34,7 +34,7 @@ To configure the form limits for a sinlge webapplication, the context
handler (or webappContext) instance must be configured using the
following methods:
-[source,java]
+[source, java, subs="{sub-order}"]
----
ContextHandler.setMaxFormContentSize(int maxSizeInBytes);
ContextHandler.setMaxFormKeys(int formKeys);
@@ -45,7 +45,7 @@ These methods may be called directly when embedding jetty, but more
commonly are configured from a context XML file or WEB-INF/jetty-web.xml
file:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -64,7 +64,7 @@ server attributes are inspected to see if a server wide limit has been
set on the size or keys. The following XML shows how these attributes
can be set in jetty.xml:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/configuring/security/jaas-support.adoc b/jetty-documentation/src/main/asciidoc/configuring/security/jaas-support.adoc
index 57a34034530..da96b883514 100644
--- a/jetty-documentation/src/main/asciidoc/configuring/security/jaas-support.adoc
+++ b/jetty-documentation/src/main/asciidoc/configuring/security/jaas-support.adoc
@@ -71,7 +71,7 @@ Configure a jetty `org.eclipse.jetty.jaas.JAASLoginService` to match the
in your web.xml file. For example, if the `web.xml`
contains a realm called "xyz" like so:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
FORM
@@ -86,7 +86,7 @@ contains a realm called "xyz" like so:
Then you need to create a JAASLoginService with the matching name of
"xyz":
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
Test JAAS Realm
@@ -106,7 +106,7 @@ security infrastructure, then you can declare your JAASLoginService in a
top-level jetty xml file as a bean that is added to the
org.eclipse.jetty.server.Server. Here's an example:
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -125,7 +125,7 @@ org.eclipse.jetty.server.Server. Here's an example:
webapp by creating a link:#deployable-descriptor-file[context xml] file
for the webapp, and specifying the JAASLoginService in it:
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -224,7 +224,7 @@ user role (Default: `org.eclipse.jetty.jaas.JAASRole`)
Here's an example of setting each of these (to their default values):
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
Test JAAS Realm
@@ -478,7 +478,7 @@ login module, add the RequestParameterCallback to the list of callback
handlers the login module uses, tell it which params you are interested
in, and then get the value of the parameter back. Here's an example:
-[source,java]
+[source, java, subs="{sub-order}"]
----
public class FooLoginModule extends AbstractLoginModule
diff --git a/jetty-documentation/src/main/asciidoc/configuring/security/jetty-home-and-jetty-base.adoc b/jetty-documentation/src/main/asciidoc/configuring/security/jetty-home-and-jetty-base.adoc
index 79d2139a965..79d17b82d25 100644
--- a/jetty-documentation/src/main/asciidoc/configuring/security/jetty-home-and-jetty-base.adoc
+++ b/jetty-documentation/src/main/asciidoc/configuring/security/jetty-home-and-jetty-base.adoc
@@ -57,20 +57,20 @@ maximum effect. It also includes a detailed explanation of how modules
work.
This example assumes you have the jetty-distribution unpacked in
-`/home/user/jetty-distribution-@project.version@.`
+`/home/user/jetty-distribution-{VERSION}.`
1. Create a base directory anywhere.
+
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
[/home/user]$ mkdir my-base
[/home/user]$ cd my-base
....
2. Add the modules for SSL, HTTP, and webapp deployment.
+
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
-[my-base]$ java -jar /home/user/jetty-distribution-@project.version@/start.jar --add-to-start=http,https,deploy
+[my-base]$ java -jar /home/user/jetty-distribution-{VERSION}/start.jar --add-to-start=http,https,deploy
ssl initialised in ${jetty.base}/start.ini (appended)
ssl enabled in ${jetty.base}/start.ini
@@ -87,7 +87,7 @@ server enabled in ${jetty.base}/start.ini
....
3. Look at your directory.
+
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
[my-base]$ ls -la
total 20
@@ -99,20 +99,20 @@ drwxrwxr-x 2 user group 4096 Oct 8 06:55 webapps/
....
4. Copy your WAR files into webapps.
+
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
[my-base]$ ls -la
[my-base]$ cp ~/code/project/target/gadget.war webapps/
....
5. Copy your keystore into place.
+
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
[my-base]$ cp ~/code/project/keystore etc/keystore
....
6. Edit the `start.ini` to configure your SSL settings.
+
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
[my-base]$ cat start.ini
....
@@ -165,9 +165,9 @@ http.timeout=30000
Look at the configuration you have at this point.
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
-[my-base]$ java -jar /home/user/jetty-distribution-@project.version@/start.jar --list-config
+[my-base]$ java -jar /home/user/jetty-distribution-{VERSION}/start.jar --list-config
Java Environment:
-----------------
@@ -182,9 +182,9 @@ Java Environment:
Jetty Environment:
-----------------
- jetty.home=/home/user/jetty-distribution-@project.version@
+ jetty.home=/home/user/jetty-distribution-{VERSION}
jetty.base=/home/user/my-base
- jetty.version=@project.version@
+ jetty.version={VERSION}
JVM Arguments:
--------------
@@ -193,7 +193,7 @@ JVM Arguments:
System Properties:
------------------
jetty.base = /home/user/my-base
- jetty.home = /home/user/jetty-distribution-@project.version@
+ jetty.home = /home/user/jetty-distribution-{VERSION}
Properties:
-----------
@@ -218,15 +218,15 @@ Note: order presented here is how they would appear on the classpath.
changes to the --module=name command line options will be reflected here.
0: 3.1.0 | ${jetty.home}/lib/servlet-api-3.1.jar
1: 3.1.RC0 | ${jetty.home}/lib/jetty-schemas-3.1.jar
- 2: @project.version@ | ${jetty.home}/lib/jetty-http-@project.version@.jar
- 3: @project.version@ | ${jetty.home}/lib/jetty-continuation-@project.version@.jar
- 4: @project.version@ | ${jetty.home}/lib/jetty-server-@project.version@.jar
- 5: @project.version@ | ${jetty.home}/lib/jetty-xml-@project.version@.jar
- 6: @project.version@ | ${jetty.home}/lib/jetty-util-@project.version@.jar
- 7: @project.version@ | ${jetty.home}/lib/jetty-io-@project.version@.jar
- 8: @project.version@ | ${jetty.home}/lib/jetty-servlet-@project.version@.jar
- 9: @project.version@ | ${jetty.home}/lib/jetty-webapp-@project.version@.jar
-10: @project.version@ | ${jetty.home}/lib/jetty-deploy-@project.version@.jar
+ 2: {VERSION} | ${jetty.home}/lib/jetty-http-{VERSION}.jar
+ 3: {VERSION} | ${jetty.home}/lib/jetty-continuation-{VERSION}.jar
+ 4: {VERSION} | ${jetty.home}/lib/jetty-server-{VERSION}.jar
+ 5: {VERSION} | ${jetty.home}/lib/jetty-xml-{VERSION}.jar
+ 6: {VERSION} | ${jetty.home}/lib/jetty-util-{VERSION}.jar
+ 7: {VERSION} | ${jetty.home}/lib/jetty-io-{VERSION}.jar
+ 8: {VERSION} | ${jetty.home}/lib/jetty-servlet-{VERSION}.jar
+ 9: {VERSION} | ${jetty.home}/lib/jetty-webapp-{VERSION}.jar
+10: {VERSION} | ${jetty.home}/lib/jetty-deploy-{VERSION}.jar
Jetty Active XMLs:
------------------
@@ -238,10 +238,10 @@ Jetty Active XMLs:
Now start Jetty.
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
-[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@
+[my-base]$ java -jar /home/user/jetty-distribution-{VERSION}/start.jar
+2013-10-08 07:06:55.837:INFO:oejs.Server:main: jetty-{VERSION}
2013-10-08 07:06:55.853:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/home/user/my-base/webapps/] at interval 1
2013-10-08 07:06:55.872:INFO:oejs.ServerConnector:main: Started ServerConnector@72974691{HTTP/1.1}{0.0.0.0:8080}
....
@@ -268,9 +268,9 @@ a single unit, with dependencies on other modules.
You can see the list of modules:
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
-[my-base]$ java -jar /home/user/jetty-distribution-@project.version@/start.jar --list-modules
+[my-base]$ java -jar /home/user/jetty-distribution-{VERSION}/start.jar --list-modules
Jetty All Available Modules:
----------------------------
@@ -458,9 +458,9 @@ easier to edit the `${jetty.base}/start.ini`.
If you want to start using a new module:
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
-[my-base] $ java -jar ../jetty-distribution-@project.version@/start.jar --add-to-start=https
+[my-base] $ java -jar ../jetty-distribution-{VERSION}/start.jar --add-to-start=https
....
This adds the `--module=` lines and associated properties (the
@@ -494,12 +494,12 @@ For more information on the `start.jar` in 9.1, see xref:start-jar[].
==== Summary of Configuring SSL in Jetty 9.1
1. Download and unpack Jetty 9.1 into
-`/home/user/jetty-distribution-@project.version@`.
+`/home/user/jetty-distribution-{VERSION}`.
2. Go to your base directory and just use the distribution, no editing.
+
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
-[my-base]$ java -jar /home/user/jetty-distribution-@project.version@/start.jar
+[my-base]$ java -jar /home/user/jetty-distribution-{VERSION}/start.jar
....
* The Jetty 9.1 distribution provides, out of the box, the XML
configuration files, in this case `jetty-http.xml` and `jetty-ssl.xml`.
@@ -529,9 +529,9 @@ modules as well.
You can see what the configuration looks like, after all of the modules
are resolved, without starting Jetty via:
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
-[my-base] $ java -jar ../jetty-distribution-@project.version@/start.jar --list-config
+[my-base] $ java -jar ../jetty-distribution-{VERSION}/start.jar --list-config
....
Just because the JARs exist on disk does not mean that they are in use.
@@ -541,7 +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]
+[source, screen, subs="{sub-order}"]
....
-[my-base]$ java -jar ~/jetty-distribution-@project.version@/start.jar --list-config
+[my-base]$ java -jar ~/jetty-distribution-{VERSION}/start.jar --list-config
....
diff --git a/jetty-documentation/src/main/asciidoc/configuring/security/secure-passwords.adoc b/jetty-documentation/src/main/asciidoc/configuring/security/secure-passwords.adoc
index 6fbab51ccd9..5a4d4d913e6 100644
--- a/jetty-documentation/src/main/asciidoc/configuring/security/secure-passwords.adoc
+++ b/jetty-documentation/src/main/asciidoc/configuring/security/secure-passwords.adoc
@@ -38,7 +38,7 @@ generate all varieties of passwords.
Run it without arguments to see usage instructions:
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
$ export JETTY_VERSION=9.0.0-SNAPSHOT
@@ -53,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ export JETTY_VERSION=9.0.0.RC0
@@ -93,7 +93,7 @@ You can also use obfuscated passwords in jetty xml files where a plain
text password is usually needed. Here's an example setting the password
for a JDBC Datasource with obfuscation:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/configuring/security/serving-aliased-files.adoc b/jetty-documentation/src/main/asciidoc/configuring/security/serving-aliased-files.adoc
index b4837da9b9b..804a4b55c54 100644
--- a/jetty-documentation/src/main/asciidoc/configuring/security/serving-aliased-files.adoc
+++ b/jetty-documentation/src/main/asciidoc/configuring/security/serving-aliased-files.adoc
@@ -116,7 +116,7 @@ An application is free to implement its own Alias checking. Alias
Checkers can be installed in a context via the following XML used in a
context deployer file or `WEB-INF/jetty-web.xml`:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/configuring/security/spnego-support.adoc b/jetty-documentation/src/main/asciidoc/configuring/security/spnego-support.adoc
index ccd0fa3b312..be4e9aab0ff 100644
--- a/jetty-documentation/src/main/asciidoc/configuring/security/spnego-support.adoc
+++ b/jetty-documentation/src/main/asciidoc/configuring/security/spnego-support.adoc
@@ -59,7 +59,7 @@ helpful:
Spengo Authentication must be enabled in the webapp in the following
way. The name of the role will be different for your network.
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -89,7 +89,7 @@ embedded, via the jetty.xml or in a context file for the webapp.
This is what the configuration within a jetty xml file would look like.
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -107,7 +107,7 @@ This is what the configuration within a jetty xml file would look like.
This is what the configuration within a context xml file would look
like.
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -142,7 +142,7 @@ for the http server. To do this use a process similar to this:
On the windows active domain controller run:
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
$ setspn -A HTTP/linux.mortbay.org ADUser
@@ -152,7 +152,7 @@ $ setspn -A HTTP/linux.mortbay.org ADUser
To create the keytab file use the following process:
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
$ 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
diff --git a/jetty-documentation/src/main/asciidoc/development/ant/jetty-ant.adoc b/jetty-documentation/src/main/asciidoc/development/ant/jetty-ant.adoc
index 571a44d6d00..595b850c8bb 100644
--- a/jetty-documentation/src/main/asciidoc/development/ant/jetty-ant.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/ant/jetty-ant.adoc
@@ -21,7 +21,7 @@ The Ant Jetty plugin is a part of Jetty 9 under the `jetty-ant` module.
This plugin makes it possible to start a Jetty web server directly from the Ant build script, and to embed the Jetty web server inside your build process.
Its purpose is to provide almost the same functionality as the Jetty plugin for Maven: dynamic application reloading, working directly on web application sources, and tightly integrating with the build system.
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
@@ -49,7 +49,7 @@ Now you're ready to edit or create your Ant `build.xml` file.
Begin with an empty `build.xml`:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -58,7 +58,7 @@ Begin with an empty `build.xml`:
Add a `` that imports all available Jetty tasks:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -74,7 +74,7 @@ Add a `` that imports all available Jetty tasks:
Now you are ready to add a new target for running Jetty:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -98,7 +98,7 @@ This is the minimal configuration you need. You can now start Jetty on the defau
At the command line enter:
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
> ant jetty.run
....
@@ -111,7 +111,7 @@ ports and connectors:::
To configure the port that Jetty starts on you need to define a connector.
First you need to configure a `` for the Connector class and then define the connector in the Jetty tags:
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -146,7 +146,7 @@ login services:::
If your web application requires authentication and authorization services, you can configure these on the Jetty container.
Here's an example of how to set up an link:{JDURL}/org/eclipse/jetty/security/HashLoginService.html[org.eclipse.jetty.security.HashLoginService]:
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -174,7 +174,7 @@ request log:::
The `requestLog` option allows you to specify a request logger for the Jetty instance.
You can either use the link:{JDURL}/org/eclipse/jetty/server/NCSARequestLog.html[org.eclipse.jetty.server.NCSARequestLog] class, or supply the name of your custom class:
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -195,7 +195,7 @@ request log:::
temporary directory:::
You can configure a directory as a temporary file store for uses such as expanding files and compiling JSPs by supplying the `tempDirectory` option:
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -218,7 +218,7 @@ other context handlers:::
You can specify these other context handlers using the `` element.
You need to supply a `` for it before you can use it:
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -247,7 +247,7 @@ system properties:::
As a convenience, you can configure system properties by using the `` element.
Be aware that, depending on the purpose of the system property, setting it from within the Ant execution may mean that it is evaluated too late, as the JVM evaluates some system properties on entry.
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -271,7 +271,7 @@ system properties:::
jetty XML file:::
If you have a lot of configuration to apply to the Jetty container, it can be more convenient to put it into a standard Jetty XML configuration file and have the Ant plugin apply it before starting Jetty:
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -295,7 +295,7 @@ scanning for changes:::
The `scanIntervalSeconds` option controls how frequently the `` task scans your web application/WAR file for changes.
The default value of `0` disables scanning. Here's an example where Jetty checks for changes every five seconds:
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -321,7 +321,7 @@ stopping:::
The `` task sends this stop message.
You can also optionally provide a `stopWait` value (in seconds), which is the length of time the `` task waits for confirmation that the stop succeeded:
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -346,7 +346,7 @@ stopping:::
+
To stop jetty via Ant, enter:
+
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
> ant jetty.stop
....
@@ -359,7 +359,7 @@ execution without pausing ant:::
This defaults to `false`. For `true`, Ant continues to execute after starting Jetty.
If Ant exits, so does Jetty. Understand that this option does _not_ fork a new process for Jetty.
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -383,7 +383,7 @@ execution without pausing ant:::
Add a `` for the `org.eclipse.jetty.ant.AntWebAppContext` class with name __webApp__, then add a `` element to `` to describe your web application.
The following example deploys a web application that is expanded in the local directory `foo/` to context path ` / `:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -410,7 +410,7 @@ deploying a WAR file:::
It is not necessary to expand the web application into a directory.
It is fine to deploy it as a WAR file:
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -436,7 +436,7 @@ deploying a WAR file:::
deploying more than one web application:::
You can also deploy more than one web application:
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -471,7 +471,7 @@ class, you can configure it by adding attributes of the same name
Here's an example that specifies the location of the `web.xml` file (equivalent to method link:{JDURL}/org/eclipse/jetty/webapp/WebAppContext.html#setDescriptor%28java.lang.String%29[`AntWebAppContext.setDescriptor()`]) and the web application's temporary directory (equivalent to method link:{JDURL}/org/eclipse/jetty/webapp/WebAppContext.html#setTempDirectory%28java.io.File%29[`AntWebAppContext.setTempDirectory()`]):
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -499,7 +499,7 @@ Other extra configuration options for the AntWebAppContext include:
extra classes and Jars:::
If your web application's classes and Jars do not reside inside `WEB-INF` of the resource base directory, you can use the and elements to tell Ant where to find them. Here's an example:
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -536,7 +536,7 @@ context attributes:::
For convenience, the Ant plugin permits you to configure these directly in the build file.
Here's an example:
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -565,7 +565,7 @@ context attributes:::
`jetty-env.xml` file:::
If you are using features such as link:#configuring_jndi[JNDI] with your web application, you may need to configure a link:#using_jndi[`WEB-INF/jetty-env.xml`] file to define resources. If the structure of your web application project is such that the source of `jetty-env.xml` file resides somewhere other than `WEB-INF`, you can use the `jettyEnvXml` attribute to tell Ant where to find it:
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -594,7 +594,7 @@ context XML file:::
In this case, you can use a standard context XML configuration file which the Ant plugin applies to your web application before it is deployed.
Be aware that the settings from the context XML file _override_ those of the attributes and nested elements you defined in the build file.
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
project name="Jetty-Ant integration test" basedir=".">
diff --git a/jetty-documentation/src/main/asciidoc/development/clients/http/http-client-api.adoc b/jetty-documentation/src/main/asciidoc/development/clients/http/http-client-api.adoc
index 0eb6a4c15f5..6435e7e7336 100644
--- a/jetty-documentation/src/main/asciidoc/development/clients/http/http-client-api.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/clients/http/http-client-api.adoc
@@ -22,7 +22,7 @@
The simpler way to perform a HTTP request is the following:
-[source,java]
+[source, java, subs="{sub-order}"]
----
ContentResponse response = httpClient.GET("http://domain.com/path?query");
@@ -36,7 +36,7 @@ The content length is limited by default to 2 MiB; for larger content see xref:h
If you want to customize the request, for example by issuing a HEAD request instead of a GET, and simulating a browser user agent, you can do it in this way:
-[source,java]
+[source, java, subs="{sub-order}"]
----
ContentResponse response = httpClient.newRequest("http://domain.com/path?query")
.method(HttpMethod.HEAD)
@@ -48,7 +48,7 @@ ContentResponse response = httpClient.newRequest("http://domain.com/path?query")
This is a shorthand for:
-[source,java]
+[source, java, subs="{sub-order}"]
----
Request request = httpClient.newRequest("http://domain.com/path?query");
@@ -64,7 +64,7 @@ When the request object is customized, you call `Request.send()` that produces t
Simple POST requests also have a shortcut method:
-[source,java]
+[source, java, subs="{sub-order}"]
----
ContentResponse response = httpClient.POST("http://domain.com/entity/1")
@@ -81,7 +81,7 @@ Following redirects is a feature that you can enable/disable on a per-request ba
File uploads also require one line, and make use of JDK 7′s `java.nio.file` classes:
-[source,java]
+[source, java, subs="{sub-order}"]
----
ContentResponse response = httpClient.newRequest("http://domain.com/upload")
@@ -93,7 +93,7 @@ ContentResponse response = httpClient.newRequest("http://domain.com/upload")
It is possible to impose a total timeout for the request/response conversation using the `Request.timeout(...)` method, in this way:
-[source,java]
+[source, java, subs="{sub-order}"]
----
ContentResponse response = httpClient.newRequest("http://domain.com/path?query")
@@ -135,7 +135,7 @@ When the request and the response are both fully processed, the thread that fini
A simple asynchronous GET request that discards the response content can be written in this way:
-[source,java]
+[source, java, subs="{sub-order}"]
----
httpClient.newRequest("http://domain.com/path")
@@ -155,7 +155,7 @@ Method `Request.send(Response.CompleteListener)` returns void and does not block
You can write the same code using JDK 8′s lambda expressions:
-[source,java]
+[source, java, subs="{sub-order}"]
----
httpClient.newRequest("http://domain.com/path")
@@ -166,7 +166,7 @@ httpClient.newRequest("http://domain.com/path")
You can impose a total timeout for the request/response conversation in the same way used by the synchronous API:
-[source,java]
+[source, java, subs="{sub-order}"]
----
Request request = httpClient.newRequest("http://domain.com/path")
@@ -187,7 +187,7 @@ The example above will impose a total timeout of 3 seconds on the request/respon
The HTTP client APIs use listeners extensively to provide hooks for all possible request and response events, and with JDK 8′s lambda expressions they’re even more fun to use:
-[source,java]
+[source, java, subs="{sub-order}"]
----
httpClient.newRequest("http://domain.com/path")
@@ -222,7 +222,7 @@ Jetty HTTP client provides a number of utility classes off the shelf to handle r
You can provide request content as `String`, `byte[]`, `ByteBuffer`, `java.nio.file.Path`, `InputStream`, and provide your own implementation of `org.eclipse.jetty.client.api.ContentProvider`.
Here’s an example that provides the request content using `java.nio.file.Paths`:
-[source,java]
+[source, java, subs="{sub-order}"]
----
ContentResponse response = httpClient.newRequest("http://domain.com/upload")
@@ -234,7 +234,7 @@ ContentResponse response = httpClient.newRequest("http://domain.com/upload")
This is equivalent to using the `PathContentProvider` utility class:
-[source,java]
+[source, java, subs="{sub-order}"]
----
ContentResponse response = httpClient.newRequest("http://domain.com/upload")
@@ -246,7 +246,7 @@ ContentResponse response = httpClient.newRequest("http://domain.com/upload")
Alternatively, you can use `FileInputStream` via the `InputStreamContentProvider` utility class:
-[source,java]
+[source, java, subs="{sub-order}"]
----
ContentResponse response = httpClient.newRequest("http://domain.com/upload")
@@ -260,7 +260,7 @@ Since `InputStream` is blocking, then also the send of the request will block if
If you have already read the content in memory, you can pass it as a `byte[]` using the `BytesContentProvider` utility class:
-[source,java]
+[source, java, subs="{sub-order}"]
----
byte[] bytes = ...;
@@ -273,7 +273,7 @@ ContentResponse response = httpClient.newRequest("http://domain.com/upload")
If the request content is not immediately available, but your application will be notified of the content to send, you can use `DeferredContentProvider` in this way:
-[source,java]
+[source, java, subs="{sub-order}"]
----
DeferredContentProvider content = new DeferredContentProvider();
@@ -309,7 +309,7 @@ This allows fine-grained control of the request/response conversation: for examp
Another way to provide request content is by using an `OutputStreamContentProvider`, which allows applications to write request content when it is available to the `OutputStream` provided by `OutputStreamContentProvider`:
-[source,java]
+[source, java, subs="{sub-order}"]
----
OutputStreamContentProvider content = new OutputStreamContentProvider();
@@ -347,7 +347,7 @@ The first way is to buffer the response content in memory; this is done when usi
If you want to control the length of the response content (for example limiting to values smaller than the default of 2 MiB), then you can use a `org.eclipse.jetty.client.util.FutureResponseListener`in this way:
-[source,java]
+[source, java, subs="{sub-order}"]
----
Request request = httpClient.newRequest("http://domain.com/path");
@@ -366,7 +366,7 @@ If the response content length is exceeded, the response will be aborted, and an
If you are using the asynchronous APIs (see xref:http-client-async[]), you can use the `BufferingResponseListener` utility class:
-[source,java]
+[source, java, subs="{sub-order}"]
----
httpClient.newRequest("http://domain.com/path")
@@ -389,7 +389,7 @@ httpClient.newRequest("http://domain.com/path")
The second way is the most efficient (because it avoids content copies) and allows you to specify a `Response.ContentListener`, or a subclass, to handle the content as soon as it arrives:
-[source,java]
+[source, java, subs="{sub-order}"]
----
ContentResponse response = httpClient
@@ -408,7 +408,7 @@ ContentResponse response = httpClient
The third way allows you to wait for the response and then stream the content using the `InputStreamResponseListener` utility class:
-[source,java]
+[source, java, subs="{sub-order}"]
----
InputStreamResponseListener listener = new InputStreamResponseListener();
diff --git a/jetty-documentation/src/main/asciidoc/development/clients/http/http-client-intro.adoc b/jetty-documentation/src/main/asciidoc/development/clients/http/http-client-intro.adoc
index 97d8583def0..c50fab80123 100644
--- a/jetty-documentation/src/main/asciidoc/development/clients/http/http-client-intro.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/clients/http/http-client-intro.adoc
@@ -42,7 +42,7 @@ Like a browser, it can make requests to different domains, it manages redirects,
In order to use `HttpClient`, you must instantiate it, configure it, and then start it:
-[source,java]
+[source, java, subs="{sub-order}"]
----
// Instantiate HttpClient
@@ -64,7 +64,7 @@ When you create a `HttpClient` instance using the parameterless constructor, you
In order to perform HTTPS requests, you should create first a link:{JDURL}/org/eclipse/jetty/util/ssl/SslContextFactory.html[`SslContextFactory`], configure it, and pass it to `HttpClient`'s constructor.
When created with a `SslContextFactory`, the `HttpClient` will be able to perform both HTTP and HTTPS requests to any domain.
-[source,java]
+[source, java, subs="{sub-order}"]
----
// Instantiate and configure the SslContextFactory
diff --git a/jetty-documentation/src/main/asciidoc/development/clients/http/http-client-other.adoc b/jetty-documentation/src/main/asciidoc/development/clients/http/http-client-other.adoc
index f2007c0063c..91b9f3d9666 100644
--- a/jetty-documentation/src/main/asciidoc/development/clients/http/http-client-other.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/clients/http/http-client-other.adoc
@@ -26,7 +26,7 @@ When new requests are made, the cookie store is consulted and if there are match
Applications can programmatically access the cookie store to find the cookies that have been set:
-[source,java]
+[source, java, subs="{sub-order}"]
----
CookieStore cookieStore = httpClient.getCookieStore();
@@ -37,7 +37,7 @@ List cookies = cookieStore.get(URI.create("http://domain.com/path"))
Applications can also programmatically set cookies as if they were returned from a HTTP response:
-[source,java]
+[source, java, subs="{sub-order}"]
----
CookieStore cookieStore = httpClient.getCookieStore();
@@ -52,7 +52,7 @@ cookieStore.add(URI.create("http://domain.com"), cookie);
You can remove cookies that you do not want to be sent in future HTTP requests:
-[source,java]
+[source, java, subs="{sub-order}"]
----
CookieStore cookieStore = httpClient.getCookieStore();
@@ -66,7 +66,7 @@ for (HttpCookie cookie : cookies)
If you want to totally disable cookie handling, you can install a `HttpCookieStore.Empty` instance in this way:
-[source,java]
+[source, java, subs="{sub-order}"]
----
httpClient.setCookieStore(new HttpCookieStore.Empty());
@@ -76,7 +76,7 @@ httpClient.setCookieStore(new HttpCookieStore.Empty());
You can enable cookie filtering by installing a cookie store that performs the filtering logic in this way:
-[source,java]
+[source, java, subs="{sub-order}"]
----
httpClient.setCookieStore(new GoogleOnlyCookieStore());
@@ -103,7 +103,7 @@ Jetty HTTP client supports the "Basic" and "Digest" authentication mechanisms de
You can configure authentication credentials in the HTTP client instance as follows:
-[source,java]
+[source, java, subs="{sub-order}"]
----
URI uri = new URI("http://domain.com/secure");
@@ -128,7 +128,7 @@ If the authentication is successful, it caches the result and reuses it for subs
Successful authentications are cached, but it is possible to clear them in order to force authentication again:
-[source,java]
+[source, java, subs="{sub-order}"]
----
httpClient.getAuthenticationStore().clearAuthenticationResults();
@@ -146,7 +146,7 @@ Other implementations may be written by subclassing `ProxyConfiguration.Proxy`.
A typical configuration is the following:
-[source,java]
+[source, java, subs="{sub-order}"]
----
ProxyConfiguration proxyConfig = httpClient.getProxyConfiguration();
diff --git a/jetty-documentation/src/main/asciidoc/development/continuations/continuations-patterns.adoc b/jetty-documentation/src/main/asciidoc/development/continuations/continuations-patterns.adoc
index 5b11049281e..ac4dc06bb69 100644
--- a/jetty-documentation/src/main/asciidoc/development/continuations/continuations-patterns.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/continuations/continuations-patterns.adoc
@@ -22,7 +22,7 @@
The suspend/resume style is used when a servlet and/or filter is used to generate the response after an asynchronous wait that is terminated by an asynchronous handler.
Typically a request attribute is used to pass results and to indicate if the request has already been suspended.
-[source,java]
+[source, java, subs="{sub-order}"]
----
void doGet(HttpServletRequest request, HttpServletResponse response)
{
@@ -67,7 +67,7 @@ This style is very good when the response needs the facilities of the servlet co
The suspend/complete style is used when an asynchronous handler is used to generate the response:
-[source,java]
+[source, java, subs="{sub-order}"]
----
void doGet(HttpServletRequest request, HttpServletResponse response)
{
diff --git a/jetty-documentation/src/main/asciidoc/development/continuations/continuations-using.adoc b/jetty-documentation/src/main/asciidoc/development/continuations/continuations-using.adoc
index c630f575817..a2fd3713e63 100644
--- a/jetty-documentation/src/main/asciidoc/development/continuations/continuations-using.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/continuations/continuations-using.adoc
@@ -31,7 +31,7 @@ The link:{JDURL}/org/eclipse/jetty/continuation/ContinuationSupport.html[Continu
To suspend a request, the suspend method can be called on the continuation:
-[source,java]
+[source, java, subs="{sub-order}"]
----
void doGet(HttpServletRequest request, HttpServletResponse response)
{
@@ -60,7 +60,7 @@ If an exception is desirable (to bypass code that is unaware of continuations an
Once an asynchronous event has occurred, the continuation can be resumed:
-[source,java]
+[source, java, subs="{sub-order}"]
----
void myAsyncCallback(Object results)
{
@@ -78,7 +78,7 @@ Continuation resume is analogous to Servlet 3.0 `AsyncContext.dispatch()`.
As an alternative to resuming a request, an asynchronous handler may write the response itself. After writing the response, the handler must indicate the request handling is complete by calling the complete method:
-[source,java]
+[source, java, subs="{sub-order}"]
----
void myAsyncCallback(Object results)
{
@@ -93,7 +93,7 @@ After complete is called, the container schedules the response to be committed
An application may monitor the status of a continuation by using a ContinuationListener:
-[source,java]
+[source, java, subs="{sub-order}"]
----
void doGet(HttpServletRequest request, HttpServletResponse response)
{
diff --git a/jetty-documentation/src/main/asciidoc/development/debugging/enable-remote-debugging.adoc b/jetty-documentation/src/main/asciidoc/development/debugging/enable-remote-debugging.adoc
index 23a59363b9e..0812d475ec9 100644
--- a/jetty-documentation/src/main/asciidoc/development/debugging/enable-remote-debugging.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/debugging/enable-remote-debugging.adoc
@@ -36,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ java -Xdebug -agentlib:jdwp=transport=dt_socket,address=9999,server=y,suspend=n -jar start.jar
@@ -50,7 +50,7 @@ Via `start.ini`::
1. Edit the `start.ini` and uncomment the --exec line, this is required if you are adding jvm options to the start.ini file as jetty-start must generate the classpath required and fork a new jvm.
2. Add the parameters mentioned above in the Command Line option so your start.ini looks like this:
+
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
#===========================================================
# Configure JVM arguments.
@@ -84,7 +84,7 @@ Uncomment any other jvm environmental options you so desire for your debugging s
3. Regardless of the option chosen, you should see the following lines at the top of your jetty-distribution startup.
+
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
Listening for transport dt_socket at address: 9999
diff --git a/jetty-documentation/src/main/asciidoc/development/embedding/embedded-examples.adoc b/jetty-documentation/src/main/asciidoc/development/embedding/embedded-examples.adoc
index b0ebb13c192..c106a0ed3f3 100644
--- a/jetty-documentation/src/main/asciidoc/development/embedding/embedded-examples.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/embedding/embedded-examples.adoc
@@ -40,7 +40,7 @@ This example is very similar to the one in the previous section, although it ena
As of jetty-9.2, we use the JSP engine from Apache, which relies on a Servlet Specification 3.1 style ServletContainerInitializer to initialize itself.
To get this to work with Jetty, you need to enable annotations processing, as shown in this example code:
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/OneWebAppWithJsp.java[]
@@ -54,7 +54,7 @@ After you have started things up you should be able to navigate to http://localh
To use this example in your project, you will need the following maven dependencies declared, in addition to those from the previous section:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/development/embedding/embedding-jetty.adoc b/jetty-documentation/src/main/asciidoc/development/embedding/embedding-jetty.adoc
index db4d465993e..61d093b7b06 100644
--- a/jetty-documentation/src/main/asciidoc/development/embedding/embedding-jetty.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/embedding/embedding-jetty.adoc
@@ -78,7 +78,7 @@ The handler sets the response status, content-type, and marks the request as han
To allow a Handler to handle HTTP requests, you must add it to a Server instance.
The following code from OneHandler.java shows how a Jetty server can use the HelloWorld handler:
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/OneHandler.java[]
----
@@ -130,7 +130,7 @@ Thus when the ContextHandler handles the request, it does so within the scope th
The link:{JXURL}/org/eclipse/jetty/embedded/FileServer.html[FileServer example] shows how you can use a ResourceHandler to serve static content from the current working directory:
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/FileServer.java[]
----
@@ -147,7 +147,7 @@ However, often when embedding Jetty it is desirable to explicity instantiate and
The following example, link:{JXURL}/org/eclipse/jetty/embedded/OneConnector.html[OneConnector.java],
instantiates, configures, and adds a single HTTP connector instance to the server:
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/OneConnector.java[]
----
@@ -171,7 +171,7 @@ It uses standard path mappings to match a Servlet to a request; sets the request
The link:{JXURL}/org/eclipse/jetty/embedded/MinimalServlets.html[MinimalServlets example] creates a ServletHandler instance and configures a single HelloServlet:
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/MinimalServlets.java[]
----
@@ -189,7 +189,7 @@ Requests that match the context path have their path methods updated accordingly
The following link:{JXURL}/org/eclipse/jetty/embedded/OneContext.html[OneContext example] shows a context being established that wraps the link:{JXURL}/org/eclipse/jetty/embedded/HelloHandler.html[HelloHandler]:
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/OneContext.java[]
----
@@ -197,7 +197,7 @@ include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/One
When many contexts are present, you can embed a ContextHandlerCollection to efficiently examine a request URI to then select the matching ContextHandler(s) for the request.
The link:{JXURL}/org/eclipse/jetty/embedded/ManyContexts.html[ManyContexts example] shows how many such contexts you can configure:
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/ManyContexts.java[]
----
@@ -207,7 +207,7 @@ include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/Man
A link:{JXURL}/org/eclipse/jetty/servlet/ServletContextHandler.html[ServletContextHandler] is a specialization of ContextHandler with support for standard sessions and Servlets.
The following link:{JXURL}/org/eclipse/jetty/embedded/OneServletContext.html[OneServletContext example] instantiates a link:{JXURL}/org/eclipse/jetty/servlet/DefaultServlet.html[DefaultServlet] to server static content from /tmp/ and a `DumpServlet` that creates a session and dumps basic details about the request:
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/OneServletContext.java[]
----
@@ -218,7 +218,7 @@ A link:{JXURL}/org/eclipse/jetty/webapp/WebAppContext.html[WebAppContext] is an
The following link:{JXURL}/org/eclipse/jetty/embedded/OneWebApp.html[OneWebApp example] configures the Jetty test webapp.
Web applications can use resources the container provides, and in this case a LoginService is needed and also configured:
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/OneWebApp.java[]
----
@@ -239,7 +239,7 @@ The link:{JXURL}/org/eclipse/jetty/embedded/LikeJettyXml.html[LikeJettyXml examp
* link:{GITBROWSEURL}/jetty-server/src/main/config/etc/jetty-lowresources.xml[jetty-lowresources.xml]
* link:{GITBROWSEURL}/tests/test-webapps/test-jetty-webapp/src/main/config/etc/test-realm.xml[test-realm.xml]
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/LikeJettyXml.java[]
----
diff --git a/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-file-server.adoc b/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-file-server.adoc
index 46a132fa592..8cab6587a46 100644
--- a/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-file-server.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-file-server.adoc
@@ -22,7 +22,7 @@ It is perfectly suitable for test cases where you need an actual web server to o
Note that this does not have any logic for caching of files, either within the server or setting the appropriate headers on the response.
It is simply a few lines that illustrate how easy it is to serve out some files.
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/FileServer.java[]
@@ -36,7 +36,7 @@ After you have started things up you should be able to navigate to http://localh
To use this example in your project you will need the following maven dependencies declared.
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
diff --git a/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-many-connectors.adoc b/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-many-connectors.adoc
index 198697db563..167ad4adb67 100644
--- a/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-many-connectors.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-many-connectors.adoc
@@ -20,7 +20,7 @@
This example shows how to configure Jetty to use multiple connectors, specifically so it can process both http and https requests.
Since the meat of this example is the server and connector configuration it only uses a simple HelloHandler but this example should be easily merged with other examples like those deploying servlets or webapps.
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/ManyConnectors.java[]
@@ -36,7 +36,7 @@ See http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Thread.html#join()[Th
To use this example in your project you will need the following maven dependencies declared.
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-minimal-servlet.adoc b/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-minimal-servlet.adoc
index 02fa02eb8bf..c709bf7babd 100644
--- a/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-minimal-servlet.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-minimal-servlet.adoc
@@ -22,7 +22,7 @@ Note that this is strictly a servlet, not a servlet in the context of a web appl
This is purely just a servlet deployed and mounted on a context and able to process requests.
This example is excellent for situations where you have a simple servlet that you need to unit test, just mount it on a context and issue requests using your favorite http client library (like our Jetty client found in xref:http-client[]).
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/MinimalServlets.java[]
@@ -41,7 +41,7 @@ After you have started things up you should be able to navigate to http://localh
To use this example in your project you will need the following maven dependencies declared.
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-one-webapp.adoc b/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-one-webapp.adoc
index dddf2874447..6b17070a34a 100644
--- a/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-one-webapp.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-one-webapp.adoc
@@ -21,7 +21,7 @@ This example shows how to deploy a simple webapp with an embedded instance of je
This is useful when you want to manage the lifecycle of a server programmatically, either within a production application or as a simple way to deploying and debugging a full scale application deployment.
In many ways it is easier then traditional deployment since you control the classpath yourself, making this easy to wire up in a test case in maven and issue requests using your favorite http client library (like our Jetty client found in xref:http-client[]).
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/OneWebApp.java[]
@@ -35,7 +35,7 @@ After you have started things up you should be able to navigate to http://localh
To use this example in your project you will need the following maven dependencies declared.
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-secured-hello-handler.adoc b/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-secured-hello-handler.adoc
index 9c660873184..131d0eea188 100644
--- a/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-secured-hello-handler.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-secured-hello-handler.adoc
@@ -22,7 +22,7 @@ We have a simple Hello Handler that just return a greeting but add on the restri
Another thing to remember is that this example uses the ConstraintSecurityHandler which is what supports the security mappings inside of the servlet api, it could be easier to show just the SecurityHandler usage, but the constraint provides more configuration power.
If you don't need that you can drop the Constraint bits and use just the SecurityHandler.
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/SecuredHelloHandler.java[]
@@ -44,7 +44,7 @@ include::{SRCDIR}/examples/embedded/src/test/resources/realm.properties[]
To use this example in your project you will need the following maven dependencies declared.
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-split-file-server.adoc b/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-split-file-server.adoc
index 9a31d71732d..d046bbaae24 100644
--- a/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-split-file-server.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/embedding/examples/embedded-split-file-server.adoc
@@ -19,7 +19,7 @@
This example builds on the link:#emebedded-file-server[Simple File Server] to show how chaining multiple ResourceHandlers together can let you aggregate mulitple directories to serve content on a single path and how you can link these together with ContextHandlers.
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/SplitFileServer.java[]
@@ -36,7 +36,7 @@ Any requests for files will be looked for in the first resource handler, then th
To use this example as is in your project you will need the following maven dependencies declared.
We would recommend not using the toolchain dependency in your actual application.
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/development/embedding/jetty-helloworld.adoc b/jetty-documentation/src/main/asciidoc/development/embedding/jetty-helloworld.adoc
index 8c3088e7978..e9ee5d75cee 100644
--- a/jetty-documentation/src/main/asciidoc/development/embedding/jetty-helloworld.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/embedding/jetty-helloworld.adoc
@@ -24,7 +24,7 @@ This section provides a tutorial that shows how you can quickly develop embedded
Jetty is decomposed into many jars and dependencies to achieve a minimal footprint by selecting the minimal set of jars.
Typically it is best to use something like Maven to manage jars, however this tutorial uses an aggregate Jar that contains all of the Jetty classes in one Jar.
-You can manually download the aggregate http://central.maven.org/maven2/org/eclipse/jetty/aggregate/jetty-all/@project.version@/jetty-all-@project.version@-uber.jar[`jetty-all.jar`] using `curl`) or a browser.
+You can manually download the aggregate http://central.maven.org/maven2/org/eclipse/jetty/aggregate/jetty-all/{VERSION}/jetty-all-{VERSION}-uber.jar[`jetty-all.jar`] using `curl`) or a browser.
____
[NOTE]
@@ -34,11 +34,11 @@ ____
Use curl as follows:
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
> mkdir Demo
> cd Demo
-> curl -o jetty-all-uber.jar http://central.maven.org/maven2/org/eclipse/jetty/aggregate/jetty-all/@project.version@/jetty-all-@project.version@-uber.jar
+> curl -o jetty-all-uber.jar http://central.maven.org/maven2/org/eclipse/jetty/aggregate/jetty-all/{VERSION}/jetty-all-{VERSION}-uber.jar
....
[[writing-helloworld-example]]
@@ -48,7 +48,7 @@ The link:#embedding[Embedding Jetty] section contains many examples of writing a
This tutorial uses a simple HelloWorld handler with a main method to run the server.
You can either link:{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/HelloWorld.java[download] or create in an editor the file `HelloWorld.java` with the following content:
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/HelloWorld.java[]
----
@@ -58,7 +58,7 @@ include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/Hel
The following command compiles the HelloWorld class:
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
> mkdir classes
> javac -d classes -cp jetty-all-uber.jar HelloWorld.java
@@ -69,7 +69,7 @@ The following command compiles the HelloWorld class:
The following command runs the HelloWorld example:
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
> java -cp classes:jetty-all-uber.jar org.eclipse.jetty.embedded.HelloWorld
....
diff --git a/jetty-documentation/src/main/asciidoc/development/frameworks/metro.adoc b/jetty-documentation/src/main/asciidoc/development/frameworks/metro.adoc
index c1711a0d641..22f5ad11ff9 100644
--- a/jetty-documentation/src/main/asciidoc/development/frameworks/metro.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/frameworks/metro.adoc
@@ -29,7 +29,7 @@ We'll refer to the unpacked location as `$metro.home`.
3. Copy the jars from $metro.home/lib to `$jetty.home/lib/metro`
4. Edit the start.ini file and add an OPTION line for metro near the end.
+
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
OPTIONS=metro
----
@@ -41,12 +41,12 @@ 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]
+[source, screen, subs="{sub-order}"]
....
[2093] java -jar start.jar
2013-07-26 15:47:53.480:INFO:oejs.Server:main: jetty-9.0.4.v20130625
-2013-07-26 15:47:53.549:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/home/user/jetty-distribution-@project.version@/webapps/] at interval 1
+2013-07-26 15:47:53.549:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/home/user/jetty-distribution-{VERSION}/webapps/] at interval 1
Jul 26, 2013 3:47:53 PM com.sun.xml.ws.transport.http.servlet.WSServletContextListener contextInitialized
INFO: WSSERVLET12: JAX-WS context listener initializing
Jul 26, 2013 3:47:56 PM com.sun.xml.ws.server.MonitorBase createRoot
diff --git a/jetty-documentation/src/main/asciidoc/development/frameworks/osgi.adoc b/jetty-documentation/src/main/asciidoc/development/frameworks/osgi.adoc
index 54c77b8b08f..3c57ca7fde8 100644
--- a/jetty-documentation/src/main/asciidoc/development/frameworks/osgi.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/frameworks/osgi.adoc
@@ -98,7 +98,7 @@ jetty.home::
`etc/` directory containing xml files to configure the Jetty container
on startup. For example:
+
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
jetty.home=/opt/custom/jetty
@@ -106,7 +106,7 @@ jetty.home=/opt/custom/jetty
+
Where `/opt/custom/jetty` contains:
+
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
etc/jetty.xml
@@ -126,7 +126,7 @@ jetty.home.bundle::
jettyhome/` directory with a default set of xml
configuration files. Here's how you would specify it:
+
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
jetty.home.bundle=org.eclipse.jetty.osgi.boot
----
@@ -134,7 +134,7 @@ jetty.home.bundle=org.eclipse.jetty.osgi.boot
Here's a partial listing of that jar that shows you the names of the
xml files contained within it:
+
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
META-INF/MANIFEST.MF
jettyhome/etc/jetty.xml
@@ -145,7 +145,7 @@ jetty.etc.config.urls::
This specifies the paths of the xml files that are to be used. If not
specified, they default to:
+
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
etc/jetty.xml,etc/jetty-http.xml,etc/jetty-deployer.xml
----
@@ -178,7 +178,7 @@ applied to it, and then published as an OSGi service. Normally, you will
not need to interact with this service instance, however you can
retrieve a reference to it using the usual OSGi API:
-[source,java]
+[source, java, subs="{sub-order}"]
----
org.osgi.framework.BundleContext bc;
@@ -217,7 +217,7 @@ Here's an example of how to create a new Server instance and register it
with OSGi so that the jetty-osgi-boot code will find it and configure it
so it can be a deployment target:
-[source,java]
+[source, java, subs="{sub-order}"]
----
public class Activator implements BundleActivator
{
@@ -246,7 +246,7 @@ webapps and ContextHandlers as Bundles or Services to it (see below for
more information on this). Here's an example of deploying a webapp as a
Service and targetting it to the "fooServer" Server we created above:
-[source,java]
+[source, java, subs="{sub-order}"]
----
public class Activator implements BundleActivator
{
@@ -286,7 +286,7 @@ jetty-9.3) or Jetty-WarResourcePath::
+
`MANIFEST`:
+
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
Bundle-Name: Web
@@ -300,7 +300,7 @@ Bundle-SymbolicName: com.acme.sample.web
+
Bundle contents:
+
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
META-INF/MANIFEST.MF
@@ -323,7 +323,7 @@ Bundle MANIFEST contains Web-ContextPath::
+
`MANIFEST`:
+
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
Bundle-Name: Web
@@ -389,14 +389,14 @@ any file extensions.
For example, suppose we have a bundle whose location is:
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
file://some/where/over/the/rainbow/oz.war
----
The corresponding synthesized context path would be:
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
/oz
----
@@ -409,7 +409,7 @@ file that is applied to the webapp. This xml file must be placed in
Here's an example of a webapp bundle listing containing such a file:
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
META-INF/MANIFEST.MF
@@ -469,28 +469,28 @@ Bundle MANIFEST contains Jetty-ContextFilePath::
+
A context file that is inside the bundle:
+
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
Jetty-ContextFilePath: ./a/b/c/d/foo.xml
----
+
A context file that is on the file system:
+
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
Jetty-ContextFilePath: /opt/app/contexts/foo.xml
----
+
A context file that is relative to jetty.home:
+
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
Jetty-ContextFilePath: contexts/foo.xml
----
+
A number of different context files:
+
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
Jetty-ContextFilePath: ./a/b/c/d/foo.xml,/opt/app/contexts/foo.xml,contexts/foo.xml
----
@@ -529,7 +529,7 @@ bundle.root::
Here's an example of a context xml file that makes use of these
properties:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
include::{SRCDIR}/jetty-osgi/test-jetty-osgi-context/src/main/context/acme.xml[]
----
@@ -550,7 +550,7 @@ WebAppContext:
The bundle contents:
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
META-INF/MANIFEST.MF
@@ -562,7 +562,7 @@ com/acme/osgi/Activator.class
The `MANIFEST.MF`:
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
Bundle-Classpath: .
@@ -585,7 +585,7 @@ Bundle-SymbolicName: com.acme.testwebapp
The Activator code:
-[source,java]
+[source, java, subs="{sub-order}"]
----
public void start(BundleContext context) throws Exception
@@ -659,7 +659,7 @@ apply upon deployment:
The bundle contents:
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
META-INF/MANIFEST.MF
@@ -673,7 +673,7 @@ com/acme/osgi/Activator$1.class
The `MANIFEST`:
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
Bundle-Classpath: .
@@ -697,7 +697,7 @@ Bundle-SymbolicName: com.acme.testcontext
The Activator code:
-[source,java]
+[source, java, subs="{sub-order}"]
----
public void start(final BundleContext context) throws Exception
@@ -729,7 +729,7 @@ public void start(final BundleContext context) throws Exception
The contents of the `acme.xml` context file:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
include::{SRCDIR}/jetty-osgi/test-jetty-osgi-context/src/main/context/acme.xml[]
----
@@ -939,7 +939,7 @@ Firstly, lets look at an example of a web bundle's modified MANIFEST
file so you get an idea of what is required. This example is a web
bundle that uses the Spring servlet framework:
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
Bundle-SymbolicName: com.acme.sample
@@ -982,7 +982,7 @@ org.eclipse.jetty.osgi.tldbundles::
will be treated as if they are on the container's classpath for web
bundles. For example:
+
-[source,plain]
+[source, plain, subs="{sub-order}"]
----
org.eclipse.jetty.osgi.tldbundles=com.acme.special.tags,com.foo.web,org.bar.web.framework
----
@@ -1012,7 +1012,7 @@ org.eclipse.jetty.server.webapp.containerIncludeBundlePattern::
jetty-deploy.xml file would look if we defined a pattern that matched
all bundle symbolic names ending in "tag" and "web":
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/development/frameworks/spring-usage.adoc b/jetty-documentation/src/main/asciidoc/development/frameworks/spring-usage.adoc
index 41007853145..9b0c57feb74 100644
--- a/jetty-documentation/src/main/asciidoc/development/frameworks/spring-usage.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/frameworks/spring-usage.adoc
@@ -26,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ java -jar start.jar --add-to-startd=spring
....
@@ -40,7 +40,7 @@ You will need to download these and place them into jetty's classpath - you can
Configuring Jetty via Spring is simply a matter of calling the API as Spring beans.
The following is an example mimicking the default jetty startup configuration.
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/development/frameworks/weld.adoc b/jetty-documentation/src/main/asciidoc/development/frameworks/weld.adoc
index fe968e6a43b..c54d72415a0 100644
--- a/jetty-documentation/src/main/asciidoc/development/frameworks/weld.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/frameworks/weld.adoc
@@ -28,7 +28,7 @@ The easiest way to configure weld is within the jetty distribution itself:
1. Enable the startup link:#startup-modules[module] called "cdi".
2. Ensure your `WEB-INF/web.xml` contains the following:
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.jboss.weld.environment.servlet.Listener
@@ -43,7 +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]
+[source, screen, subs="{sub-order}"]
....
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
diff --git a/jetty-documentation/src/main/asciidoc/development/handlers/writing-custom-handlers.adoc b/jetty-documentation/src/main/asciidoc/development/handlers/writing-custom-handlers.adoc
index 7efc62805e3..f335768196b 100644
--- a/jetty-documentation/src/main/asciidoc/development/handlers/writing-custom-handlers.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/handlers/writing-custom-handlers.adoc
@@ -33,7 +33,7 @@ Classes that implement this interface are used to coordinate requests, filter re
The core API of the Handler interface is:
-[source,java]
+[source, java, subs="{sub-order}"]
----
public void handle(String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException
@@ -65,7 +65,7 @@ More often than not, access to the Jetty implementations of these classes is req
However, as the request and response may be wrapped by handlers, filters and servlets, it is not possible to pass the implementation directly.
The following mantra retrieves the core implementation objects from under any wrappers:
-[source,java]
+[source, java, subs="{sub-order}"]
----
Request base_request = request instanceof Request ? (Request)request : HttpConnection.getCurrentConnection().getHttpChannel().getRequest();
Response base_response = response instanceof Response ? (Response)response : HttpConnection.getCurrentConnection().getHttpChannel().getResponse();
@@ -103,7 +103,7 @@ The link:{JDURL}/org/eclipse/jetty/embedded/OneHandler.html[OneHandler] embedded
You can use the normal servlet response API, which will typically set some status, content headers and then write out the content:
-[source,java]
+[source, java, subs="{sub-order}"]
----
response.setContentType("text/html");
response.setStatus(HttpServletResponse.SC_OK);
@@ -112,7 +112,7 @@ You can use the normal servlet response API, which will typically set some statu
It is also very important that a handler indicate that it has completed handling the request and that the request should not be passed to other handlers:
-[source,java]
+[source, java, subs="{sub-order}"]
----
Request base_request = (request instanceof Request) ? (Request)request:HttpConnection.getCurrentConnection().getHttpChannel().getRequest();
base_request.setHandled(true);
@@ -137,7 +137,7 @@ You can also update the context of the request:
Typically Jetty passes a modified request to another handler and undoes modifications in a finally block afterwards:
-[source,java]
+[source, java, subs="{sub-order}"]
----
try
{
diff --git a/jetty-documentation/src/main/asciidoc/development/maven/jetty-jspc-maven-plugin.adoc b/jetty-documentation/src/main/asciidoc/development/maven/jetty-jspc-maven-plugin.adoc
index 05f2ae78cca..b5d6601e687 100644
--- a/jetty-documentation/src/main/asciidoc/development/maven/jetty-jspc-maven-plugin.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/maven/jetty-jspc-maven-plugin.adoc
@@ -24,13 +24,13 @@ This plugin will help you pre-compile your jsps and works in conjunction with th
Here's the basic setup required to put the jspc plugin into your build:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
jetty-jspc-maven-plugin
- @project.version@
+ {VERSION}
jspc
@@ -118,7 +118,7 @@ jspc::
Taking all the default settings, here's how to configure the war plugin to use the generated web.xml that includes all of the jsp servlet declarations:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -139,7 +139,7 @@ As compiling jsps is usually done during preparation for a production release an
For example, the following profile will only be invoked if the flag `-Dprod` is present on the run line:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -153,7 +153,7 @@ For example, the following profile will only be invoked if the flag `-Dprod` is
org.eclipse.jetty
jetty-jspc-maven-plugin
- @project.version@
+ {VERSION}
@@ -171,7 +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 and s inserted in the web.xml and your webapp assembled into a war:
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
$ mvn -Dprod package
@@ -191,7 +191,7 @@ We will unpack the overlaid war file, compile the jsps and merge their servlet d
Here's an example configuration of the war plugin that separate those phases into an unpack phase, and then a packing phase:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -231,13 +231,13 @@ Now you also need to configure the jetty-jspc-maven-plugin so that it can use th
This is in target/foo/WEB-INF/web.xml.
Using the default settings, the web.xml merged with the jsp servlet definitions will be put into target/web.xml.
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
jetty-jspc-maven-plugin
- @project.version@
+ {VERSION}
jspc
diff --git a/jetty-documentation/src/main/asciidoc/development/maven/jetty-maven-helloworld.adoc b/jetty-documentation/src/main/asciidoc/development/maven/jetty-maven-helloworld.adoc
index 67a5f25a179..3066c373a56 100644
--- a/jetty-documentation/src/main/asciidoc/development/maven/jetty-maven-helloworld.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/maven/jetty-maven-helloworld.adoc
@@ -36,7 +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]
+[source, screen, subs="{sub-order}"]
....
> mkdir JettyMavenHelloWorld
> cd JettyMavenHelloWorld
@@ -48,7 +48,7 @@ You can use _link:#archetypes[http://maven.apache.org/guides/introduction/introd
Use an editor to create the file `src/main/java/org/example/HelloWorld.java` with the following contents:
-[source,java]
+[source, java, subs="{sub-order}"]
----
package org.example;
@@ -91,7 +91,7 @@ public class HelloWorld extends AbstractHandler
The `pom.xml` file declares the project name and its dependencies.
Use an editor to create the file `pom.xml` with the following contents:
-[source,java]
+[source, java, subs="{sub-order}"]
----
mvn clean compile exec:java
....
@@ -150,7 +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]
+[source, screen, subs="{sub-order}"]
....
> mvn dependency:tree
[INFO] Scanning for projects...
@@ -183,7 +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]
+[source, screen, subs="{sub-order}"]
....
> mkdir JettyMavenHelloWarApp
> cd JettyMavenHelloWebApp
@@ -196,7 +196,7 @@ First create the Maven structure (you can use the maven webapp archetype instead
Use an editor to create the file `src/main/java/org/example/HelloServlet.java` with the following contents:
-[source,java]
+[source, java, subs="{sub-order}"]
----
package org.example;
@@ -220,7 +220,7 @@ public class HelloServlet extends HttpServlet
You need to declare this servlet in the deployment descriptor, so edit the file `src/main/webapp/WEB-INF/web.xml` and add the following contents:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
Jetty HelloWorld WebApp
- @project.version@
+ {VERSION}
@@ -292,7 +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]
+[source, screen, subs="{sub-order}"]
....
> mvn jetty:run
....
@@ -307,7 +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]
+[source, screen, subs="{sub-order}"]
....
> mvn package
....
diff --git a/jetty-documentation/src/main/asciidoc/development/maven/jetty-maven-plugin.adoc b/jetty-documentation/src/main/asciidoc/development/maven/jetty-maven-plugin.adoc
index ef5dbd36951..7417d306879 100644
--- a/jetty-documentation/src/main/asciidoc/development/maven/jetty-maven-plugin.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/maven/jetty-maven-plugin.adoc
@@ -36,13 +36,13 @@ We recommend either the traditional distribution deployment approach or using em
First, add `jetty-maven-plugin` to your `pom.xml` definition:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
jetty-maven-plugin
- @project.version@
+ {VERSION}
@@ -50,7 +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]
+[source, screen, subs="{sub-order}"]
....
mvn jetty:run
....
@@ -78,14 +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]
+[source, screen, subs="{sub-order}"]
....
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]
+[source, screen, subs="{sub-order}"]
....
mvn jetty:help -Ddetail=true -Dgoal= goal-name
....
@@ -201,7 +201,7 @@ jetty.xml::
Importantly, it sets up the link:{SRCDIR}/jetty-server/src/main/java/org/eclipse/jetty/server/HttpConfiguration.java[`org.eclipse.jetty.server.HttpConfiguration`] element that we can refer to in subsequent xml files that configure the connectors.
Here's the relevant section:
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
https
@@ -224,7 +224,7 @@ jetty-ssl.xml::
Set up ssl which will be used by the https connector.
Here's the `jetty-ssl.xml` file from the jetty-distribution:
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
include::{SRCDIR}/jetty-server/src/main/config/etc/jetty-ssl.xml[]
----
@@ -232,19 +232,19 @@ jetty-https.xml::
Set up the https connector using the HttpConfiguration from
`jetty.xml` and the ssl configuration from` jetty-ssl.xml`:
+
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
include::{SRCDIR}/jetty-server/src/main/config/etc/jetty-https.xml[]
----
Now you need to let the plugin know to apply the files above:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
jetty-maven-plugin
- @project.version@
+ {VERSION}
jetty.xml,jetty-ssl.xml,jetty-https.xml
@@ -259,19 +259,19 @@ ____
You can also use jetty xml files to configure a http connector for the plugin to use.
Here we use the same `jetty-http.xml` file from the Jetty distribution:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
include::{SRCDIR}/jetty-server/src/main/config/etc/jetty-http.xml[]
----
Now we add it to the list of configs for the plugin to apply:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
jetty-maven-plugin
- @project.version@
+ {VERSION}
jetty.xml,jetty-http.xml,jetty-ssl.xml,jetty-https.xml
@@ -347,13 +347,13 @@ Any changes you make are immediately reflected in the running instance of Jetty,
Here is a small example, which turns on scanning for changes every ten seconds, and sets the webapp context path to `/test`:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
jetty-maven-plugin
- @project.version@
+ {VERSION}
10
@@ -406,7 +406,7 @@ scanTestClassesPattern::
Here's an example:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -416,7 +416,7 @@ Here's an example:
org.eclipse.jetty
jetty-maven-plugin
- @project.version@
+ {VERSION}
${project.basedir}/src/staticfiles
@@ -472,7 +472,7 @@ war::
Here's how to set it:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -482,7 +482,7 @@ Here's how to set it:
org.eclipse.jetty
jetty-maven-plugin
- @project.version@
+ {VERSION}
${project.basedir}/target/mycustom.war
@@ -507,7 +507,7 @@ war::
Here's how to set it:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -517,7 +517,7 @@ Here's how to set it:
org.eclipse.jetty
maven-jetty-plugin
- @project.version@
+ {VERSION}
${project.basedir}/target/myfunkywebapp
@@ -545,7 +545,7 @@ daemon::
Here's the configuration:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -555,7 +555,7 @@ Here's the configuration:
org.eclipse.jetty
jetty-maven-plugin
- @project.version@
+ {VERSION}
/opt/special/some-app.war
alpha
@@ -631,7 +631,7 @@ systemProperties::
To deploy your unassembled web app to Jetty running in a new JVM:
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
mvn jetty:run-forked
....
@@ -658,13 +658,13 @@ For example, you can configure the plugin to start your webapp at the beginning
To do this, you need to set up a couple of `execution` scenarios for the Jetty plugin.
You use the `pre-integration-test` and `post-integration-test` Maven build phases to trigger the execution and termination of Jetty:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
jetty-maven-plugin
- @project.version@
+ {VERSION}
10
foo
@@ -711,13 +711,13 @@ stopWait::
Here's a configuration example:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
jetty-maven-plugin
- @project.version@
+ {VERSION}
9966
foo
@@ -730,7 +730,7 @@ Here's a configuration example:
Then, while Jetty is running (in another window), type:
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
mvn jetty:stop
....
@@ -769,7 +769,7 @@ This is probably best seen by looking at a concrete example.
Suppose your webapp depends on the following wars:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -809,12 +809,12 @@ WebAppY:
They are configured for the http://maven.apache.org/plugins/maven-war-plugin/overlays.html[maven-war-plugin]:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.apache.maven.plugins
maven-war-plugin
- @project.version@
+ {VERSION}
@@ -852,7 +852,7 @@ The configuration parameter `` (see the section on link:#configuri
For example, suppose our webapp depends on these two wars:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
com.acme
@@ -903,12 +903,12 @@ Then our webapp has available these additional resources:
You can configure LoginServices in the plugin.
Here's an example of setting up the HashLoginService for a webapp:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
jetty-maven-plugin
- @project.version@
+ {VERSION}
10
@@ -932,7 +932,7 @@ If you have external resources that you want to incorporate in the execution of
At runtime, when Jetty receives a request for a resource, it searches all the locations to retrieve the resource.
It's a lot like the overlaid war situation, but without the war. Here's a configuration example:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -953,12 +953,12 @@ If you want to deploy webapp A, and webapps B and C in the same Jetty instance:
Putting the configuration in webapp A's `pom.xml`:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
jetty-maven-plugin
- @project.version@
+ {VERSION}
10
@@ -988,7 +988,7 @@ ____
Alternatively, add a `jetty.xml` file to webapp A.
Copy the `jetty.xml` file from the jetty distribution, and then add WebAppContexts for the other 2 webapps:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
[
@@ -1013,12 +1013,12 @@ Copy the `jetty.xml` file from the jetty distribution, and then add WebAppContex
Then configure the location of this `jetty.xml` file into webapp A's jetty plugin:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
jetty-maven-plugin
- @project.version@
+ {VERSION}
10
@@ -1042,7 +1042,7 @@ However, *sometimes it is not possible to use this feature to set System propert
time that jetty runs.
In the latter case, you can use the http://mojo.codehaus.org/properties-maven-plugin/[maven properties plugin] to define the system properties instead. Here's an example that configures the logback logging system as the jetty logger:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -1076,7 +1076,7 @@ Note that if a System property is already set (for example, from the command lin
Here's an example of how to specify System properties in the POM:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
@@ -1098,7 +1098,7 @@ Here's an example of how to specify System properties in the POM:
To change the default behaviour so that these system properties override those on the command line, use the <`force>` parameter:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
@@ -1135,7 +1135,7 @@ fooprop=222
This can be configured on the plugin like so:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
diff --git a/jetty-documentation/src/main/asciidoc/development/websockets/intro/chapter.adoc b/jetty-documentation/src/main/asciidoc/development/websockets/intro/chapter.adoc
index 66164eb739e..40abb5cc29c 100644
--- a/jetty-documentation/src/main/asciidoc/development/websockets/intro/chapter.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/websockets/intro/chapter.adoc
@@ -120,7 +120,7 @@ Completely disable jsr-356 for a particular webapp:::
Set the `org.eclipse.jetty.containerInitializerExclusionPattern` link:#context_attributes[context attribute] to include `org.eclipse.jetty.websocket.jsr356.server.deploy.WebSocketServerContainerInitializer`.
Here's an example of doing this in code, although you can do the link:#intro-jetty-configuration-webapps[same in xml]:
+
-[source,java]
+[source, java, subs="{sub-order}"]
----
WebAppContext context = new WebAppContext();
context.setAttribute("org.eclipse.jetty.containerInitializerExclusionPattern",
diff --git a/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-adapter.adoc b/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-adapter.adoc
index b2d5ded6c83..a5f6c193c34 100644
--- a/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-adapter.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-adapter.adoc
@@ -19,7 +19,7 @@
A basic adapter for managing the Session object on the WebSocketListener.
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/jetty-websocket/websocket-common/src/test/java/examples/echo/AdapterEchoSocket.java[]
----
diff --git a/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-annotations.adoc b/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-annotations.adoc
index 2fd62e559fb..7cbd39cfe79 100644
--- a/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-annotations.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-annotations.adoc
@@ -20,7 +20,7 @@
The most basic form of WebSocket is a marked up POJO with annotations
provided by the Jetty WebSocket API.
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/jetty-websocket/websocket-common/src/test/java/examples/echo/AnnotatedEchoSocket.java[]
----
diff --git a/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-listener.adoc b/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-listener.adoc
index 72b39460788..2cde0d2c93a 100644
--- a/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-listener.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-listener.adoc
@@ -19,7 +19,7 @@
The basic form of a WebSocket using the link:{JDURL}/org/eclipse/jetty/websocket/api/WebSocketListener.html[`org.eclipse.jetty.websocket.api.WebSocketListener`] for incoming events.
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/jetty-websocket/websocket-common/src/test/java/examples/echo/ListenerEchoSocket.java[]
----
diff --git a/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-send-message.adoc b/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-send-message.adoc
index 4c756f92040..dc4988e4017 100644
--- a/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-send-message.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-send-message.adoc
@@ -26,7 +26,7 @@ With RemoteEndpoint you can choose to send TEXT or BINARY WebSocket messages, or
Most calls are blocking in nature, and will not return until the send has completed (or has thrown an exception).
-[source,java]
+[source, java, subs="{sub-order}"]
----
RemoteEndpoint remote = session.getRemote();
@@ -45,7 +45,7 @@ catch (IOException e)
How to send a simple Binary message using the RemoteEndpoint.
This will block until the message is sent, possibly throwing an IOException if unable to send the message.
-[source,java]
+[source, java, subs="{sub-order}"]
----
RemoteEndpoint remote = session.getRemote();
@@ -69,7 +69,7 @@ This will block until the message is sent, possibly throwing an IOException if u
If you have a large message to send, and want to send it in pieces and parts, you can utilize the partial message sending methods of RemoteEndpoint.
Just be sure you finish sending your message (`isLast == true`).
-[source,java]
+[source, java, subs="{sub-order}"]
----
RemoteEndpoint remote = session.getRemote();
@@ -92,7 +92,7 @@ catch (IOException e)
How to send a Binary message in 2 parts, using the partial message support in RemoteEndpoint.
This will block until each part of the message is sent, possibly throwing an IOException if unable to send the partial message.
-[source,java]
+[source, java, subs="{sub-order}"]
----
RemoteEndpoint remote = session.getRemote();
@@ -118,7 +118,7 @@ This will block until each part of the message is sent, possibly throwing an IOE
You can also send Ping and Pong control frames using the RemoteEndpoint.
-[source,java]
+[source, java, subs="{sub-order}"]
----
RemoteEndpoint remote = session.getRemote();
@@ -138,7 +138,7 @@ catch (IOException e)
How to send a Ping control frame, with a payload of `"You There?"` (arriving at Remote Endpoint as a byte array payload).
This will block until the message is sent, possibly throwing an IOException if unable to send the ping frame.
-[source,java]
+[source, java, subs="{sub-order}"]
----
RemoteEndpoint remote = session.getRemote();
@@ -170,7 +170,7 @@ However there are also 2 Async send message methods available:
Both return a `Future` that can be used to test for success and failure of the message send using standard http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html[`java.util.concurrent.Future`] behavior.
-[source,java]
+[source, java, subs="{sub-order}"]
----
RemoteEndpoint remote = session.getRemote();
@@ -182,7 +182,7 @@ remote.sendBytesByFuture(buf);
How to send a simple Binary message using the RemoteEndpoint.
The message will be enqueued for outgoing write, but you will not know if it succeeded or failed.
-[source,java]
+[source, java, subs="{sub-order}"]
----
RemoteEndpoint remote = session.getRemote();
@@ -203,7 +203,7 @@ catch (ExecutionException | InterruptedException e)
How to send a simple Binary message using the RemoteEndpoint, tracking the `Future` to know if the send succeeded or failed.
-[source,java]
+[source, java, subs="{sub-order}"]
----
RemoteEndpoint remote = session.getRemote();
@@ -235,7 +235,7 @@ catch (TimeoutException e)
How to send a simple Binary message using the RemoteEndpoint, tracking the `Future` and waiting only prescribed amount of time for the send to complete, cancelling the message if the timeout occurs.
-[source,java]
+[source, java, subs="{sub-order}"]
----
RemoteEndpoint remote = session.getRemote();
@@ -246,7 +246,7 @@ remote.sendStringByFuture("Hello World");
How to send a simple Text message using the RemoteEndpoint.
The message will be enqueued for outgoing write, but you will not know if it succeeded or failed.
-[source,java]
+[source, java, subs="{sub-order}"]
----
RemoteEndpoint remote = session.getRemote();
@@ -266,7 +266,7 @@ catch (ExecutionException | InterruptedException e)
How to send a simple Binary message using the RemoteEndpoint, tracking the `Future` to know if the send succeeded or failed.
-[source,java]
+[source, java, subs="{sub-order}"]
----
RemoteEndpoint remote = session.getRemote();
diff --git a/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-session.adoc b/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-session.adoc
index 1d0113bdff0..472d4989608 100644
--- a/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-session.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-api-session.adoc
@@ -21,7 +21,7 @@ The link:{JDURL}/org/eclipse/jetty/websocket/api/Session.html[Session] object ca
The Connection State (is it open or not).
-[source,java]
+[source, java, subs="{sub-order}"]
----
if(session.isOpen()) {
// send message
@@ -30,7 +30,7 @@ if(session.isOpen()) {
Is the Connection Secure.
-[source,java]
+[source, java, subs="{sub-order}"]
----
if(session.isSecure()) {
// connection is using 'wss://'
@@ -39,7 +39,7 @@ if(session.isSecure()) {
What was in the Upgrade Request and Response.
-[source,java]
+[source, java, subs="{sub-order}"]
----
UpgradeRequest req = session.getUpgradeRequest();
String channelName = req.getParameterMap().get("channelName");
@@ -50,14 +50,14 @@ String subprotocol = resp.getAcceptedSubProtocol();
What is the Local and Remote Address.
-[source,java]
+[source, java, subs="{sub-order}"]
----
InetSocketAddress remoteAddr = session.getRemoteAddress();
----
Get and Set the Idle Timeout
-[source,java]
+[source, java, subs="{sub-order}"]
----
session.setIdleTimeout(2000); // 2 second timeout
----
diff --git a/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-client-api.adoc b/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-client-api.adoc
index f6c2d370c1d..45ad13f0316 100644
--- a/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-client-api.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-client-api.adoc
@@ -21,7 +21,7 @@ Jetty also provides a Jetty WebSocket Client Library to write make talking to We
To use the Jetty WebSocket Client on your own Java project you will need the following maven artifacts.
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty.websocket
@@ -34,14 +34,14 @@ To use the Jetty WebSocket Client on your own Java project you will need the fol
To use the WebSocketClient you will need to hook up a WebSocket object instance to a specific destination WebSocket URI.
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/jetty-websocket/websocket-client/src/test/java/examples/SimpleEchoClient.java[]
----
The above example connects to a remote WebSocket server and hands off a SimpleEchoSocket to perform the logic on the websocket once connected, waiting for the socket to register that it has closed.
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/jetty-websocket/websocket-client/src/test/java/examples/SimpleEchoSocket.java[]
----
diff --git a/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-server-api.adoc b/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-server-api.adoc
index 2d623deb8aa..19511830ece 100644
--- a/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-server-api.adoc
+++ b/jetty-documentation/src/main/asciidoc/development/websockets/jetty/jetty-websocket-server-api.adoc
@@ -27,7 +27,7 @@ This will only work when running within the Jetty Container (unlike past Jetty t
To wire up your WebSocket to a specific path via the WebSocketServlet, you will need to extend org.eclipse.jetty.websocket.servlet.WebSocketServlet and specify what WebSocket object should be created with incoming Upgrade requests.
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/jetty-websocket/websocket-servlet/src/test/java/examples/MyEchoServlet.java[]
----
@@ -53,7 +53,7 @@ Use link:{JDURL}/org/eclipse/jetty/websocket/servlet/WebSocketServletFactory.htm
If you have a more complicated creation scenario, you might want to provide your own WebSocketCreator that bases the WebSocket it creates off of information present in the UpgradeRequest object.
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/jetty-websocket/websocket-servlet/src/test/java/examples/MyAdvancedEchoCreator.java[]
----
@@ -61,7 +61,7 @@ include::{SRCDIR}/jetty-websocket/websocket-servlet/src/test/java/examples/MyAdv
Here we show a WebSocketCreator that will utilize the http://tools.ietf.org/html/rfc6455#section-1.9[WebSocket subprotocol] information from request to determine what WebSocket type should be
created.
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/jetty-websocket/websocket-servlet/src/test/java/examples/MyAdvancedEchoServlet.java[]
----
diff --git a/jetty-documentation/src/main/asciidoc/index.adoc b/jetty-documentation/src/main/asciidoc/index.adoc
index 1555d56684a..d64ec5bcc34 100644
--- a/jetty-documentation/src/main/asciidoc/index.adoc
+++ b/jetty-documentation/src/main/asciidoc/index.adoc
@@ -17,7 +17,7 @@
Jetty : The Definitive Reference
================================
:docinfo:
-:revnumber: {project.version}
+:revnumber: {VERSION}
:toc:
diff --git a/jetty-documentation/src/main/asciidoc/quick-start/configuring/how-to-configure.adoc b/jetty-documentation/src/main/asciidoc/quick-start/configuring/how-to-configure.adoc
index f4fa583f9e0..445c092208f 100644
--- a/jetty-documentation/src/main/asciidoc/quick-start/configuring/how-to-configure.adoc
+++ b/jetty-documentation/src/main/asciidoc/quick-start/configuring/how-to-configure.adoc
@@ -105,14 +105,14 @@ Property Files::
To understand the link:#jetty-xml-syntax[Jetty IoC XML format], consider the following example of an embedded Jetty server instantiated and configured in Java:
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/ExampleServer.java[]
----
link:#jetty-xml-syntax[Jetty IoC XML format] allows you to instantiate and configure the exact same server in XML without writing any java code:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/resources/exampleserver.xml[]
----
diff --git a/jetty-documentation/src/main/asciidoc/quick-start/configuring/what-to-configure.adoc b/jetty-documentation/src/main/asciidoc/quick-start/configuring/what-to-configure.adoc
index 2c12a63c57d..4f536ff4b3d 100644
--- a/jetty-documentation/src/main/asciidoc/quick-start/configuring/what-to-configure.adoc
+++ b/jetty-documentation/src/main/asciidoc/quick-start/configuring/what-to-configure.adoc
@@ -130,7 +130,7 @@ resourceBase::
In an embedded server, you configure contexts by directly calling the link:{JDURL}/org/eclipse/jetty/server/handler/ContextHandler.html[ContextHandler] API as in the following example:
-[source,java]
+[source, java, subs="{sub-order}"]
----
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/OneContext.java[]
----
@@ -140,7 +140,7 @@ include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/One
You can create and configure a context entirely by IoC XML (either Jetty's or Spring).
The deployer discovers and hot deploys context IoC descriptors like the following which creates a context to serve the Javadoc from the Jetty distribution:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -250,7 +250,7 @@ In Jetty, there are several realm implementations (called LoginServices) and the
To configure an instance of HashLoginService that matches the "Test Realm" configured above, the following `$JETTY_HOME/etc/test-realm.xml` IoC XML file should be passed on the command line or set in `start.ini`.
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
include::{SRCDIR}/tests/test-webapps/test-jetty-webapp/src/main/config/demo-base/etc/test-realm.xml[]
----
diff --git a/jetty-documentation/src/main/asciidoc/quick-start/getting-started/jetty-coordinates.adoc b/jetty-documentation/src/main/asciidoc/quick-start/getting-started/jetty-coordinates.adoc
index 1c0d014fda5..5b439d9e5b9 100644
--- a/jetty-documentation/src/main/asciidoc/quick-start/getting-started/jetty-coordinates.adoc
+++ b/jetty-documentation/src/main/asciidoc/quick-start/getting-started/jetty-coordinates.adoc
@@ -25,7 +25,7 @@ With Jetty 7 the project moved to the Eclipse foundation and to a new `groupId`
The top level Project Object Model (POM) for the Jetty project is located under the following coordinates.
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
@@ -41,7 +41,7 @@ Those generated files are also uploaded into Maven Central during the release of
http://central.maven.org/maven2/org/eclipse/jetty/jetty-project/
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
org.eclipse.jetty
diff --git a/jetty-documentation/src/main/asciidoc/quick-start/getting-started/jetty-running.adoc b/jetty-documentation/src/main/asciidoc/quick-start/getting-started/jetty-running.adoc
index 7ed5ec28175..71751198f98 100644
--- a/jetty-documentation/src/main/asciidoc/quick-start/getting-started/jetty-running.adoc
+++ b/jetty-documentation/src/main/asciidoc/quick-start/getting-started/jetty-running.adoc
@@ -19,7 +19,7 @@
To start Jetty on the default port of 8080, run the following command:
-[source, screen]
+[source, screen, subs="{sub-order}"]
----
> cd $JETTY_HOME
> java -jar start.jar
@@ -41,7 +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]
+[source, screen, subs="{sub-order}"]
----
> cd $JETTY_HOME/demo-base/
> java -jar $JETTY_HOME/start.jar
@@ -77,7 +77,7 @@ ____
You can see the configuration of the demo-base by using the following commands:
-[source, screen]
+[source, screen, subs="{sub-order}"]
----
> cd $JETTY_HOME/demo-base/
> java -jar $JETTY_HOME/start.jar --list-modules
@@ -100,7 +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]
+[source, screen, subs="{sub-order}"]
----
> cd $JETTY_BASE
> java -jar $JETTY_HOME/start.jar
@@ -108,7 +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]
+[source, screen, subs="{sub-order}"]
----
> JETTY_BASE=/tmp/mybase
> mkdir $JETTY_BASE
@@ -145,7 +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]
+[source, screen, subs="{sub-order}"]
----
> cd $JETTY_BASE
> java -jar $JETTY_HOME/start.jar jetty.http.port=8081
@@ -173,7 +173,7 @@ ____
To add the HTTPS connector to a jetty configuration, the https module can be activated by the following command:
-[source, screen]
+[source, screen, subs="{sub-order}"]
----
> java -jar $JETTY_HOME/start.jar --add-to-startd=https,http2
[...]
@@ -201,7 +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]
+[source, screen, subs="{sub-order}"]
----
> cd $JETTY_BASE
> java -jar $JETTY_HOME/start.jar jetty.ssl.port=8444
@@ -216,7 +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]
+[source, screen, subs="{sub-order}"]
----
> java -jar $JETTY_HOME/start.jar --help
----
diff --git a/jetty-documentation/src/main/asciidoc/reference/architecture/basic-architecture.adoc b/jetty-documentation/src/main/asciidoc/reference/architecture/basic-architecture.adoc
index 81517c66c96..86e0ffe8722 100644
--- a/jetty-documentation/src/main/asciidoc/reference/architecture/basic-architecture.adoc
+++ b/jetty-documentation/src/main/asciidoc/reference/architecture/basic-architecture.adoc
@@ -71,7 +71,7 @@ The Handler is the component that deals with received requests. The core API of
image:images/basic-architecture-handlers.png[image,width=576]
-[source,java]
+[source, java, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/reference/architecture/jetty-classloading.adoc b/jetty-documentation/src/main/asciidoc/reference/architecture/jetty-classloading.adoc
index 2d6f25ba1fc..a63376e54fe 100644
--- a/jetty-documentation/src/main/asciidoc/reference/architecture/jetty-classloading.adoc
+++ b/jetty-documentation/src/main/asciidoc/reference/architecture/jetty-classloading.adoc
@@ -120,7 +120,7 @@ You can place additional Jars here.
You can add an additional classpath to a context classloader by calling link:{JDURL}/org/eclipse/jetty/webapp/WebAppContext.html#setExtraClasspath(java.lang.String)[org.eclipse.jetty.webapp.WebAppContext.setExtraClasspath(String)] with a comma-separated list of paths.
You can do so directly to the API via a context XML file such as the following:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
...
@@ -135,7 +135,7 @@ If none of the alternatives already described meet your needs, you can always pr
We recommend, but do not require, that your custom loader subclasses link:{JDURL}/org/eclipse/jetty/webapp/WebAppClassLoader.html[WebAppClassLoader].
You configure the classloader for the webapp like so:
-[source,java]
+[source, java, subs="{sub-order}"]
----
MyCleverClassLoader myCleverClassLoader = new MyCleverClassLoader();
...
@@ -153,14 +153,14 @@ You can also accomplish this in a context xml file.
If you start a Jetty server using a custom class loader–consider the Jetty classes not being available to the system class loader, only your custom class loader–you may run into class loading issues when the WebAppClassLoader kicks in.
By default the WebAppClassLoader uses the system class loader as its parent, hence the problem. This is easy to fix, like so:
-[source,java]
+[source, java, subs="{sub-order}"]
----
context.setClassLoader(new WebAppClassLoader(this.getClass().getClassLoader(), context));
----
or
-[source,java]
+[source, java, subs="{sub-order}"]
----
context.setClassLoader(new WebAppClassLoader(new MyCustomClassLoader(), context));
----
diff --git a/jetty-documentation/src/main/asciidoc/reference/architecture/server-side-architecture.adoc b/jetty-documentation/src/main/asciidoc/reference/architecture/server-side-architecture.adoc
index 07c7c194ece..649bdc605a7 100644
--- a/jetty-documentation/src/main/asciidoc/reference/architecture/server-side-architecture.adoc
+++ b/jetty-documentation/src/main/asciidoc/reference/architecture/server-side-architecture.adoc
@@ -87,7 +87,7 @@ It is trivial to write the synchronous version in terms of the asynchronous vers
You can use `EndPoint.write(Callback, ByteBuffer...)` in a blocking way as follows:
-[source,java]
+[source, java, subs="{sub-order}"]
----
FutureCallback callback = new FutureCallback();
endPoint.write(callback, buffers);
diff --git a/jetty-documentation/src/main/asciidoc/reference/contributing/coding-standards.adoc b/jetty-documentation/src/main/asciidoc/reference/contributing/coding-standards.adoc
index 3eec683ad31..8efcd2033ed 100644
--- a/jetty-documentation/src/main/asciidoc/reference/contributing/coding-standards.adoc
+++ b/jetty-documentation/src/main/asciidoc/reference/contributing/coding-standards.adoc
@@ -35,7 +35,7 @@ http://git.eclipse.org/c/jetty/org.eclipse.jetty.admin.git/tree/jetty-eclipse-co
The following is an example of the Java formatting and naming styles to apply to Jetty:
-[source,java]
+[source, java, subs="{sub-order}"]
----
import some.exact.ClassName; // GOOD
diff --git a/jetty-documentation/src/main/asciidoc/reference/contributing/documentation.adoc b/jetty-documentation/src/main/asciidoc/reference/contributing/documentation.adoc
index 0f814a40503..a45da711c7b 100644
--- a/jetty-documentation/src/main/asciidoc/reference/contributing/documentation.adoc
+++ b/jetty-documentation/src/main/asciidoc/reference/contributing/documentation.adoc
@@ -50,7 +50,7 @@ First you need to obtain the source of the documentation project.
Clone the repository:
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
$ git clone https://github.com/eclipse/jetty.project.git
....
@@ -58,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ cd jetty.project/jetty-documentation
$ mvn install
@@ -70,7 +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]
+[source, screen, subs="{sub-order}"]
....
[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
@@ -84,7 +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]
+[source, screen, subs="{sub-order}"]
....
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
@@ -124,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ git commit -s -m "Tweaked the introduction to fix a horrid misspelled word." src/main/asciidoc/quickstart/introduction/topic.xml
....
@@ -138,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ git push
....
diff --git a/jetty-documentation/src/main/asciidoc/reference/contributing/release-testing.adoc b/jetty-documentation/src/main/asciidoc/reference/contributing/release-testing.adoc
index fe850051710..ca58216a33d 100644
--- a/jetty-documentation/src/main/asciidoc/reference/contributing/release-testing.adoc
+++ b/jetty-documentation/src/main/asciidoc/reference/contributing/release-testing.adoc
@@ -21,7 +21,7 @@ To test a Jetty release, complete the following steps for each release you want
1. Download the staged release:
+
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
wget https://oss.sonatype.org/content/repositories/jetty-[reponumber]/org/eclipse/jetty/jetty-distribution/[jetty-version]/jetty-distribution-9.[jetty-minor-version].tar.gz
@@ -31,7 +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]
+[source, screen, subs="{sub-order}"]
....
cd [installdir] ; java -jar start.jar
@@ -46,7 +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]
+[source, screen, subs="{sub-order}"]
....
cd [installdir] ;
@@ -57,7 +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]
+[source, screen, subs="{sub-order}"]
....
cd jetty_src/jetty-spdy/spdy-example-webapp
@@ -68,7 +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]
+[source, screen, subs="{sub-order}"]
....
mvn -Pproxy jetty:run-forked
@@ -82,7 +82,7 @@ To test a Jetty release, complete the following steps for each release you want
1. Clone CometD.
+
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
clone git://github.com/cometd/cometd.git
@@ -112,7 +112,7 @@ To test a Jetty release, complete the following steps for each release you want
....
3. Build Cometd:
+
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
mvn clean install
@@ -126,7 +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]
+[source, screen, subs="{sub-order}"]
....
========================================
@@ -200,7 +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]
+[source, screen, subs="{sub-order}"]
....
cp cometd-demo/target/cometd-demo-[version].war [pathToJetty]/jetty-distribution-[jetty-version]/webapps/
@@ -209,7 +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]
+[source, screen, subs="{sub-order}"]
....
cd [pathToJetty] && java -jar start.jar
diff --git a/jetty-documentation/src/main/asciidoc/reference/contributing/releasing-jetty.adoc b/jetty-documentation/src/main/asciidoc/reference/contributing/releasing-jetty.adoc
index 4e9a4b9bc24..ecddb7eb9a7 100644
--- a/jetty-documentation/src/main/asciidoc/reference/contributing/releasing-jetty.adoc
+++ b/jetty-documentation/src/main/asciidoc/reference/contributing/releasing-jetty.adoc
@@ -40,7 +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]
+[source, screen, subs="{sub-order}"]
....
// Get all of the remotes
@@ -57,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ mvn -N -Pupdate-version
@@ -66,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ vi VERSION.txt
@@ -75,7 +75,7 @@ $ vi VERSION.txt
....
5. Make sure everything is commit'd and pushed to github.com/eclipse/jetty.project
+
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
$ git commit -m "Updating VERSION.txt top section" VERSION.txt
@@ -88,7 +88,7 @@ $ git push origin release-9
NOTE: This step updates the 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]
+[source, screen, subs="{sub-order}"]
....
$ mvn release:prepare -DreleaseVersion=9.0.0.v20130322 \
@@ -102,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ mvn release:perform
@@ -116,7 +116,7 @@ Do not date this line.
+
Make sure everything is commit'd and pushed to github.com/eclipse/jetty.project
+
-[source, screen]
+[source, screen, subs="{sub-order}"]
....
$ vi VERSION.txt
@@ -132,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ git checkout master
@@ -151,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ cd target/checkout
@@ -179,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ ./promote-to-eclipse.sh 9.0.0.v20130322
@@ -195,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ ssh @build.eclipse.org
@@ -209,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ cd ~/downloads/jetty
diff --git a/jetty-documentation/src/main/asciidoc/reference/contributing/source-build.adoc b/jetty-documentation/src/main/asciidoc/reference/contributing/source-build.adoc
index ea7e080c3de..4d262dd015e 100644
--- a/jetty-documentation/src/main/asciidoc/reference/contributing/source-build.adoc
+++ b/jetty-documentation/src/main/asciidoc/reference/contributing/source-build.adoc
@@ -53,7 +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]
+[source, screen, subs="{sub-order}"]
....
$ git clone https://github.com/eclipse/jetty.project.git
diff --git a/jetty-documentation/src/main/asciidoc/reference/jetty-xml/jetty-env-xml.adoc b/jetty-documentation/src/main/asciidoc/reference/jetty-xml/jetty-env-xml.adoc
index 18adbd72e49..4e9b3269ffd 100644
--- a/jetty-documentation/src/main/asciidoc/reference/jetty-xml/jetty-env-xml.adoc
+++ b/jetty-documentation/src/main/asciidoc/reference/jetty-xml/jetty-env-xml.adoc
@@ -28,7 +28,7 @@ You define global naming resources on the server via `jetty.xml`.
Jetty applies `jetty-env.xml` on a per-webapp basis, and configures an instance of `org.eclipse.jetty.webapp.WebAppContext.`
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -51,7 +51,7 @@ ____
Place the `jetty-env.xml` file in your web application's WEB-INF folder.
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/reference/jetty-xml/jetty-web-xml-config.adoc b/jetty-documentation/src/main/asciidoc/reference/jetty-xml/jetty-web-xml-config.adoc
index 7d30ece7b08..154518ab115 100644
--- a/jetty-documentation/src/main/asciidoc/reference/jetty-xml/jetty-web-xml-config.adoc
+++ b/jetty-documentation/src/main/asciidoc/reference/jetty-xml/jetty-web-xml-config.adoc
@@ -28,7 +28,7 @@ For a more in-depth look at the syntax, see xref:jetty-xml-syntax[].
`jetty-web.xml` applies on a per-webapp basis, and configures an instance of `org.eclipse.jetty.webapp.WebAppContext`.
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/reference/jetty-xml/jetty-xml-config.adoc b/jetty-documentation/src/main/asciidoc/reference/jetty-xml/jetty-xml-config.adoc
index 5f0a4457d69..1849e82f623 100644
--- a/jetty-documentation/src/main/asciidoc/reference/jetty-xml/jetty-xml-config.adoc
+++ b/jetty-documentation/src/main/asciidoc/reference/jetty-xml/jetty-xml-config.adoc
@@ -37,7 +37,7 @@ The selection of which configuration files to use is controlled by xref:advanced
`jetty.xml` configures an instance of the `Jetty org.eclipse.jetty.server.Server.`
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
diff --git a/jetty-documentation/src/main/asciidoc/reference/jetty-xml/jetty-xml-syntax.adoc b/jetty-documentation/src/main/asciidoc/reference/jetty-xml/jetty-xml-syntax.adoc
index d92e6438907..6915889615a 100644
--- a/jetty-documentation/src/main/asciidoc/reference/jetty-xml/jetty-xml-syntax.adoc
+++ b/jetty-documentation/src/main/asciidoc/reference/jetty-xml/jetty-xml-syntax.adoc
@@ -29,7 +29,7 @@ See configuration files for specific examples.
The following XML configuration file creates some Java objects and sets some attributes:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -58,7 +58,7 @@ The following XML configuration file creates some Java objects and sets some att
The XML above is equivalent to the following Java code:
-[source,java]
+[source, java, subs="{sub-order}"]
----
com.acme.Foo foo = new com.acme.Foo();
foo.setName("demo");
@@ -85,7 +85,7 @@ describes all valid elements in a Jetty XML configuration file using the
Jetty IoC format. The first two lines of an XML must reference the DTD
to be used to validate the XML like:
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -116,7 +116,7 @@ most scope is given by a Configure element and elements like Call, New
and Get establish new scopes. The following example uses the name fields
to explain the scope
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
value
@@ -242,7 +242,7 @@ link:#jetty-xml-property[Property element]
====== Basic Example
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
8080
@@ -251,7 +251,7 @@ link:#jetty-xml-property[Property element]
This is equivalent to:
-[source,java]
+[source, java, subs="{sub-order}"]
----
org.eclipse.jetty.server.Server server = new org.eclipse.jetty.server.Server();
server.setPort(8080);
@@ -262,7 +262,7 @@ files
(etc/jetty.xml)
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -271,7 +271,7 @@ files
(etc/jetty-logging.xml)
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
@@ -321,7 +321,7 @@ link:#jetty-xml-property[Property element]
====== Basic Example
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
8080
@@ -330,7 +330,7 @@ link:#jetty-xml-property[Property element]
====== Set via a System Property
-[source,xml]
+[source, xml, subs="{sub-order}"]
----
]