Merge branch 'jetty-9.3.x' into pr/576
# Conflicts: # jetty-documentation/src/main/asciidoc/administration/logging/default-log ging-with-stderrlog.adoc
This commit is contained in:
Jesse McConnell
commit
643f8e8096
|
|
@ -257,6 +257,7 @@ This section is for Jetty developers that need to update the ALPN implementation
|
|||
|
||||
Clone the OpenJDK repository with the following command:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ hg clone http://hg.openjdk.java.net/jdk7u/jdk7u jdk7u # OpenJDK 7
|
||||
$ hg clone http://hg.openjdk.java.net/jdk8u/jdk8u jdk8u # OpenJDK 8
|
||||
|
|
@ -267,6 +268,7 @@ $ ./get_source.sh
|
|||
|
||||
To update the source to a specific tag, use the following command:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ ./make/scripts/hgforest.sh update <tag-name>
|
||||
|
||||
|
|
|
|||
|
|
@ -29,6 +29,7 @@ The RewriteHandler matches a request against a set of rules, and modifies the re
|
|||
|
||||
The standard Jetty distribution bundle contains the `jetty-rewrite` link:#startup-modules[module], so all you need to do is to enable it using one of the link:#start-jar[module commands], eg:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ java -jar start.jar --add-to-startd=rewrite
|
||||
|
|
|
|||
|
|
@ -95,6 +95,7 @@ Typically this can be done as the top level handler, but you may choose to confi
|
|||
Please note that `jetty-stats.xml` has to appear in the command line after the main Jetty configuration file as shown below.
|
||||
It should be able to be uncommented in the start.ini file.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ java -jar start.jar OPTIONS=default etc/jetty.xml etc/jetty-stats.xml
|
||||
|
||||
|
|
|
|||
|
|
@ -29,6 +29,7 @@ Refer to xref:jetty-downloading[] for more information about how to install Jett
|
|||
|
||||
The fourth step is to create a Jetty base directory (see xref:startup-base-and-home[]), called in the following `$JETTY_BASE`, where you setup the configuration needed to support FastCGI in Jetty, and configure the `fcgi`, `http` and `deploy` modules, so that Jetty will be able to accept HTTP requests from browsers, convert them in FastCGI, and proxy them to `php-fpm`:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ mkdir -p /usr/jetty/wordpress
|
||||
$ cd /usr/jetty/wordpress
|
||||
|
|
@ -134,6 +135,7 @@ Refer to the link:{JDURL}/org/eclipse/jetty/fcgi/server/proxy/FastCGIProxyServle
|
|||
|
||||
The last step is to start Jetty (see xref:startup[]) and hit `http://localhost:8080` with your browser and enjoy WordPress:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ cd $JETTY_BASE
|
||||
$ java -jar /opt/jetty/start.jar
|
||||
|
|
@ -147,6 +149,7 @@ In order to configure Jetty to listen for HTTP/2 requests from clients that are
|
|||
|
||||
Enabling the `http2` is really simple; in additions to the modules you have enabled above, add the `http2` module:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ cd $JETTY_BASE
|
||||
$ java -jar $JETTY_HOME/start.jar --add-to-start=http2
|
||||
|
|
@ -167,6 +170,7 @@ These will setup a clear text connector on port 8080 for HTTP/1.1 and a TLS conn
|
|||
|
||||
At this point, you can start Jetty (see xref:startup[]), hit `http://localhost:8080` with your browser and enjoy WordPress via HTTP/2 using a HTTP/2 enabled browser:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ cd $JETTY_BASE
|
||||
$ java -jar $JETTY_HOME/start.jar
|
||||
|
|
|
|||
|
|
@ -19,6 +19,7 @@
|
|||
|
||||
This section is written assuming that a jetty base directory is being used and a demo jetty base that support HTTP/1, HTTPS/1 and deployment from a webapps directory can be created with the commands:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ JETTY_BASE=http2-demo
|
||||
$ mkdir $JETTY_BASE
|
||||
|
|
|
|||
|
|
@ -29,6 +29,7 @@ To monitor Jetty's server status with JConsole, make sure JConsole is running, a
|
|||
|
||||
The simplest way to enable support is to add the jmx support module to your $\{jetty.base}.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[mybase]$ java /opt/jetty-dist/start.jar --add-to-start=jmx
|
||||
INFO: jmx-remote initialised in ${jetty.base}/start.ini (appended)
|
||||
|
|
@ -60,6 +61,7 @@ The way to do this is to set your MAVEN_OPTS environment variable (if you're not
|
|||
|
||||
Here is an example that sets the system property on the fly in a BASH shell, before starting Jetty via the plugin:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ export MAVEN_OPTS=-Dcom.sun.management.jmxremote
|
||||
|
|
|
|||
|
|
@ -82,9 +82,10 @@ There are a number of properties that can be defined in the configuration that w
|
|||
When true, outputs logging events to `STDERR` using long form, fully qualified class names.
|
||||
When false, uses abbreviated package names.
|
||||
Default is false.
|
||||
|
||||
* Example when set to false:
|
||||
|
||||
+
|
||||
* Example when set to false:
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
2014-06-03 14:36:16.013:INFO:oejs.Server:main: jetty-9.2.0.v20140526
|
||||
2014-06-03 14:36:16.028:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/opt/jetty/demo-base/webapps/] at interval 1
|
||||
|
|
@ -92,9 +93,10 @@ There are a number of properties that can be defined in the configuration that w
|
|||
2014-06-03 14:36:17.880:INFO:oejs.ServerConnector:main: Started ServerConnector@34f2d11a{HTTP/1.1}{0.0.0.0:8080}
|
||||
2014-06-03 14:36:17.888:INFO:oejs.Server:main: Started @257ms
|
||||
....
|
||||
|
||||
* Example when set to true:
|
||||
|
||||
+
|
||||
* Example when set to true:
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
2014-06-03 14:38:19.019:INFO:org.eclipse.jetty.server.Server:main: jetty-9.2.0.v20140526
|
||||
2014-06-03 14:38:19.032:INFO:org.eclipse.jetty.deploy.providers.ScanningAppProvider:main: Deployment monitor [file:/opt/jetty/demo-base/webapps/] at interval 1
|
||||
|
|
|
|||
|
|
@ -22,6 +22,7 @@ This is accomplished by configuring Jetty for logging to http://logging.apache.o
|
|||
|
||||
A convenient replacement `logging` module has been created to bootstrap your `${jetty.base}` directory for logging with log4j.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[mybase]$ mkdir modules
|
||||
[mybase]$ cd modules
|
||||
|
|
|
|||
|
|
@ -32,6 +32,7 @@ ____
|
|||
|
||||
A convenient replacement `logging` module has been created to bootstrap your `${jetty.base}` directory for logging with `java.util.logging`.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[mybase]$ mkdir modules
|
||||
[mybase]$ cd modules
|
||||
|
|
|
|||
|
|
@ -24,6 +24,7 @@ If you want to use the built-in native `JavaUtilLog` implementation, see #exampl
|
|||
|
||||
A convenient replacement `logging` module has been created to bootstrap your `${jetty.base}` directory for logging with `java.util.logging`.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[mybase]$ mkdir modules
|
||||
[mybase]$ cd modules
|
||||
|
|
|
|||
|
|
@ -35,6 +35,7 @@ See https://github.com/jetty-project/jetty-webapp-logging/blob/master/src/main/j
|
|||
|
||||
A convenient replacement `logging` module has been created to bootstrap your `${jetty.base}` directory for capturing all Jetty server logging from multiple logging frameworks into a single logging output file managed by Logback.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[mybase]$ mkdir modules
|
||||
[mybase]$ cd modules
|
||||
|
|
|
|||
|
|
@ -22,6 +22,7 @@ This is accomplished by configuring Jetty for logging to `Logback`, which uses h
|
|||
|
||||
A convenient replacement `logging` module has been created to bootstrap the `${jetty.base}` directory for logging with logback.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[mybase]$ mkdir modules
|
||||
[mybase]$ cd modules
|
||||
|
|
|
|||
|
|
@ -86,6 +86,7 @@ It also requires including the other Slf4j binding JARs in the classpath, along
|
|||
|
||||
A convenient replacement `logging` module has been created to bootstrap the `${jetty.base}` directory for capturing all Jetty server logging from multiple logging frameworks into a single logging output file managed by logback.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[mybase]$ mkdir modules
|
||||
[mybase]$ cd modules
|
||||
|
|
|
|||
|
|
@ -281,6 +281,7 @@ implementation with the OpenJDK versions.
|
|||
|
||||
Clone the OpenJDK repository with the following command:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ hg clone http://hg.openjdk.java.net/jdk7u/jdk7u jdk7u
|
||||
$ cd jdk7u
|
||||
|
|
@ -290,6 +291,7 @@ $ ./get_source.sh
|
|||
|
||||
To update the source to a specific tag, use the following command:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ ./make/scripts/hgforest.sh update <tag-name>
|
||||
|
||||
|
|
|
|||
|
|
@ -33,6 +33,7 @@ You will need the jetty-runner jar:
|
|||
Let's assume we have a very simple webapp, that does not need any resources from its environment, nor any configuration apart from the defaults.
|
||||
Starting it is as simple as doing the following:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar jetty-runner.jar simple.war
|
||||
....
|
||||
|
|
@ -41,12 +42,14 @@ This will start jetty on port 8080, and deploy the webapp to "/".
|
|||
|
||||
Your webapp does not have to be packed into a war, you can deploy a webapp that is a directory instead in the same way:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar jetty-runner.jar simple
|
||||
....
|
||||
|
||||
In fact, the webapp does not have to be a war or even a directory, it can simply be a jetty link:#using-context-provider[context xml] file that describes your webapp:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar jetty-runner.jar simple-context.xml
|
||||
....
|
||||
|
|
@ -62,6 +65,7 @@ If you have more than one webapp that must be deployed, simply provide them all
|
|||
You can control the context paths for them using the "--path" parameter.
|
||||
Here's an example of deploying 2 wars (although either or both of them could be unpacked directories instead):
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar jetty-runner.jar --path /one my1.war --path /two my2.war
|
||||
....
|
||||
|
|
@ -69,6 +73,7 @@ Here's an example of deploying 2 wars (although either or both of them could be
|
|||
If you have context xml files that describe your webapps, you can fully configure your webapps in them, and hence you don't need to use the command line switches.
|
||||
Just provide the list of context files like so:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar jetty-runner.jar my-first-context.xml my-second-context.xml my-third-context.xml
|
||||
|
||||
|
|
@ -86,6 +91,7 @@ By default the jetty-runner will listen on port 8080.
|
|||
You can easily change this on the command line using the "--port" command.
|
||||
Here's an example that runs our simple.war on port 9090:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar jetty-runner.jar --port 9090 simple.war
|
||||
....
|
||||
|
|
@ -95,6 +101,7 @@ Here's an example that runs our simple.war on port 9090:
|
|||
Instead of, or in addition to using command line switches, you can use one or more jetty.xml files to configure the environment for your webapps.
|
||||
Here's an example where we apply two different jetty.xml files:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar jetty-runner.jar --config jetty.xml --config jetty-https.xml simple.war
|
||||
....
|
||||
|
|
@ -108,6 +115,7 @@ ____
|
|||
|
||||
You can see the fill set of configuration options using the --help switch:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar jetty-runner.jar --help
|
||||
....
|
||||
|
|
@ -139,6 +147,7 @@ Context opts:
|
|||
Printing the version:::
|
||||
Print out the version of jetty and then exit immediately.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar jetty-runner.jar --version
|
||||
|
||||
|
|
@ -149,6 +158,7 @@ Configuring a request log:::
|
|||
If the file is prefixed with yyyy_mm_dd then the file will be automatically rolled over.
|
||||
Note that for finer grained configuration of the link:{JDURL}/org/eclipse/jetty/server/NCSARequestLog.html[request log], you will need to use a jetty xml file instead.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar jetty-runner.jar --log yyyy_mm_dd-requests.log my.war
|
||||
|
||||
|
|
@ -158,6 +168,7 @@ Configuring the output log:::
|
|||
Redirect the output of jetty logging to the named file.
|
||||
If the file is prefixed with yyyy_mm_dd then the file will be automatically rolled over.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar jetty-runner.jar --out yyyy_mm_dd-output.log my.war
|
||||
|
||||
|
|
@ -167,6 +178,7 @@ Configuring the interface for http:::
|
|||
Like jetty standalone, the default is for the connectors to listen on all interfaces on a machine.
|
||||
You can control that by specifying the name or ip address of the particular interface you wish to use with the --host argument:
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar jetty-runner.jar --host 192.168.22.19 my.war
|
||||
|
||||
|
|
@ -176,6 +188,7 @@ Configuring the port for http:::
|
|||
The default port number is 8080.
|
||||
To link:#how-to-configure-connectors[configure a https connector], use a jetty xml config file instead.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar jetty-runner.jar --port 9090 my.war
|
||||
|
||||
|
|
@ -186,6 +199,7 @@ Configuring stop:::
|
|||
This requires the use of a "secret" key, to prevent malicious or accidental termination.
|
||||
Use the --stop-port and --stop-key parameters as arguments to the jetty-runner:
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar jetty-runner.jar --stop-port 8181 --stop-key abc123
|
||||
|
||||
|
|
@ -195,6 +209,7 @@ Then, to stop jetty from a different terminal, you need to supply the same port
|
|||
For this you'll either need a local installation of jetty, the link:#jetty-maven-plugin[jetty-maven-plugin], the link:#jetty-ant[jetty-ant plugin], or write a custom class.
|
||||
Here's how to use a jetty installation to perform a stop:
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar start.jar --stop-port 8181 --stop-key abc123 --stop
|
||||
|
||||
|
|
@ -207,6 +222,7 @@ Configuring the container classpath:::
|
|||
--lib adds the location of a directory which contains jars to add to the container classpath.
|
||||
You can add 1 or more. Here's an example of configuring 2 directories:
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar jetty-runner.jar --lib /usr/local/external/lib --lib $HOME/external-other/lib my.war
|
||||
|
||||
|
|
@ -216,6 +232,7 @@ You can add 1 or more. Here's an example of configuring 2 directories:
|
|||
You can add 1 or more.
|
||||
Here's an example of configuring 3 extra jars:
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar jetty-runner.jar --jar /opt/stuff/jars/jar1.jar --jar $HOME/jars/jar2.jar --jar /usr/local/proj/jars/jar3.jar my.war
|
||||
|
||||
|
|
@ -225,6 +242,7 @@ Here's an example of configuring 3 extra jars:
|
|||
You can add 1 or more.
|
||||
Here's an example of configuring a single extra classes dir:
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar jetty-runner.jar --classes /opt/stuff/classes my.war
|
||||
|
||||
|
|
@ -236,6 +254,7 @@ Gathering statistics:::
|
|||
context with a password. Here's an example of enabling statistics,
|
||||
with no password protection:
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar jetty-runner.jar --stats unsecure my.war
|
||||
|
||||
|
|
@ -257,6 +276,7 @@ digest: MD5:6e120743ad67abfbc385bc2bb754e297,user
|
|||
+
|
||||
Assuming we've copied it into the local directory, we would apply it like so
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar jetty-runner.jar --stats realm.properties my.war
|
||||
|
||||
|
|
|
|||
|
|
@ -14,6 +14,7 @@
|
|||
// You may elect to redistribute this code under either of these licenses.
|
||||
// ========================================================================
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[mybase]$ java -jar /opt/jetty-distribution/start.jar --list-config
|
||||
|
||||
|
|
|
|||
|
|
@ -14,6 +14,7 @@
|
|||
// You may elect to redistribute this code under either of these licenses.
|
||||
// ========================================================================
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
WARNING: Nothing to start, exiting ...
|
||||
|
||||
|
|
|
|||
|
|
@ -14,6 +14,7 @@
|
|||
// You may elect to redistribute this code under either of these licenses.
|
||||
// ========================================================================
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[mybase]$ java -jar /opt/jetty-distribution/start.jar --list-config
|
||||
|
||||
|
|
|
|||
|
|
@ -14,6 +14,7 @@
|
|||
// You may elect to redistribute this code under either of these licenses.
|
||||
// ========================================================================
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[mybase]$ java -jar /opt/jetty-distribution/start.jar --add-to-start=http,webapp,deploy
|
||||
|
||||
|
|
|
|||
|
|
@ -14,6 +14,7 @@
|
|||
// You may elect to redistribute this code under either of these licenses.
|
||||
// ========================================================================
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[mybase]$ java -jar /opt/jetty-distribution/start.jar --list-modules
|
||||
|
||||
|
|
|
|||
|
|
@ -21,6 +21,7 @@ The most basic way of starting the Jetty standalone server is to execute
|
|||
the `start.jar`, which is a bootstrap for starting Jetty with the
|
||||
configuration you want.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[jetty-distribution-@project.version@]$ java -jar start.jar
|
||||
2013-09-23 11:27:06.654:INFO:oejs.Server:main: jetty-@project.version@
|
||||
|
|
@ -174,6 +175,7 @@ module system).
|
|||
http://graphviz.org/content/dot-language[dot file] of the module graph
|
||||
as it exists for the active `${jetty.base}`.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
# generate module.dot
|
||||
$ java -jar start.jar --module=websocket --write-module-graph=modules.dot
|
||||
|
|
|
|||
|
|
@ -61,6 +61,7 @@ enables the various demonstration webapps and server configurations.
|
|||
|
||||
How to use the demo-base directory as a Jetty Base directory.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[jetty-distribution-@project.version@]$ ls -la
|
||||
total 496
|
||||
|
|
@ -96,6 +97,7 @@ using the Jetty Base concepts.
|
|||
If you want to see what the Jetty Base looks like without executing
|
||||
Jetty, you can simply list the configuration
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[my-base]$ java -jar $JETTY_HOME/start.jar --list-config
|
||||
|
||||
|
|
@ -221,6 +223,7 @@ elements came from, be it in either in `${jetty.home}` or
|
|||
If you look at the $\{jetty.base}/start.ini you will see something like
|
||||
the following.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[my-base]$ cat start.ini
|
||||
# Enable security via jaas, and configure it
|
||||
|
|
@ -279,6 +282,7 @@ The Jetty start.jar and XML files always assume that both
|
|||
You can opt to manually define the `${jetty.home}` and `${jetty.base}`
|
||||
directories, such as this:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[jetty-distribution-@project.version@]$ pwd
|
||||
/home/user/jetty-distribution-@project.version@
|
||||
|
|
@ -296,6 +300,7 @@ The following example uses default discovery of `${jetty.home}` by using
|
|||
the parent directory of wherever start.jar itself is, and a manual
|
||||
declaration of `${jetty.base}`.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[jetty-distribution-@project.version@]$ pwd
|
||||
/home/user/jetty-distribution-@project.version@
|
||||
|
|
@ -313,6 +318,7 @@ The following demonstrates this by allowing default discovery of
|
|||
`${jetty.home}` via locating the `start.jar`, and using the `user.dir`
|
||||
System Property for `${jetty.base}`.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[jetty-distribution-@project.version@]$ pwd
|
||||
/home/user/jetty-distribution-@project.version@
|
||||
|
|
|
|||
|
|
@ -67,6 +67,7 @@ The `--list-classpath` command line option is used as such.
|
|||
(Demonstrated with the link:#demo-base[demo-base from the Jetty
|
||||
Distribution])
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[demo-base]$ java -jar $JETTY_HOME/start.jar --list-classpath
|
||||
|
||||
|
|
|
|||
|
|
@ -87,6 +87,7 @@ XML Files::
|
|||
The simplest way to start Jetty is via the `start.jar` mechanism using
|
||||
the following Java command line:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[user]$ cd jetty-distribution-@project.version@
|
||||
[jetty-distribution-@project.version@]$ java -jar start.jar --module=http jetty.http.port=8080
|
||||
|
|
@ -97,6 +98,7 @@ properties, and XML files with the metadata obtained from the `http`
|
|||
module. Specifically the `http` module is defined in the
|
||||
`${jetty.home}/modules/http.mod` file, and includes the following:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[jetty-distribution-@project.version@]$ cat modules/http.mod
|
||||
[depend]
|
||||
|
|
@ -119,6 +121,7 @@ section is not actually used by the command above, so the
|
|||
Following the server dependency, the `${jetty.home}/modules/server.mod`
|
||||
file includes:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[jetty-distribution-@project.version@]$ cat modules/server.mod
|
||||
[lib]
|
||||
|
|
@ -145,6 +148,7 @@ line required to start Jetty.
|
|||
Another way to see this is by asking Jetty what its configuration looks
|
||||
like:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[jetty-distribution-@project.version@]$ java -jar start.jar --module=http jetty.http.port=9099 --list-config
|
||||
|
||||
|
|
@ -206,6 +210,7 @@ using a traditional Java command line.
|
|||
The following is the equivalent `java` command line for what the
|
||||
`start.jar` bootstrap above performs.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[user]$ cd jetty-distribution-@project.version@
|
||||
[jetty-distribution-@project.version@]$ echo jetty.http.port=8080 > /tmp/jetty.properties
|
||||
|
|
@ -237,6 +242,7 @@ You can further simplify the startup of this server by using the INI
|
|||
template defined by the modules to create a `start.ini` file with the
|
||||
command:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[user]$ cd jetty-distribution-@project.version@
|
||||
[jetty-distribution-@project.version@]$ mkdir example-base
|
||||
|
|
@ -260,6 +266,7 @@ drwxrwxr-x 12 user webgroup 4096 Oct 4 11:49 ../
|
|||
Once complete, you can edit the `start.ini` file to modify any
|
||||
parameters and you can run the server with the simple command:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[example-base]$ java -jar $JETTY_HOME/start.jar
|
||||
....
|
||||
|
|
|
|||
|
|
@ -27,6 +27,7 @@ This script is suitable for setting up Jetty as a service in Unix.
|
|||
|
||||
The minimum steps to get Jetty to run as a Service
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[/opt/jetty]# tar -zxf /home/user/downloads/jetty-distribution-@project.version@.tar.gz
|
||||
[/opt/jetty]# cd jetty-distribution-@project.version@/
|
||||
|
|
@ -61,6 +62,7 @@ The techniques outlined here assume an installation on Linux
|
|||
|
||||
Prepare some empty directories to work with.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
# mkdir -p /opt/jetty
|
||||
# mkdir -p /opt/web/mybase
|
||||
|
|
@ -87,6 +89,7 @@ The directory purposes are as follows:
|
|||
Jetty $\{project.version} requires Java 7 (or greater) to run. Make sure
|
||||
you have it installed.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
# apt-get install openjdk-7-jdk
|
||||
....
|
||||
|
|
@ -94,6 +97,7 @@ you have it installed.
|
|||
Or download Java 7 from:
|
||||
http://www.oracle.com/technetwork/java/javase/downloads/index.html
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
# java -version
|
||||
java version "1.6.0_27"
|
||||
|
|
@ -125,6 +129,7 @@ OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
|
|||
It is recommended that you create a user to specifically run Jetty. This
|
||||
user should have the minimum set of privileges needed to run Jetty.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
# useradd --user-group --shell /bin/false --home-dir /opt/jetty/temp jetty
|
||||
....
|
||||
|
|
@ -138,6 +143,7 @@ link:#jetty-downloading[Official Eclipse Download Site]
|
|||
|
||||
Unpack it into place.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[/opt/jetty]# tar -zxf /home/user/Downloads/jetty-distribution-@project.version@.tar.gz
|
||||
[/opt/jetty]# ls -F
|
||||
|
|
@ -165,6 +171,7 @@ ____
|
|||
In past versions of Jetty, you would configure / modify / add to the jetty-distribution directory directly. While this is still supported, we encourage you to setup a proper `${jetty.base}` directory, as it will benefit you with easier jetty-distribution upgrades in the future.
|
||||
____
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
# cd /opt/web/mybase/
|
||||
[/opt/web/mybase]# ls
|
||||
|
|
@ -204,6 +211,7 @@ up and configuring a `${jetty.base}` directory.
|
|||
|
||||
Copy your war file into place.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
# cp /home/user/projects/mywebsite.war /opt/web/mybase/webapps/
|
||||
....
|
||||
|
|
@ -215,6 +223,7 @@ your opportunity to change this from the default value of `8080` to
|
|||
Edit the `/opt/web/mybase/start.ini` and change the `jetty.http.port`
|
||||
value.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
# grep jetty.http.port /opt/web/mybase/start.ini
|
||||
jetty.port=80
|
||||
|
|
@ -223,6 +232,7 @@ jetty.port=80
|
|||
Change the permissions on the Jetty distribution, and your webapp
|
||||
directories so that the user you created can access it.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
# chown --recursive jetty /opt/jetty
|
||||
# chown --recursive jetty /opt/web/mybase
|
||||
|
|
@ -231,6 +241,7 @@ directories so that the user you created can access it.
|
|||
Next we need to make the Unix System aware that we have a new Jetty
|
||||
Service that can be managed by the standard `service` calls.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
# cp /opt/jetty/jetty-distribution-@project.version@/bin/jetty.sh /etc/init.d/jetty
|
||||
# echo "JETTY_HOME=/opt/jetty/jetty-distribution-@project.version@" > /etc/default/jetty
|
||||
|
|
@ -240,6 +251,7 @@ Service that can be managed by the standard `service` calls.
|
|||
|
||||
Test out the configuration
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
# service jetty status
|
||||
Checking arguments to Jetty:
|
||||
|
|
@ -275,6 +287,7 @@ along with the service level files necessary to start the service.
|
|||
|
||||
Go ahead, start it.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
# service jetty start
|
||||
Starting Jetty: OK Wed Nov 20 12:35:28 MST 2013
|
||||
|
|
|
|||
|
|
@ -29,6 +29,7 @@ The techniques outlined here are based on Windows 7 (64-bit), using JDK
|
|||
|
||||
Prepare some empty directories to work with.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
C:\> mkdir opt
|
||||
C:\> cd opt
|
||||
|
|
@ -77,6 +78,7 @@ C:\opt\temp::
|
|||
Or download Java 7 from:
|
||||
http://www.oracle.com/technetwork/java/javase/downloads/index.html
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
C:\opt>java -version
|
||||
java version "1.7.0_45"
|
||||
|
|
@ -94,6 +96,7 @@ of the `jetty-distribution-@project.version@` directory into place at
|
|||
Once you are complete, the contents of the `C:\opt\jetty` directory
|
||||
should look like this:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
C:\opt\jetty>dir
|
||||
Volume in drive C has no label.
|
||||
|
|
@ -140,6 +143,7 @@ file.
|
|||
Once you are complete, the contents of `C:\opt` directory should look
|
||||
like this:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
C:\opt> dir
|
||||
Volume in drive C has no label.
|
||||
|
|
@ -164,6 +168,7 @@ your WebApps and the configurations that they need.
|
|||
We'll start by specifying which modules we want to use (this will create
|
||||
a start.ini file and also create a few empty directories for you)
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
C:\opt\myappbase>java -jar ..\jetty\start.jar --add-to-start=deploy,http,logging
|
||||
|
||||
|
|
@ -216,6 +221,7 @@ up and configuring a `${jetty.base}` directory.
|
|||
At this point you merely have to copy your WAR files into the webapps
|
||||
directory.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
C:\opt\myappbase> copy C:\projects\mywebsite.war webapps\
|
||||
....
|
||||
|
|
|
|||
|
|
@ -50,6 +50,7 @@ Linux does a reasonable job of self-configuring TCP/IP, but there are a few limi
|
|||
|
||||
You should increase TCP buffer sizes to at least 16MB for 10G paths and tune the auto-tuning (although you now need to consider buffer bloat).
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ sysctl -w net.core.rmem_max=16777216
|
||||
$ sysctl -w net.core.wmem_max=16777216
|
||||
|
|
@ -64,6 +65,7 @@ $ sysctl -w net.ipv4.tcp_wmem="4096 16384 16777216"
|
|||
The default value is 128; if you are running a high-volume server and connections are getting refused at a TCP level, you need to increase this.
|
||||
This is a very tweakable setting in such a case: if you set it too high, resource problems occur as it tries to notify a server of a large number of connections, and many remain pending, but if you set it too low, refused connections occur.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ sysctl -w net.core.somaxconn=4096
|
||||
|
||||
|
|
@ -72,6 +74,7 @@ This is a very tweakable setting in such a case: if you set it too high, resourc
|
|||
The `net.core.netdev_max_backlog` controls the size of the incoming packet queue for upper-layer (java) processing.
|
||||
The default (2048) may be increased and other related parameters (TODO MORE EXPLANATION) adjusted with:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ sysctl -w net.core.netdev_max_backlog=16384
|
||||
|
|
@ -85,6 +88,7 @@ $ sysctl -w net.ipv4.tcp_syncookies=1
|
|||
|
||||
If many outgoing connections are made (for example, on load generators), the operating system might run low on ports. Thus it is best to increase the port range, and allow reuse of sockets in TIME_WAIT:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ sysctl -w net.ipv4.ip_local_port_range="1024 65535"
|
||||
|
|
@ -108,6 +112,7 @@ theusername soft nofile 40000
|
|||
Linux supports pluggable congestion control algorithms.
|
||||
To get a list of congestion control algorithms that are available in your kernel run:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ sysctl net.ipv4.tcp_available_congestion_control
|
||||
|
||||
|
|
@ -116,6 +121,7 @@ $ sysctl net.ipv4.tcp_available_congestion_control
|
|||
If cubic and/or htcp are not listed, you need to research the control algorithms for your kernel.
|
||||
You can try setting the control to cubic with:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ sysctl -w net.ipv4.tcp_congestion_control=cubic
|
||||
|
||||
|
|
|
|||
|
|
@ -113,6 +113,7 @@ read the full manuals of the tools you are using if you want to specify:
|
|||
The following command generates a key pair and certificate directly into
|
||||
file `keystore`:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ keytool -keystore keystore -alias jetty -genkey -keyalg RSA
|
||||
....
|
||||
|
|
@ -129,6 +130,7 @@ passwords to protect both the keystore and the keys within it. The only
|
|||
mandatory response is to provide the fully qualified host name of the
|
||||
server at the "first and last name" prompt. For example:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ keytool -keystore keystore -alias jetty -genkey -keyalg RSA -sigalg SHA256withRSA
|
||||
Enter keystore password: password
|
||||
|
|
@ -168,6 +170,7 @@ otherwise your certificate is only valid for one month.
|
|||
If you are using java 8 or later, then you may also use the SAN
|
||||
extension to set one or more names that the certificate applies to:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ keytool -keystore keystore -alias jetty -genkey -keyalg RSA -sigalg SHA256withRSA -ext 'SAN=dns:jetty.eclipse.org,dns:*.jetty.org'
|
||||
...
|
||||
|
|
@ -178,6 +181,7 @@ $ keytool -keystore keystore -alias jetty -genkey -keyalg RSA -sigalg SHA256with
|
|||
|
||||
The following command generates a key pair in the file `jetty.key`:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ openssl genrsa -aes128 -out jetty.key
|
||||
....
|
||||
|
|
@ -188,6 +192,7 @@ arbitrary file that helps seed the random number generator.
|
|||
The following command generates a certificate for the key into the file
|
||||
` jetty.crt`:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ openssl req -new -x509 -newkey rsa:2048 -sha256 -key jetty.key -out jetty.crt
|
||||
....
|
||||
|
|
@ -201,6 +206,7 @@ passwords to protect both the keystore and the keys within it. The only
|
|||
mandatory response is to provide the fully qualified host name of the
|
||||
server at the "Common Name" prompt. For example:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ openssl genrsa -aes128 -out jetty.key
|
||||
Generating RSA private key, 2048 bit long modulus
|
||||
|
|
@ -267,6 +273,7 @@ request (CSR).
|
|||
The following command generates the file `jetty.csr` using `keytool` for
|
||||
a key/cert already in the keystore:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ keytool -certreq -alias jetty -keystore keystore -file jetty.csr
|
||||
....
|
||||
|
|
@ -277,6 +284,7 @@ $ keytool -certreq -alias jetty -keystore keystore -file jetty.csr
|
|||
The following command generates the file `jetty.csr` using OpenSSL for a
|
||||
key in the file `jetty.key`:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ openssl req -new -key jetty.key -out jetty.csr
|
||||
....
|
||||
|
|
@ -332,6 +340,7 @@ Rcz6oCRvCGCe5kDB
|
|||
The following command loads a PEM encoded certificate in the `jetty.crt`
|
||||
file into a JSSE keystore:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ keytool -keystore keystore -import -alias jetty -file jetty.crt -trustcacerts
|
||||
....
|
||||
|
|
@ -340,6 +349,7 @@ If the certificate you receive from the CA is not in a format that
|
|||
`keytool` understands, you can use the `openssl` command to convert
|
||||
formats:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ openssl x509 -in jetty.der -inform DER -outform PEM -out jetty.crt
|
||||
....
|
||||
|
|
@ -355,6 +365,7 @@ in response to your CSR.
|
|||
The following OpenSSL command combines the keys in `jetty.key` and the
|
||||
certificate in the `jetty.crt` file into the `jetty.pkcs12` file:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ openssl pkcs12 -inkey jetty.key -in jetty.crt -export -out jetty.pkcs12
|
||||
....
|
||||
|
|
@ -362,6 +373,7 @@ $ openssl pkcs12 -inkey jetty.key -in jetty.crt -export -out jetty.pkcs12
|
|||
If you have a chain of certificates, because your CA is an intermediary,
|
||||
build the PKCS12 file as follows:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ cat example.crt intermediate.crt [intermediate2.crt] ... rootCA.crt > cert-chain.txt
|
||||
$ openssl pkcs12 -export -inkey example.key -in cert-chain.txt -out example.pkcs12
|
||||
|
|
@ -374,6 +386,7 @@ OpenSSL asks for an __export password__. A non-empty password is
|
|||
required to make the next step work. Then load the resulting PKCS12 file
|
||||
into a JSSE keystore with `keytool`:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ keytool -importkeystore -srckeystore jetty.pkcs12 -srcstoretype PKCS12 -destkeystore keystore
|
||||
....
|
||||
|
|
|
|||
|
|
@ -31,6 +31,7 @@ On some Linux systems you can use the _ipchains REDIRECT_ mechanism to
|
|||
redirect from one port to another inside the kernel (if ipchains is not
|
||||
available, then usually iptables is):
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
# /sbin/ipchains -I input --proto TCP --dport 80 -j REDIRECT 8080
|
||||
....
|
||||
|
|
@ -54,6 +55,7 @@ available, then usually ipchains is).
|
|||
You need to add something like the following to the startup scripts or
|
||||
your firewall rules:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
# /sbin/iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
|
||||
....
|
||||
|
|
@ -92,6 +94,7 @@ the http port] to 80 (and link:#quickstart-changing-https-port[changed
|
|||
the https port] to 443 if you are using SSL).
|
||||
3. Enable the setuid.mod module:
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
# java -jar start.jar --add-to-start=setuid
|
||||
....
|
||||
|
|
@ -127,6 +130,7 @@ https://github.com/eclipse/jetty.toolchain/jetty-setuid[jetty-setuid]
|
|||
project. Build it locally, which will produce a native library
|
||||
appropriate for the operating system:
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
# mvn clean install
|
||||
....
|
||||
|
|
@ -142,6 +146,7 @@ location of the native library to java. Here's an example of how to do
|
|||
it on the command line, assuming were are in the
|
||||
link:#demo-webapps-base[demo-base] directory:
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
# sudo java -Djava.library.path=libsetuid-linux -jar $JETTY_HOME/start.jar
|
||||
....
|
||||
|
|
@ -152,6 +157,7 @@ link:#demo-webapps-base[demo-base] directory:
|
|||
Solaris 10 provides a User Rights Management framework that can permit
|
||||
users and processes superuser-like abilities:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
usermod -K defaultpriv=basic,net_privaddr myself
|
||||
....
|
||||
|
|
|
|||
|
|
@ -66,6 +66,7 @@ include::{SRCDIR}/examples/embedded/src/main/resources/jetty-otherserver.xml[]
|
|||
To run the other server, simply add the extra configuration file(s) to
|
||||
the command line:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
java -jar start.jar jetty-otherserver.xml
|
||||
....
|
||||
|
|
|
|||
|
|
@ -88,6 +88,7 @@ demonstration are available in overlays-demo.tar.gz. You can expand it
|
|||
on top of the jetty distribution; this tutorial expands it to /tmp and
|
||||
installs the components step-by-step:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ cd /tmp
|
||||
|
|
@ -122,6 +123,7 @@ The smarts of this are in etc/jetty-deploy.xml, which installs the
|
|||
OverlayedAppProvider into the DeploymentManager. You can then start
|
||||
Jetty normally:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ java -jar start.jar
|
||||
|
|
@ -143,6 +145,7 @@ You can download and deploy the WAR file for this demo using the
|
|||
following commands, which essentially downloads and extracts the WAR
|
||||
file to the $JETTY_HOME/overlays/webapps directory.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ cd /tmp
|
||||
|
|
@ -179,6 +182,7 @@ the web application for all instances you plan to deploy.
|
|||
You can install the demo template from the downloaded files with the
|
||||
command:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ mv $OVERLAYS/jtracTemplate\=jtrac-2.1.0 $JETTY_HOME/overlays/templates/
|
||||
|
|
@ -308,6 +312,7 @@ the configuration, which facilitates easy multi-tenant deployment.
|
|||
Now that you have installed a template, you can install one or more
|
||||
instance overlays to deploy the actual web applications:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ mv /tmp/overlays/instances/jtracTemplate\=blue $JETTY_HOME/overlays/instances/
|
||||
|
|
|
|||
|
|
@ -49,6 +49,7 @@ In a maven project this is done just by adding a dependency on the
|
|||
artifact ID jetty-quickstart or with a standard jetty distribution you
|
||||
can run the command:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ java -jar $JETTY_HOME/start.jar --add-to-startd=quickstart
|
||||
....
|
||||
|
|
@ -60,7 +61,8 @@ web application already has a `webapps/myapp.xml` file, then you can
|
|||
simply change the class in the Configure element, otherwise you can
|
||||
create an `webapps/myapp.xml` file as follows:
|
||||
|
||||
....
|
||||
[source, xml]
|
||||
____
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_0.dtd">
|
||||
<Configure class="org.eclipse.jetty.quickstart.QuickStartWebApp">
|
||||
|
|
@ -68,7 +70,7 @@ create an `webapps/myapp.xml` file as follows:
|
|||
<Set name="contextPath">/benchmark</Set>
|
||||
<Set name="autoPreconfigure">true</Set>
|
||||
</Configure>
|
||||
....
|
||||
____
|
||||
|
||||
==== Preconfiguring the web application
|
||||
|
||||
|
|
@ -84,6 +86,7 @@ class
|
|||
link:{JDURL}/org/eclipse/jetty/quickstart/PreconfigureQuickStartWar.html[org.eclipse.jetty.quickstart.PreconfigureQuickStartWar]
|
||||
simply with the jetty-all-uber (aggregate) jar:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ java -cp jetty-all-@project.version@-uber.jar org.eclipse.jetty.quickstart.PreconfigureQuickStartWar myapp.war
|
||||
....
|
||||
|
|
@ -103,12 +106,13 @@ scan to be skipped. This can be done by adding a context-param to the
|
|||
`web.xml` file (this is done automatically by the Jetty Maven JSPC
|
||||
plugin):
|
||||
|
||||
....
|
||||
[source, xml]
|
||||
____
|
||||
<context-param>
|
||||
<param-name>org.eclipse.jetty.jsp.precompiled</param-name>
|
||||
<param-value>true</param-value>
|
||||
</context-param>
|
||||
....
|
||||
____
|
||||
|
||||
==== Bypassing start.jar
|
||||
|
||||
|
|
@ -119,6 +123,7 @@ the classpath. The start.jar mechanism can be bypassed by using the
|
|||
`–dry-run` option to generate and reuse a complete command line to start
|
||||
jetty at a later time:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ RUN=$(java -jar $JETTY_HOME/start.jar --dry-run)
|
||||
$ eval $RUN
|
||||
|
|
|
|||
|
|
@ -61,12 +61,14 @@ This example assumes you have the jetty-distribution unpacked in
|
|||
|
||||
1. Create a base directory anywhere.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
[/home/user]$ mkdir my-base
|
||||
[/home/user]$ cd my-base
|
||||
....
|
||||
2. Add the modules for SSL, HTTP, and webapp deployment.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
[my-base]$ java -jar /home/user/jetty-distribution-@project.version@/start.jar --add-to-start=http,https,deploy
|
||||
|
||||
|
|
@ -85,6 +87,7 @@ server enabled in ${jetty.base}/start.ini
|
|||
....
|
||||
3. Look at your directory.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
[my-base]$ ls -la
|
||||
total 20
|
||||
|
|
@ -96,17 +99,20 @@ drwxrwxr-x 2 user group 4096 Oct 8 06:55 webapps/
|
|||
....
|
||||
4. Copy your WAR files into webapps.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
[my-base]$ ls -la
|
||||
[my-base]$ cp ~/code/project/target/gadget.war webapps/
|
||||
....
|
||||
5. Copy your keystore into place.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
[my-base]$ cp ~/code/project/keystore etc/keystore
|
||||
....
|
||||
6. Edit the `start.ini` to configure your SSL settings.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
[my-base]$ cat start.ini
|
||||
....
|
||||
|
|
@ -159,6 +165,7 @@ http.timeout=30000
|
|||
|
||||
Look at the configuration you have at this point.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[my-base]$ java -jar /home/user/jetty-distribution-@project.version@/start.jar --list-config
|
||||
|
||||
|
|
@ -231,6 +238,7 @@ Jetty Active XMLs:
|
|||
|
||||
Now start Jetty.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[my-base]$ java -jar /home/user/jetty-distribution-@project.version@/start.jar
|
||||
2013-10-08 07:06:55.837:INFO:oejs.Server:main: jetty-@project.version@
|
||||
|
|
@ -260,6 +268,7 @@ a single unit, with dependencies on other modules.
|
|||
|
||||
You can see the list of modules:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[my-base]$ java -jar /home/user/jetty-distribution-@project.version@/start.jar --list-modules
|
||||
|
||||
|
|
@ -449,6 +458,7 @@ easier to edit the `${jetty.base}/start.ini`.
|
|||
|
||||
If you want to start using a new module:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[my-base] $ java -jar ../jetty-distribution-@project.version@/start.jar --add-to-start=https
|
||||
....
|
||||
|
|
@ -487,6 +497,7 @@ For more information on the `start.jar` in 9.1, see xref:start-jar[].
|
|||
`/home/user/jetty-distribution-@project.version@`.
|
||||
2. Go to your base directory and just use the distribution, no editing.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
[my-base]$ java -jar /home/user/jetty-distribution-@project.version@/start.jar
|
||||
....
|
||||
|
|
@ -518,6 +529,7 @@ modules as well.
|
|||
You can see what the configuration looks like, after all of the modules
|
||||
are resolved, without starting Jetty via:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[my-base] $ java -jar ../jetty-distribution-@project.version@/start.jar --list-config
|
||||
....
|
||||
|
|
@ -529,6 +541,7 @@ Use the `--list-config` to see the configuration. Notice that only a
|
|||
subset of the JARs from the distribution are in use. The modules you
|
||||
have anabled determine that subset.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[my-base]$ java -jar ~/jetty-distribution-@project.version@/start.jar --list-config
|
||||
....
|
||||
|
|
|
|||
|
|
@ -38,6 +38,7 @@ generate all varieties of passwords.
|
|||
|
||||
Run it without arguments to see usage instructions:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ export JETTY_VERSION=9.0.0-SNAPSHOT
|
||||
|
|
@ -52,6 +53,7 @@ If the password is ?, the user will be prompted for the password
|
|||
For example, to generate a secured version of the password "blah" for
|
||||
the user "me", do:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ export JETTY_VERSION=9.0.0.RC0
|
||||
|
|
|
|||
|
|
@ -142,6 +142,7 @@ for the http server. To do this use a process similar to this:
|
|||
|
||||
On the windows active domain controller run:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ setspn -A HTTP/linux.mortbay.org ADUser
|
||||
|
|
@ -151,6 +152,7 @@ $ setspn -A HTTP/linux.mortbay.org ADUser
|
|||
|
||||
To create the keytab file use the following process:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ ktpass -out c:\dir\krb5.keytab -princ HTTP/linux.mortbay.org@MORTBAY.ORG -mapUser ADUser -mapOp set -pass ADUserPWD -crypto RC4-HMAC-NT -pType KRB5_NT_PRINCIPAL
|
||||
|
|
|
|||
|
|
@ -98,6 +98,7 @@ This is the minimal configuration you need. You can now start Jetty on the defau
|
|||
|
||||
At the command line enter:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> ant jetty.run
|
||||
....
|
||||
|
|
@ -345,6 +346,7 @@ stopping:::
|
|||
+
|
||||
To stop jetty via Ant, enter:
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
> ant jetty.stop
|
||||
....
|
||||
|
|
|
|||
|
|
@ -36,6 +36,7 @@ Assuming you have your webapp deployed into jetty, there are two different ways
|
|||
Via command line::
|
||||
Add the required parameters on the commandline like so.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ java -Xdebug -agentlib:jdwp=transport=dt_socket,address=9999,server=y,suspend=n -jar start.jar
|
||||
|
|
|
|||
|
|
@ -34,6 +34,7 @@ ____
|
|||
|
||||
Use curl as follows:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> mkdir Demo
|
||||
> cd Demo
|
||||
|
|
@ -57,6 +58,7 @@ include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/Hel
|
|||
|
||||
The following command compiles the HelloWorld class:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> mkdir classes
|
||||
> javac -d classes -cp jetty-all-uber.jar HelloWorld.java
|
||||
|
|
@ -67,6 +69,7 @@ The following command compiles the HelloWorld class:
|
|||
|
||||
The following command runs the HelloWorld example:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> java -cp classes:jetty-all-uber.jar org.eclipse.jetty.embedded.HelloWorld
|
||||
....
|
||||
|
|
|
|||
|
|
@ -41,6 +41,7 @@ The Metro distribution you downloaded should also contain several example web ap
|
|||
|
||||
Here's an example of the log output from Jetty when one of the sample Metro wars (from `$metro.home/samples/async`) is deployed to Jetty:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[2093] java -jar start.jar
|
||||
|
||||
|
|
|
|||
|
|
@ -26,6 +26,7 @@ If you want to replace the jetty-xml being used to start the normal Jetty distri
|
|||
The skeleton of a jetty spring module can be enabled from the jetty-distribution via the link:#startup-modules[module mechanism].
|
||||
For example:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ java -jar start.jar --add-to-startd=spring
|
||||
....
|
||||
|
|
|
|||
|
|
@ -43,6 +43,7 @@ The easiest way to configure weld is within the jetty distribution itself:
|
|||
|
||||
That should be it so when you start up your jetty distribution with the webapp you should see output similar to the following (providing your logging is the default configuration):
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
2015-06-18 12:13:54.924:INFO::main: Logging initialized @485ms
|
||||
2015-06-18 12:13:55.231:INFO:oejs.Server:main: jetty-9.3.1-SNAPSHOT
|
||||
|
|
|
|||
|
|
@ -171,6 +171,7 @@ For example, the following profile will only be invoked if the flag `-Dprod` is
|
|||
|
||||
So, the following invocation would cause your code to be compiled, the jsps to be compiled, the <servlet> and <servlet-mapping>s inserted in the web.xml and your webapp assembled into a war:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ mvn -Dprod package
|
||||
|
|
|
|||
|
|
@ -36,6 +36,7 @@ To understand the basic operations of building and running against Jetty, first
|
|||
Maven uses convention over configuration, so it is best to use the project structure Maven recommends.
|
||||
You can use _link:#archetypes[http://maven.apache.org/guides/introduction/introduction-to-archetypes.html[archetypes]]_ to quickly setup Maven projects, but we will set up the structure manually for this simple tutorial example:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> mkdir JettyMavenHelloWorld
|
||||
> cd JettyMavenHelloWorld
|
||||
|
|
@ -141,6 +142,7 @@ Use an editor to create the file `pom.xml` with the following contents:
|
|||
|
||||
You can now compile and execute the HelloWorld class by using these commands:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> mvn clean compile exec:java
|
||||
....
|
||||
|
|
@ -148,6 +150,7 @@ You can now compile and execute the HelloWorld class by using these commands:
|
|||
You can point your browser to `http://localhost:8080` to see the hello world page.
|
||||
You can observe what Maven is doing for you behind the scenes by using the `mvn dependency:tree` command, which reveals the transitive dependency resolved and downloaded as:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> mvn dependency:tree
|
||||
[INFO] Scanning for projects...
|
||||
|
|
@ -180,6 +183,7 @@ The previous section demonstrated how to use Maven with an application that embe
|
|||
Now we will examine instead how to develop a standard webapp with Maven and Jetty.
|
||||
First create the Maven structure (you can use the maven webapp archetype instead if you prefer):
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> mkdir JettyMavenHelloWarApp
|
||||
> cd JettyMavenHelloWebApp
|
||||
|
|
@ -288,6 +292,7 @@ Use an editor to create the file `pom.xml` with the following contents, noting p
|
|||
|
||||
Now you can both build and run the web application without needing to assemble it into a war by using the link:#jetty-maven-plugin[jetty-maven-plugin] via the command:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> mvn jetty:run
|
||||
....
|
||||
|
|
@ -302,6 +307,7 @@ The full reference is at link:#jetty-maven-plugin[Configuring the Jetty Maven Pl
|
|||
|
||||
You can create a Web Application Archive (WAR) file from the project with the command:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> mvn package
|
||||
....
|
||||
|
|
|
|||
|
|
@ -50,6 +50,7 @@ First, add `jetty-maven-plugin` to your `pom.xml` definition:
|
|||
|
||||
Then, from the same directory as your root `pom.xml`, type:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
mvn jetty:run
|
||||
....
|
||||
|
|
@ -77,12 +78,14 @@ There are different goals to accomplish these tasks, as well as several others.
|
|||
|
||||
To see a list of all goals supported by the Jetty Maven plugin, do:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
mvn jetty:help
|
||||
....
|
||||
|
||||
To see the detailed list of parameters that can be configured for a particular goal, in addition to its description, do:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
mvn jetty:help -Ddetail=true -Dgoal= goal-name
|
||||
....
|
||||
|
|
@ -628,6 +631,7 @@ systemProperties::
|
|||
|
||||
To deploy your unassembled web app to Jetty running in a new JVM:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
mvn jetty:run-forked
|
||||
....
|
||||
|
|
@ -726,6 +730,7 @@ Here's a configuration example:
|
|||
|
||||
Then, while Jetty is running (in another window), type:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
mvn jetty:stop
|
||||
....
|
||||
|
|
|
|||
|
|
@ -50,6 +50,7 @@ First you need to obtain the source of the documentation project.
|
|||
|
||||
Clone the repository:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ git clone https://github.com/eclipse/jetty.project.git
|
||||
....
|
||||
|
|
@ -57,6 +58,7 @@ $ git clone https://github.com/eclipse/jetty.project.git
|
|||
You will now have a local directory with all of jetty, including the jetty-documentation.
|
||||
Now we move on to building it.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ cd jetty.project/jetty-documentation
|
||||
$ mvn install
|
||||
|
|
@ -68,6 +70,7 @@ This build will first produce docbook xml and then through the docbkx-maven-plug
|
|||
The downloads are all of the java dependencies that are required to make this build work.
|
||||
After a while the downloading will stop and you should see the execution of the asciidoctor-maven-plugin followed by the docbkx-maven-plugin.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[INFO] --- asciidoctor-maven-plugin:1.5.3:process-asciidoc (output-html) @ jetty-documentation ---
|
||||
[INFO] Rendered /Users/jesse/src/projects/jetty/jetty-docs/src/main/asciidoc/index.adoc
|
||||
|
|
@ -81,6 +84,7 @@ After a while the downloading will stop and you should see the execution of the
|
|||
|
||||
The build is finished once you see a message akin to this:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
[INFO] ------------------------------------------------------------------------
|
||||
[INFO] BUILD SUCCESS
|
||||
|
|
@ -120,6 +124,7 @@ Now follow the process to push that change back into Jetty proper.
|
|||
Do make sure the change works and the build isn't broken though so make sure you run maven and check the output.
|
||||
Then commit the change.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ git commit -s -m "Tweaked the introduction to fix a horrid misspelled word." src/main/asciidoc/quickstart/introduction/topic.xml
|
||||
....
|
||||
|
|
@ -133,6 +138,7 @@ ____
|
|||
This will commit the change in your local repository.
|
||||
You can then push the change up to your repository on github.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ git push
|
||||
....
|
||||
|
|
|
|||
|
|
@ -21,6 +21,7 @@ To test a Jetty release, complete the following steps for each release you want
|
|||
|
||||
1. Download the staged release:
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
wget https://oss.sonatype.org/content/repositories/jetty-[reponumber]/org/eclipse/jetty/jetty-distribution/[jetty-version]/jetty-distribution-9.[jetty-minor-version].tar.gz
|
||||
|
|
@ -30,6 +31,7 @@ To test a Jetty release, complete the following steps for each release you want
|
|||
2. Extract to a directory of your choice.
|
||||
3. Start jetty:
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
cd [installdir] ; java -jar start.jar
|
||||
|
|
@ -44,6 +46,7 @@ To test a Jetty release, complete the following steps for each release you want
|
|||
9. In the examples section click "Servlet 3.1 Test" and verify that everything works as expected.
|
||||
10. Verify that hot deployment works.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
cd [installdir] ;
|
||||
|
|
@ -54,6 +57,7 @@ To test a Jetty release, complete the following steps for each release you want
|
|||
11. Verify that `test.war` gets redeployed in `STDOUT`.
|
||||
12. Verify that the spdy example webapp and spdy-proxy do work
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
cd jetty_src/jetty-spdy/spdy-example-webapp
|
||||
|
|
@ -64,6 +68,7 @@ To test a Jetty release, complete the following steps for each release you want
|
|||
13. Browse to https://localhost:8443 and verify that all looks ok
|
||||
14. Stop the server with CTRL+C and restart it in proxy mode:
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
mvn -Pproxy jetty:run-forked
|
||||
|
|
@ -77,6 +82,7 @@ To test a Jetty release, complete the following steps for each release you want
|
|||
|
||||
1. Clone CometD.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
clone git://github.com/cometd/cometd.git
|
||||
|
|
@ -106,6 +112,7 @@ To test a Jetty release, complete the following steps for each release you want
|
|||
....
|
||||
3. Build Cometd:
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
mvn clean install
|
||||
|
|
@ -119,6 +126,7 @@ Run the loadtest until ''JIT compilation time'' is close to a value of zero (abo
|
|||
6. Make sure that the performance results are reasonably fast.
|
||||
On a MacBook Pro i7 2.6ghz dualcore produces the following:
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
========================================
|
||||
|
|
@ -192,6 +200,7 @@ Thread Pool - Concurrent Threads max = 239 | Queue Size max = 1002 | Queue Laten
|
|||
....
|
||||
7. Deploy `cometd.war` to the `webapps` directory of the jetty-distribution tested above.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
cp cometd-demo/target/cometd-demo-[version].war [pathToJetty]/jetty-distribution-[jetty-version]/webapps/
|
||||
|
|
@ -200,6 +209,7 @@ Thread Pool - Concurrent Threads max = 239 | Queue Size max = 1002 | Queue Laten
|
|||
....
|
||||
8. Start jetty and make sure there are no exceptions.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
cd [pathToJetty] && java -jar start.jar
|
||||
|
|
|
|||
|
|
@ -40,6 +40,7 @@ Tag Name : jetty-9.9.0.v20130322
|
|||
....
|
||||
2. We use the 'release-9' branch to avoid problems with other developers actively working on the master branch.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
// Get all of the remotes
|
||||
|
|
@ -56,6 +57,7 @@ $ git merge --no-ff master
|
|||
....
|
||||
3. Update the VERSION.txt with changes from the git logs, this populates the resolves issues since the last release.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ mvn -N -Pupdate-version
|
||||
|
|
@ -64,6 +66,7 @@ $ mvn -N -Pupdate-version
|
|||
....
|
||||
4. Edit the VERSION.txt file to set the 'Release Version' at the top alongside the Date of this release.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ vi VERSION.txt
|
||||
|
|
@ -72,6 +75,7 @@ $ vi VERSION.txt
|
|||
....
|
||||
5. Make sure everything is commit'd and pushed to github.com/eclipse/jetty.project
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ git commit -m "Updating VERSION.txt top section" VERSION.txt
|
||||
|
|
@ -84,6 +88,7 @@ $ git push origin release-9
|
|||
NOTE: This step updates the <version> elements in the pom.xml files, does a test build with these new versions, and then commits the pom.xml changes to your local git repo.
|
||||
The `eclipse-release` profile is required on the prepare in order to bring in the jetty aggregates as that profile defines a module which is ignored otherwise.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ mvn release:prepare -DreleaseVersion=9.0.0.v20130322 \
|
||||
|
|
@ -97,6 +102,7 @@ $ mvn release:prepare -DreleaseVersion=9.0.0.v20130322 \
|
|||
+
|
||||
NOTE: This step performs the release and deploys it to a oss.sonatype.org staging repository.
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ mvn release:perform
|
||||
|
|
@ -110,6 +116,7 @@ Do not date this line.
|
|||
+
|
||||
Make sure everything is commit'd and pushed to github.com/eclipse/jetty.project
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ vi VERSION.txt
|
||||
|
|
@ -125,6 +132,7 @@ $ git push origin release-9
|
|||
* Release the staging repository to maven central on oss.sonatype.org
|
||||
* Merge back the changes in release-9 to master
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ git checkout master
|
||||
|
|
@ -143,6 +151,7 @@ If you don't know if you have access to this then you probably don't and will ne
|
|||
|
||||
To build and deploy the aggregate javadoc and jxr bits:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ cd target/checkout
|
||||
|
|
@ -170,6 +179,7 @@ To localize the scripts to your environment:
|
|||
|
||||
Once these are setup you can deploy a release to eclipse with the following incantation:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ ./promote-to-eclipse.sh 9.0.0.v20130322
|
||||
|
|
@ -185,6 +195,7 @@ On the eclipse side of it they will also adjust the xref and javadoc documentati
|
|||
Since we are not allowed to have symbolic links on the download site we have to log into the machine manually and remove the previous stable directory and update it with a new release.
|
||||
Maintaining the conventions we use on the site will allow all 'stable' links to be stable and not needed to update to the latest major Jetty build version:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ ssh <user>@build.eclipse.org
|
||||
|
|
@ -198,6 +209,7 @@ $ ./index.sh
|
|||
|
||||
This needs to be done for all Eclipse Jetty releases (regardless of version). In addition we have to work to reduce the footprint of jetty on the primary eclipse download resources so we want to move older releases to the eclipse archive site.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ cd ~/downloads/jetty
|
||||
|
|
|
|||
|
|
@ -53,6 +53,7 @@ Jetty uses http://maven.apache.org/[Apache Maven 3] for managing its build and p
|
|||
|
||||
Building Jetty should simply be a matter of changing into the relevant directory and executing the following commands:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
|
||||
$ git clone https://github.com/eclipse/jetty.project.git
|
||||
|
|
|
|||
|
|
@ -44,6 +44,7 @@ For the time being I'll leave this buildpack under my personal github account an
|
|||
To show how incredibly easy it is to use the Jetty buildpack with cloudfoundry, this is all the more you need to do to deploy your application.
|
||||
Refer to the CloudFoundry http://docs.cloudfoundry.com/[documentation] to get started, get the `cf` utilities installed and an environment configured.
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
$ cf push snifftest --buildpack=git://github.com/jmcc0nn3ll/jetty-buildpack.git
|
||||
|
||||
|
|
|
|||
135
jetty-documentation/src/main/docbkx-resources/css/highlighter/foundation.css
vendored
Normal file
135
jetty-documentation/src/main/docbkx-resources/css/highlighter/foundation.css
vendored
Normal file
|
|
@ -0,0 +1,135 @@
|
|||
/*
|
||||
Description: Foundation 4 docs style for highlight.js
|
||||
Author: Dan Allen <dan.j.allen@gmail.com>
|
||||
Website: http://foundation.zurb.com/docs/
|
||||
Version: 1.0
|
||||
Date: 2013-04-02
|
||||
*/
|
||||
|
||||
.hljs {
|
||||
display: block;
|
||||
overflow-x: auto;
|
||||
padding: 0.5em;
|
||||
background: #eee;
|
||||
-webkit-text-size-adjust: none;
|
||||
}
|
||||
|
||||
.hljs-header,
|
||||
.hljs-decorator,
|
||||
.hljs-annotation {
|
||||
color: #000077;
|
||||
}
|
||||
|
||||
.hljs-horizontal_rule,
|
||||
.hljs-link_url,
|
||||
.hljs-emphasis,
|
||||
.hljs-attribute {
|
||||
color: #070;
|
||||
}
|
||||
|
||||
.hljs-emphasis {
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
.hljs-link_label,
|
||||
.hljs-strong,
|
||||
.hljs-value,
|
||||
.hljs-string,
|
||||
.scss .hljs-value .hljs-string {
|
||||
color: #d14;
|
||||
}
|
||||
|
||||
.hljs-strong {
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
.hljs-blockquote,
|
||||
.hljs-comment {
|
||||
color: #998;
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
.asciidoc .hljs-title,
|
||||
.hljs-function .hljs-title {
|
||||
color: #900;
|
||||
}
|
||||
|
||||
.hljs-class {
|
||||
color: #458;
|
||||
}
|
||||
|
||||
.hljs-id,
|
||||
.hljs-pseudo,
|
||||
.hljs-constant,
|
||||
.hljs-hexcolor {
|
||||
color: teal;
|
||||
}
|
||||
|
||||
.hljs-variable {
|
||||
color: #336699;
|
||||
}
|
||||
|
||||
.hljs-bullet {
|
||||
color: #997700;
|
||||
}
|
||||
|
||||
.hljs-pi,
|
||||
.hljs-doctype {
|
||||
color: #3344bb;
|
||||
}
|
||||
|
||||
.hljs-code,
|
||||
.hljs-number {
|
||||
color: #099;
|
||||
}
|
||||
|
||||
.hljs-important {
|
||||
color: #f00;
|
||||
}
|
||||
|
||||
.smartquote,
|
||||
.hljs-label {
|
||||
color: #970;
|
||||
}
|
||||
|
||||
.hljs-preprocessor,
|
||||
.hljs-pragma {
|
||||
color: #579;
|
||||
}
|
||||
|
||||
.hljs-reserved,
|
||||
.hljs-keyword,
|
||||
.scss .hljs-value {
|
||||
color: #000;
|
||||
}
|
||||
|
||||
.hljs-regexp {
|
||||
background-color: #fff0ff;
|
||||
color: #880088;
|
||||
}
|
||||
|
||||
.hljs-symbol {
|
||||
color: #990073;
|
||||
}
|
||||
|
||||
.hljs-symbol .hljs-string {
|
||||
color: #a60;
|
||||
}
|
||||
|
||||
.hljs-tag {
|
||||
color: #007700;
|
||||
}
|
||||
|
||||
.hljs-at_rule,
|
||||
.hljs-at_rule .hljs-keyword {
|
||||
color: #088;
|
||||
}
|
||||
|
||||
.hljs-at_rule .hljs-preprocessor {
|
||||
color: #808;
|
||||
}
|
||||
|
||||
.scss .hljs-tag,
|
||||
.scss .hljs-attribute {
|
||||
color: #339;
|
||||
}
|
||||
|
|
@ -77,7 +77,7 @@ xmlns:date="http://exslt.org/dates-and-times"
|
|||
-->
|
||||
<xsl:element name="link">
|
||||
<xsl:attribute name="rel">stylesheet</xsl:attribute>
|
||||
<xsl:attribute name="href">css/highlighter/darkula.css</xsl:attribute>
|
||||
<xsl:attribute name="href">css/highlighter/foundation.css</xsl:attribute>
|
||||
</xsl:element>
|
||||
<xsl:element name="script">
|
||||
<xsl:attribute name="src">js/highlight.pack.js</xsl:attribute>
|
||||
|
|
|
|||
|
|
@ -641,6 +641,7 @@ public class HttpChannel implements Runnable, HttpOutput.Interceptor
|
|||
{
|
||||
// The bad message cannot be handled in the current state, so throw
|
||||
// to hopefull somebody that can handle
|
||||
abort(e);
|
||||
throw new BadMessageException(status,reason);
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -248,6 +248,7 @@ public class HttpChannelOverHttp extends HttpChannel implements HttpParser.Reque
|
|||
{
|
||||
// Need to call onRequest, so RequestLog can reports as much as possible
|
||||
onRequest(_metadata);
|
||||
getRequest().getHttpInput().earlyEOF();
|
||||
}
|
||||
catch (Exception e)
|
||||
{
|
||||
|
|
|
|||
|
|
@ -1,145 +1,140 @@
|
|||
//
|
||||
// ========================================================================
|
||||
// Copyright (c) 1995-2016 Mort Bay Consulting Pty. Ltd.
|
||||
// ------------------------------------------------------------------------
|
||||
// All rights reserved. This program and the accompanying materials
|
||||
// are made available under the terms of the Eclipse Public License v1.0
|
||||
// and Apache License v2.0 which accompanies this distribution.
|
||||
//
|
||||
// The Eclipse Public License is available at
|
||||
// http://www.eclipse.org/legal/epl-v10.html
|
||||
//
|
||||
// The Apache License v2.0 is available at
|
||||
// http://www.opensource.org/licenses/apache2.0.php
|
||||
//
|
||||
// You may elect to redistribute this code under either of these licenses.
|
||||
// ========================================================================
|
||||
//
|
||||
|
||||
package org.eclipse.jetty.servlet;
|
||||
|
||||
import static org.hamcrest.Matchers.containsString;
|
||||
import static org.junit.Assert.assertThat;
|
||||
|
||||
import java.io.BufferedReader;
|
||||
import java.io.IOException;
|
||||
import java.nio.charset.StandardCharsets;
|
||||
import java.util.concurrent.TimeUnit;
|
||||
|
||||
import javax.servlet.ServletInputStream;
|
||||
import javax.servlet.http.HttpServlet;
|
||||
import javax.servlet.http.HttpServletRequest;
|
||||
import javax.servlet.http.HttpServletResponse;
|
||||
|
||||
import org.eclipse.jetty.server.LocalConnector;
|
||||
import org.eclipse.jetty.server.Server;
|
||||
import org.eclipse.jetty.util.log.Log;
|
||||
import org.eclipse.jetty.util.log.Logger;
|
||||
import org.eclipse.jetty.util.log.StacklessLogging;
|
||||
import org.junit.After;
|
||||
import org.junit.Before;
|
||||
import org.junit.Ignore;
|
||||
import org.junit.Test;
|
||||
|
||||
public class PostServletTest
|
||||
{
|
||||
private static final Logger LOG = Log.getLogger(PostServletTest.class);
|
||||
|
||||
public static class BasicReadPostServlet extends HttpServlet
|
||||
{
|
||||
protected void doPost(HttpServletRequest request, HttpServletResponse response)
|
||||
{
|
||||
try
|
||||
{
|
||||
byte[] buffer = new byte[4096];
|
||||
|
||||
ServletInputStream in = request.getInputStream();
|
||||
|
||||
int l = in.read(buffer);
|
||||
while (l>0)
|
||||
{
|
||||
// System.err.println("READ: "+new String(buffer,0,l,StandardCharsets.ISO_8859_1));
|
||||
l = in.read(buffer);
|
||||
}
|
||||
|
||||
}
|
||||
catch (IOException e0)
|
||||
{
|
||||
LOG.warn(e0);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
private Server server;
|
||||
private LocalConnector connector;
|
||||
|
||||
@Before
|
||||
public void startServer() throws Exception
|
||||
{
|
||||
server = new Server();
|
||||
connector = new LocalConnector(server);
|
||||
server.addConnector(connector);
|
||||
|
||||
ServletContextHandler context = new ServletContextHandler();
|
||||
context.setContextPath("/");
|
||||
context.addServlet(BasicReadPostServlet.class, "/post");
|
||||
|
||||
server.setHandler(context);
|
||||
|
||||
server.start();
|
||||
}
|
||||
|
||||
@After
|
||||
public void stopServer() throws Exception
|
||||
{
|
||||
this.server.stop();
|
||||
}
|
||||
|
||||
@Test
|
||||
public void testGoodPost() throws Exception
|
||||
{
|
||||
StringBuilder req = new StringBuilder();
|
||||
req.append("POST /post HTTP/1.1\r\n");
|
||||
req.append("Host: localhost\r\n");
|
||||
req.append("Connection: close\r\n");
|
||||
req.append("Transfer-Encoding: chunked\r\n");
|
||||
req.append("\r\n");
|
||||
req.append("6\r\n");
|
||||
req.append("Hello ");
|
||||
req.append("\r\n");
|
||||
req.append("6\r\n");
|
||||
req.append("World\n");
|
||||
req.append("\r\n");
|
||||
req.append("0\r\n");
|
||||
req.append("\r\n");
|
||||
|
||||
String resp = connector.getResponses(req.toString());
|
||||
|
||||
assertThat("resp", resp, containsString("HTTP/1.1 200 OK"));
|
||||
}
|
||||
|
||||
@Test
|
||||
public void testBadPost() throws Exception
|
||||
{
|
||||
StringBuilder req = new StringBuilder();
|
||||
req.append("POST /post HTTP/1.1\r\n");
|
||||
req.append("Host: localhost\r\n");
|
||||
req.append("Connection: close\r\n");
|
||||
req.append("Transfer-Encoding: chunked\r\n");
|
||||
req.append("\r\n");
|
||||
req.append("6\r\n");
|
||||
req.append("Hello ");
|
||||
req.append("\r\n");
|
||||
req.append("x\r\n");
|
||||
req.append("World\n");
|
||||
req.append("\r\n");
|
||||
req.append("0\r\n");
|
||||
req.append("\r\n");
|
||||
|
||||
try (StacklessLogging scope = new StacklessLogging(ServletHandler.class))
|
||||
{
|
||||
String resp = connector.getResponses(req.toString());
|
||||
assertThat("resp", resp, containsString("HTTP/1.1 500 "));
|
||||
}
|
||||
}
|
||||
}
|
||||
//
|
||||
// ========================================================================
|
||||
// Copyright (c) 1995-2016 Mort Bay Consulting Pty. Ltd.
|
||||
// ------------------------------------------------------------------------
|
||||
// All rights reserved. This program and the accompanying materials
|
||||
// are made available under the terms of the Eclipse Public License v1.0
|
||||
// and Apache License v2.0 which accompanies this distribution.
|
||||
//
|
||||
// The Eclipse Public License is available at
|
||||
// http://www.eclipse.org/legal/epl-v10.html
|
||||
//
|
||||
// The Apache License v2.0 is available at
|
||||
// http://www.opensource.org/licenses/apache2.0.php
|
||||
//
|
||||
// You may elect to redistribute this code under either of these licenses.
|
||||
// ========================================================================
|
||||
//
|
||||
|
||||
package org.eclipse.jetty.servlet;
|
||||
|
||||
import static org.hamcrest.Matchers.containsString;
|
||||
import static org.hamcrest.Matchers.not;
|
||||
import static org.junit.Assert.assertThat;
|
||||
|
||||
import java.io.IOException;
|
||||
import java.util.concurrent.TimeUnit;
|
||||
|
||||
import javax.servlet.http.HttpServlet;
|
||||
import javax.servlet.http.HttpServletRequest;
|
||||
import javax.servlet.http.HttpServletResponse;
|
||||
|
||||
import org.eclipse.jetty.server.LocalConnector;
|
||||
import org.eclipse.jetty.server.Server;
|
||||
import org.eclipse.jetty.util.log.Log;
|
||||
import org.eclipse.jetty.util.log.Logger;
|
||||
import org.eclipse.jetty.util.log.StacklessLogging;
|
||||
import org.junit.After;
|
||||
import org.junit.Before;
|
||||
import org.junit.Ignore;
|
||||
import org.junit.Test;
|
||||
|
||||
public class PostServletTest
|
||||
{
|
||||
private static final Logger LOG = Log.getLogger(PostServletTest.class);
|
||||
|
||||
public static class BasicReadPostServlet extends HttpServlet
|
||||
{
|
||||
protected void doPost(HttpServletRequest request, HttpServletResponse response)
|
||||
{
|
||||
try
|
||||
{
|
||||
response.flushBuffer();
|
||||
request.getInputStream().read();
|
||||
}
|
||||
catch (Exception e0)
|
||||
{
|
||||
try
|
||||
{
|
||||
// this read-call should fail immediately
|
||||
request.getInputStream().read();
|
||||
}
|
||||
catch (Exception e1)
|
||||
{
|
||||
LOG.warn(e1.toString());
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
private Server server;
|
||||
private LocalConnector connector;
|
||||
|
||||
@Before
|
||||
public void startServer() throws Exception
|
||||
{
|
||||
server = new Server();
|
||||
connector = new LocalConnector(server);
|
||||
server.addConnector(connector);
|
||||
|
||||
ServletContextHandler context = new ServletContextHandler();
|
||||
context.setContextPath("/");
|
||||
context.addServlet(BasicReadPostServlet.class, "/post");
|
||||
|
||||
server.setHandler(context);
|
||||
|
||||
server.start();
|
||||
}
|
||||
|
||||
@After
|
||||
public void stopServer() throws Exception
|
||||
{
|
||||
this.server.stop();
|
||||
}
|
||||
|
||||
@Test
|
||||
public void testGoodPost() throws Exception
|
||||
{
|
||||
StringBuilder req = new StringBuilder();
|
||||
req.append("POST /post HTTP/1.1\r\n");
|
||||
req.append("Host: localhost\r\n");
|
||||
req.append("Connection: close\r\n");
|
||||
req.append("Transfer-Encoding: chunked\r\n");
|
||||
req.append("\r\n");
|
||||
req.append("6\r\n");
|
||||
req.append("Hello ");
|
||||
req.append("\r\n");
|
||||
req.append("6\r\n");
|
||||
req.append("World\n");
|
||||
req.append("\r\n");
|
||||
req.append("0\r\n");
|
||||
req.append("\r\n");
|
||||
|
||||
String resp = connector.getResponses(req.toString());
|
||||
|
||||
assertThat("resp", resp, containsString("HTTP/1.1 200 OK"));
|
||||
}
|
||||
|
||||
@Test
|
||||
public void testBadPost() throws Exception
|
||||
{
|
||||
StringBuilder req = new StringBuilder(16*1024);
|
||||
req.append("POST /post HTTP/1.1\r\n");
|
||||
req.append("Host: localhost\r\n");
|
||||
req.append("Transfer-Encoding: chunked\r\n");
|
||||
req.append("\r\n");
|
||||
// intentionally bad (not a valid chunked char here)
|
||||
for (int i=1024;i-->0;)
|
||||
req.append("xxxxxxxxxxxx");
|
||||
req.append("\r\n");
|
||||
req.append("\r\n");
|
||||
|
||||
try (StacklessLogging scope = new StacklessLogging(ServletHandler.class))
|
||||
{
|
||||
String resp = connector.getResponses(req.toString());
|
||||
assertThat("resp", resp, containsString("HTTP/1.1 200 "));
|
||||
assertThat("resp", resp, containsString("chunked"));
|
||||
assertThat("resp", resp, not(containsString("\r\n0\r\n")));
|
||||
}
|
||||
}
|
||||
}
|
||||
Loading…
Reference in New Issue