Merged branch 'jetty-9.3.x' into 'jetty-9.4.x'.
This commit is contained in:
Simone Bordet
commit
9a5d8f3943
|
|
@ -132,7 +132,8 @@
|
|||
<dependency>
|
||||
<groupId>net.sf.docbook</groupId>
|
||||
<artifactId>docbook-xml</artifactId>
|
||||
<version>5.0-all</version>
|
||||
<!--version>5.0-all</version-->
|
||||
<version>5.1b4-all</version>
|
||||
<classifier>resources</classifier>
|
||||
<type>zip</type>
|
||||
<scope>runtime</scope>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -19,3 +19,13 @@
|
|||
|
||||
This chapter discusses various options for configuring logging.
|
||||
|
||||
include::configuring-jetty-logging.adoc[]
|
||||
include::default-logging-with-stderrlog.adoc[]
|
||||
include::configuring-jetty-request-logs.adoc[]
|
||||
include::example-apache-log4j.adoc[]
|
||||
include::example-java-util-logging.adoc[]
|
||||
include::example-java-util-logging-native.adoc[]
|
||||
include::example-logback.adoc[]
|
||||
include::example-slf4j-multiple-loggers.adoc[]
|
||||
include::example-logback-centralized-logging.adoc[]
|
||||
include::dump-tool.adoc[]
|
||||
|
|
|
|||
|
|
@ -15,16 +15,13 @@
|
|||
// ========================================================================
|
||||
|
||||
[[configuring-jetty-logging]]
|
||||
= Configuring Jetty Logging
|
||||
=== Configuring Jetty Logging
|
||||
|
||||
Jetty provides logging via its own `org.eclipse.jetty.util.log.Logger`
|
||||
layer, and does not natively use any existing Java logging framework.
|
||||
All logging events, produced via the Jetty logging layer, have a name, a
|
||||
level, and a message. The name is a FQCN (fully qualified class name)
|
||||
similar to how all existing Java logging frameworks operate.
|
||||
Jetty provides logging via its own `org.eclipse.jetty.util.log.Logger` layer, and does not natively use any existing Java logging framework.
|
||||
All logging events, produced via the Jetty logging layer, have a name, a level, and a message.
|
||||
The name is a FQCN (fully qualified class name) similar to how all existing Java logging frameworks operate.
|
||||
|
||||
Jetty logging, however, has a slightly different set of levels that it
|
||||
uses internally:
|
||||
Jetty logging, however, has a slightly different set of levels that it uses internally:
|
||||
|
||||
WARN::
|
||||
For events serious enough to inform and log, but not fatal.
|
||||
|
|
@ -33,67 +30,43 @@ INFO::
|
|||
DEBUG::
|
||||
Debugging events (very noisy).
|
||||
IGNORE::
|
||||
Exception events that you can safely ignore, but useful for some
|
||||
people. You might see this level as DEBUG under some Java logging
|
||||
framework configurations, where it retains the _ignore_ phrase
|
||||
somewhere in the logging.
|
||||
|
||||
Exception events that you can safely ignore, but useful for some people.
|
||||
You might see this level as DEBUG under some Java logging framework configurations, where it retains the _ignore_ phrase somewhere in the logging.
|
||||
____
|
||||
[NOTE]
|
||||
Jetty logging produces no FATAL or SEVERE events.
|
||||
____
|
||||
|
||||
[[selecting-log-framework]]
|
||||
== Selecting the Log Framework
|
||||
==== Selecting the Log Framework
|
||||
|
||||
Configure the Jetty logging layer via the
|
||||
`org.eclipse.jetty.util.log.Log` class, following
|
||||
link:{GITBROWSEURL}/jetty-util/src/main/java/org/eclipse/jetty/util/log/Log.java[these
|
||||
rules].
|
||||
Configure the Jetty logging layer via the `org.eclipse.jetty.util.log.Log` class, following link:{GITBROWSEURL}/jetty-util/src/main/java/org/eclipse/jetty/util/log/Log.java[these rules].
|
||||
|
||||
1. Load Properties
|
||||
* First from a Classpath Resource called `jetty-logging.properties` (if
|
||||
found).
|
||||
* First from a Classpath Resource called `jetty-logging.properties` (if found).
|
||||
* Then from the `System.getProperties()`.
|
||||
2. Determine the log implementation.
|
||||
* If property `org.eclipse.jetty.util.log.class` is defined, load the
|
||||
class it defines as the logger implementation from the server classpath.
|
||||
* If the class `org.slf4j.Logger` exists in server classpath, the Jetty
|
||||
implementation becomes `org.eclipse.jetty.util.log.Slf4jLog`.
|
||||
* If no logger implementation is specified, default to
|
||||
`org.eclipse.jetty.util.log.StdErrLog`.
|
||||
|
||||
* If property `org.eclipse.jetty.util.log.class` is defined, load the class it defines as the logger implementation from the server `classpath`.
|
||||
* If the class `org.slf4j.Logger` exists in server classpath, the Jetty implementation becomes `org.eclipse.jetty.util.log.Slf4jLog`.
|
||||
* If no logger implementation is specified, default to `org.eclipse.jetty.util.log.StdErrLog`.
|
||||
____
|
||||
[NOTE]
|
||||
You can create your own custom logging by providing an implementation of
|
||||
the link:{JDURL}org/eclipse/jetty/util/log/Logger.html[Jetty Logger
|
||||
API]. For an example of a custom logger, see
|
||||
link:{GITBROWSEURL}/jetty-util/src/main/java/org/eclipse/jetty/util/log/JavaUtilLog.java[JavaUtilLog.java].
|
||||
You can create your own custom logging by providing an implementation of the link:{JDURL}org/eclipse/jetty/util/log/Logger.html[Jetty Logger API].
|
||||
For an example of a custom logger, see link:{GITBROWSEURL}/jetty-util/src/main/java/org/eclipse/jetty/util/log/JavaUtilLog.java[JavaUtilLog.java].
|
||||
____
|
||||
|
||||
[[configuring-jetty-stderrlog]]
|
||||
== The jetty-logging.properties file
|
||||
==== The jetty-logging.properties file
|
||||
|
||||
By default, the internal Jetty Logging discovery mechanism will load
|
||||
logging specific properties from a classpath resource called
|
||||
`jetty-logging.properties` and then initialize the Logging from a
|
||||
combination of properties found in that file, along with any System
|
||||
Properties.
|
||||
By default, the internal Jetty Logging discovery mechanism will load logging specific properties from a classpath resource called `jetty-logging.properties` and then initialize the Logging from a combination of properties found in that file, along with any System Properties.
|
||||
A typical jetty-logging.properties file will include at least the declaration of which logging implementation you want to use by defining a value for the `org.eclipse.jetty.util.log.class` property.
|
||||
|
||||
Examples for various logging frameworks can be found later in this documentation.
|
||||
|
||||
A typical jetty-logging.properties file will include at least the
|
||||
declaration of which logging implementation you want to use by defining
|
||||
a value for the `org.eclipse.jetty.util.log.class` property.
|
||||
|
||||
Examples for various logging frameworks can be found later in this
|
||||
documentation.
|
||||
|
||||
* Default Logging with link:#default-logging-with-stderrlog[Jetty's
|
||||
StdErrLog]
|
||||
* Default Logging with link:#default-logging-with-stderrlog[Jetty's StdErrLog]
|
||||
* Using link:#example-logging-log4j[Log4j via Slf4jLog]
|
||||
* Using link:#example-logging-logback[Logback via Slf4jLog]
|
||||
* Using java.util.logging via Slf4jLog
|
||||
* Using java.util.logging via Jetty's JavaUtilLog
|
||||
* Capturing link:#example-slf4j-multiple-loggers[Multiple Logging
|
||||
Frameworks via Slf4jLog]
|
||||
* link:#example-logging-logback-centralized[Centralized Logging with
|
||||
Logback and Sfl4jLog]
|
||||
* Capturing link:#example-slf4j-multiple-loggers[Multiple Logging Frameworks via Slf4jLog]
|
||||
* link:#example-logging-logback-centralized[Centralized Logging with Logback and Sfl4jLog]
|
||||
|
|
|
|||
|
|
@ -15,19 +15,15 @@
|
|||
// ========================================================================
|
||||
|
||||
[[configuring-jetty-request-logs]]
|
||||
= Configuring Jetty Request Logs
|
||||
=== Configuring Jetty Request Logs
|
||||
|
||||
Request logs are a record of the requests that the server has processed.
|
||||
There is one entry per request received, and commonly in the standard
|
||||
NCSA format, so you can use tools like
|
||||
http://en.wikipedia.org/wiki/Webalizer[Webalizer] to analyze them
|
||||
conveniently.
|
||||
There is one entry per request received, and commonly in the standard NCSA format, so you can use tools like http://en.wikipedia.org/wiki/Webalizer[Webalizer] to analyze them conveniently.
|
||||
|
||||
[[constructing-request-log-entry]]
|
||||
== Constructing a Request Log Entry
|
||||
==== Constructing a Request Log Entry
|
||||
|
||||
A standard request log entry includes the client IP address, date,
|
||||
method, URL, result, size, referrer, and user agent, for example:
|
||||
A standard request log entry includes the client IP address, date, method, URL, result, size, referrer, and user agent, for example:
|
||||
|
||||
....
|
||||
123.4.5.6 - - [27/Aug/2004:10:16:17 +0000]
|
||||
|
|
@ -37,25 +33,16 @@ method, URL, result, size, referrer, and user agent, for example:
|
|||
....
|
||||
|
||||
[[implementing-request-log]]
|
||||
== Implementing a Request Log
|
||||
==== Implementing a Request Log
|
||||
|
||||
Jetty provides an implementation called _`NCSARequestLog`_ which
|
||||
supports the NCSA format in files that you can roll over on a daily
|
||||
basis.
|
||||
Jetty provides an implementation called _`NCSARequestLog`_ which supports the NCSA format in files that you can roll over on a daily basis.
|
||||
|
||||
The http://logback.qos.ch/[Logback Project] offers
|
||||
http://logback.qos.ch/access.html[another implementation] of a
|
||||
RequestLog interface, providing rich and powerful HTTP-access log
|
||||
functionality.
|
||||
The http://logback.qos.ch/[Logback Project] offers http://logback.qos.ch/access.html[another implementation] of a `RequestLog` interface, providing rich and powerful HTTP-access log functionality.
|
||||
|
||||
If neither of these options meets your needs, you can implement a custom
|
||||
request logger by implementing Jetty's
|
||||
link:{JDURL}/org/eclipse/jetty/server/RequestLog.html[`RequestLog.java`]
|
||||
interface and plugging it in similar to the NCSARequestLog, as shown
|
||||
below.
|
||||
If neither of these options meets your needs, you can implement a custom request logger by implementing Jetty's link:{JDURL}/org/eclipse/jetty/server/RequestLog.html[`RequestLog.java`] interface and plugging it in similar to the `NCSARequestLog`, as shown below.
|
||||
|
||||
[[configuring-request-log]]
|
||||
== Configuring a Request Log
|
||||
==== Configuring a Request Log
|
||||
|
||||
To configure a single request log for the entire Jetty Server instance:
|
||||
|
||||
|
|
@ -85,19 +72,16 @@ requestLog.setLogTimeZone("GMT");
|
|||
server.setRequestLog(requestLog);
|
||||
----
|
||||
|
||||
This configures a request log in `$JETTY_HOME/logs` with filenames
|
||||
including the date. Old log files are kept for 90 days before being
|
||||
deleted. Existing log files are appended to and the extended NCSA format
|
||||
is used in the GMT timezone.
|
||||
This configures a request log in `$JETTY_HOME/logs` with filenames including the date.
|
||||
Old log files are kept for 90 days before being deleted.
|
||||
Existing log files are appended to and the extended NCSA format is used in the GMT time zone.
|
||||
|
||||
To examine many more configuration options, see
|
||||
link:{JDURL}/org/eclipse/jetty/server/NCSARequestLog.html[NCSARequestLog.java]
|
||||
To examine many more configuration options, see link:{JDURL}/org/eclipse/jetty/server/NCSARequestLog.html[NCSARequestLog.java].
|
||||
|
||||
[[configuring-separate-request-log-for-web-application]]
|
||||
== Configuring a Separate Request Log For a Web Application
|
||||
==== Configuring a Separate Request Log For a Web Application
|
||||
|
||||
To configure a separate request log for a web application, add the
|
||||
following to the context XML file.
|
||||
To configure a separate request log for a web application, add the following to the context XML file.
|
||||
|
||||
[source,xml]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -15,45 +15,37 @@
|
|||
// ========================================================================
|
||||
|
||||
[[default-logging-with-stderrlog]]
|
||||
= Default Logging with Jetty's StdErrLog
|
||||
=== Default Logging with Jetty's StdErrLog
|
||||
|
||||
If you do nothing to configure your own logging framework, then Jetty
|
||||
will default to using an internal `org.eclipse.jetty.util.log.StdErrLog`
|
||||
implementation. This will output all logging events to STDERR (aka
|
||||
System.err).
|
||||
[[stderrlog-configuration]]
|
||||
==== StdErrLog Configuration
|
||||
|
||||
Simply use Jetty and you get StdErrLog based logging output.
|
||||
If you do nothing to configure a separate logging framework, Jetty will default to using an internal `org.eclipse.jetty.util.log.StdErrLog` implementation.
|
||||
This will output all logging events to STDERR (aka `System.err`).
|
||||
|
||||
Included in the Jetty distribution is a logging module that is capable
|
||||
of performing simple capturing of all STDOUT and STDERR output to a file
|
||||
that is rotated daily.
|
||||
Simply use Jetty and `StdErrLog` based logging is output.
|
||||
|
||||
To enable on the command line:
|
||||
Included in the Jetty distribution is a logging module that is capable of performing simple capturing of all STDOUT and STDERR output to a file that is rotated daily.
|
||||
|
||||
To enable on this feature via the command line:
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
[my-base]$ java -jar /opt/jetty/start.jar --module=logging
|
||||
----
|
||||
|
||||
You can also include the `--module=logging` command in your
|
||||
`${jetty.base}/start.ini`
|
||||
You can also include the `--module=logging` command in your `${jetty.base}/start.ini`.
|
||||
|
||||
[source,bash]
|
||||
----
|
||||
[my-base]$ java -jar /opt/jetty/start.jar --add-to-start=logging
|
||||
----
|
||||
|
||||
The default configuration for logging output will create a file
|
||||
`${jetty.logs}/yyyy_mm_dd.stderrout.log` which allows you to configure
|
||||
the output directory by setting the `jetty.logs` property to a path of
|
||||
your choice.
|
||||
The default configuration for logging output will create a file `${jetty.logs}/yyyy_mm_dd.stderrout.log` which allows configuration of the output directory by setting the `jetty.logs` property.
|
||||
|
||||
If you want a more advanced configuration of your logging output,
|
||||
consider using your logging library of choice.
|
||||
For more advanced logging configurations, please consider use of a separate logging library.
|
||||
|
||||
The recommended way to configure StdErrLog is to create a
|
||||
`${jetty.home}/resources/jetty-logging.properties` file, specify the Log
|
||||
implementation to StdErrLog and then setup your logging levels.
|
||||
The recommended way to configure `StdErrLog` is to create a `${jetty.home}/resources/jetty-logging.properties` file, specify the log implementation to `StdErrLog` and then setup logging levels.
|
||||
|
||||
[source,properties]
|
||||
----
|
||||
|
|
@ -65,46 +57,34 @@ org.eclipse.jetty.LEVEL=INFO
|
|||
org.eclipse.jetty.websocket.LEVEL=DEBUG
|
||||
----
|
||||
|
||||
There are a number of properties you can define in here that will affect
|
||||
the StdErrLog behavior.
|
||||
There are a number of properties that can be defined in the configuration that will affect the behavior of `StdErrLog`.
|
||||
|
||||
`<name>.LEVEL=<level>`::
|
||||
Sets the logging level for all loggers within the `name` specified to
|
||||
the level, which can be (in increasing order of restriction) `ALL`,
|
||||
`DEBUG`, `INFO`, `WARN`, `OFF`. The name (or hierarchy) can be a
|
||||
specific fully qualified class or a package namespace, for example,
|
||||
`org.eclipse.jetty.http.LEVEL=DEBUG` is a package namespace approach
|
||||
to turn all loggers in the Jetty HTTP package to DEBUG level, and
|
||||
`org.eclipse.jetty.io.ChanelEndPoint.LEVEL=ALL` turns on all logging
|
||||
events for the specific class, including `DEBUG`, `INFO`, `WARN` (and
|
||||
even special internally ignored exception classes). If more than one
|
||||
system property specifies a logging level, the most specific one
|
||||
applies.
|
||||
Sets the logging level for all loggers within the `name` specified to the level, which can be (in increasing order of restriction) `ALL`, `DEBUG`, `INFO`, `WARN`, `OFF`.
|
||||
The name (or hierarchy) can be a specific fully qualified class or a package namespace.
|
||||
For example, `org.eclipse.jetty.http.LEVEL=DEBUG` is a package namespace approach to turn all loggers in the Jetty HTTP package to DEBUG level, and `org.eclipse.jetty.io.ChanelEndPoint.LEVEL=ALL` turns on all logging events for the specific class, including `DEBUG`, `INFO`, `WARN` (and even special internally ignored exception classes).
|
||||
If more than one system property specifies a logging level, the most specific one applies.
|
||||
`<name>.SOURCE=<boolean>`::
|
||||
Named Logger specific, attempts to print the Java source file name and
|
||||
line number from where the logging event originated. Name must be a
|
||||
fully qualified class name (this configurable does not support package
|
||||
name hierarchy). Default is false. Be aware that this is a slow
|
||||
operation and has an impact on performance.
|
||||
Named Logger specific, attempts to print the Java source file name and line number from where the logging event originated.
|
||||
Name must be a fully qualified class name (this configurable does not support package name hierarchy).
|
||||
Default is false.
|
||||
Be aware that this is a slow operation and has an impact on performance.
|
||||
`<name>.STACKS=<boolean>`::
|
||||
Named Logger specific, controls the display of stacktraces. Name must
|
||||
be a fully qualified class name (this configurable does not support
|
||||
package name hierarchy).
|
||||
+
|
||||
Named Logger specific, controls the display of stacktraces.
|
||||
Name must be a fully qualified class name (this configurable does not support package name hierarchy).
|
||||
Default is true.
|
||||
`org.eclipse.jetty.util.log.stderr.SOURCE=<boolean>`::
|
||||
Special Global Configuration. Attempts to print the Java source file
|
||||
name and line number from where the logging event originated. Default
|
||||
is false.
|
||||
`org.eclipse.jetty.util.log.stderr.LONG=<boolean>`::
|
||||
Special Global Configuration. When true, outputs logging events to
|
||||
STDERR using long form, fully qualified class names. When false, uses
|
||||
abbreviated package names.
|
||||
+
|
||||
Special Global Configuration.
|
||||
Attempts to print the Java source file name and line number from where the logging event originated.
|
||||
Default is false.
|
||||
+
|
||||
Example when set to false:
|
||||
+
|
||||
`org.eclipse.jetty.util.log.stderr.LONG=<boolean>`::
|
||||
Special Global Configuration.
|
||||
When true, outputs logging events to `STDERR` using long form, fully qualified class names.
|
||||
When false, uses abbreviated package names.
|
||||
Default is false.
|
||||
* Example when set to false:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
2014-06-03 14:36:16.013:INFO:oejs.Server:main: jetty-9.2.0.v20140526
|
||||
2014-06-03 14:36:16.028:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/opt/jetty/demo-base/webapps/] at interval 1
|
||||
|
|
@ -113,8 +93,9 @@ the StdErrLog behavior.
|
|||
2014-06-03 14:36:17.888:INFO:oejs.Server:main: Started @257ms
|
||||
....
|
||||
+
|
||||
Example when set to true:
|
||||
* Example when set to true:
|
||||
+
|
||||
[source, screen]
|
||||
....
|
||||
2014-06-03 14:38:19.019:INFO:org.eclipse.jetty.server.Server:main: jetty-9.2.0.v20140526
|
||||
2014-06-03 14:38:19.032:INFO:org.eclipse.jetty.deploy.providers.ScanningAppProvider:main: Deployment monitor [file:/opt/jetty/demo-base/webapps/] at interval 1
|
||||
|
|
@ -123,28 +104,19 @@ the StdErrLog behavior.
|
|||
2014-06-03 14:38:20.723:INFO:org.eclipse.jetty.server.Server:main: Started @243ms
|
||||
....
|
||||
|
||||
Deprecated Parameters:
|
||||
[[deprecated-parameters]]
|
||||
==== Deprecated Parameters
|
||||
|
||||
These parameters existed in prior versions of Jetty, and are no longer
|
||||
supported. They are included here for historical (and search engine)
|
||||
reasons.
|
||||
These parameters existed in prior versions of Jetty, and are no longer supported.
|
||||
They are included here for historical (and search engine) reasons.
|
||||
|
||||
`org.eclipse.jetty.util.log.DEBUG`::
|
||||
Formerly used to enable DEBUG level logging on any logger used within
|
||||
Jetty (not just Jetty's own logger).
|
||||
+
|
||||
Replaced with using the logger implementation specific configuration
|
||||
and level filtering.
|
||||
Formerly used to enable DEBUG level logging on any logger used within Jetty (not just Jetty's own logger).
|
||||
* Replaced with using the logger implementation specific configuration and level filtering.
|
||||
`org.eclipse.jetty.util.log.stderr.DEBUG`::
|
||||
Formerly used to enable DEBUG level logging on the internal Jetty
|
||||
StdErrLog implementation.
|
||||
+
|
||||
Replaced with level specific equivalent: example:
|
||||
`org.eclipse.jetty.LEVEL=DEBUG`
|
||||
Formerly used to enable DEBUG level logging on the internal Jetty `StdErrLog` implementation.
|
||||
* Replaced with level specific equivalent.
|
||||
Example: `org.eclipse.jetty.LEVEL=DEBUG`
|
||||
`DEBUG`::
|
||||
Ancient debugging flag that turned on all debugging, even non-logging
|
||||
debugging.
|
||||
+
|
||||
Jetty no longer uses because many third party libraries employ this
|
||||
overly simple property name, which would generate far too much console
|
||||
output.
|
||||
Ancient debugging flag that turned on all debugging, even non-logging debugging.
|
||||
* Jetty no longer uses because many third party libraries employ this overly simple property name, which would generate far too much console output.
|
||||
|
|
|
|||
|
|
@ -15,18 +15,14 @@
|
|||
// ========================================================================
|
||||
|
||||
[[example-logging-log4j]]
|
||||
= Example: Logging with Apache Log4j
|
||||
=== Example: Logging with Apache Log4j
|
||||
|
||||
It is possible to have the Jetty Server logging configured so that Log4j
|
||||
controls the output of logging events produced by Jetty. This is
|
||||
accomplished by configuring Jetty for logging to
|
||||
http://logging.apache.org/log4j/[Apache Log4j] via
|
||||
http://slf4j.org/manual.html[Slf4j] and the
|
||||
http://slf4j.org/manual.html#swapping[Slf4j binding layer for Log4j].
|
||||
It is possible to have the Jetty Server logging configured so that Log4j controls the output of logging events produced by Jetty.
|
||||
This is accomplished by configuring Jetty for logging to http://logging.apache.org/log4j/[Apache Log4j] via http://slf4j.org/manual.html[Slf4j] and the http://slf4j.org/manual.html#swapping[Slf4j binding layer for Log4j].
|
||||
|
||||
A convenient replacement `logging` module has been created to bootstrap
|
||||
your `${jetty.base}` directory for logging with log4j.
|
||||
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
|
||||
|
|
@ -53,37 +49,19 @@ INFO: resources enabled in ${jetty.base}/start.ini
|
|||
|
||||
The replacement `logging.mod` performs a number of tasks.
|
||||
|
||||
1. `mybase` is a `${jetty.base}` directory
|
||||
2. The jetty-distribution is unpacked (and untouched) into
|
||||
`/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this
|
||||
demonstration.
|
||||
3. The `curl` command downloads the replacement `logging.mod` and puts
|
||||
it into the `${jetty.base}/modules/` directory for use by mybase only.
|
||||
4. The `start.jar --add-to-start=logging` command performs a number of
|
||||
steps to make the logging module available to the `${jetty.base}`
|
||||
configuration.
|
||||
1. The `--module=logging` command is added to the
|
||||
`${jetty.base}/start.ini` configuration
|
||||
2. Required `${jetty.base}` directories are created:
|
||||
`${jetty.base}/logs` and `${jetty.base}/resources`
|
||||
3. Required libraries are downloaded (if not present already):
|
||||
slf4j-api, slf4j-log4j, and log4j itself.
|
||||
+
|
||||
The libraries are put in the `${jetty.base}/lib/logging/` directory.
|
||||
4. Required configuration files are downloaded (if not present
|
||||
already): `jetty-logging.properties`, and `log4j.properties`
|
||||
+
|
||||
The configuration files are put in the `${jetty.base}/resources/`
|
||||
directory.
|
||||
5. At this point you have your `mybase` configured so that the jetty
|
||||
server itself will log using log4j, using the log4j configuration found
|
||||
in `mybase/resources/log4j.properties`
|
||||
. `mybase` is a `${jetty.base}` directory.
|
||||
. The jetty-distribution is unpacked (and untouched) into `/opt/jetty-dist/` and becomes the `${jetty.home}` directory for this demonstration.
|
||||
. The `curl` command downloads the replacement `logging.mod` and puts it into the `${jetty.base}/modules/` directory for use by mybase only.
|
||||
. The `start.jar --add-to-start=logging` command performs a number of steps to make the logging module available to the `${jetty.base}` configuration.
|
||||
.. The `--module=logging` command is added to the `${jetty.base}/start.ini` configuration.
|
||||
.. Required `${jetty.base}` directories are created: `${jetty.base}/logs` and `${jetty.base}/resources`
|
||||
.. Required libraries are downloaded (if not present already): slf4j-api, slf4j-log4j, and log4j itself.
|
||||
* The libraries are put in the `${jetty.base}/lib/logging/` directory.
|
||||
.. Required configuration files are downloaded (if not present already): `jetty-logging.properties`, and `log4j.properties`
|
||||
* The configuration files are placed in the `${jetty.base}/resources/` directory.
|
||||
|
||||
You can verify the server classpath by using the `start.jar
|
||||
--list-config` command.
|
||||
At this point the Jetty `mybase` is configured so that the Jetty server itself will log using log4j, using the log4j configuration found in `mybase/resources/log4j.properties`.
|
||||
|
||||
In essence, Jetty is now configured to emit its own logging events to
|
||||
slf4j, and slf4j itself is using the static log binder found in
|
||||
slf4j-log4j12.jar. Making all Jetty + Slf4j + Log4j events emitted by
|
||||
the Jetty server go to Log4j for routing (to console, file, syslog,
|
||||
etc...)
|
||||
The server classpath can be verified by using the `start.jar --list-config` command.
|
||||
|
||||
In essence, Jetty is now configured to emit its own logging events to slf4j, and slf4j itself is using the static log binder found in `slf4j-log4j12.jar`, making all Jetty + Slf4j + Log4j events emitted by the Jetty server go to Log4j for routing (to console, file, syslog, etc...).
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@
|
|||
// ========================================================================
|
||||
|
||||
[[example-logging-java-util-logging-native]]
|
||||
= Example: Logging with Java's java.util.logging via JavaUtilLog
|
||||
=== Example: Logging with Java's java.util.logging via JavaUtilLog
|
||||
|
||||
It is possible to have the Jetty Server logging configured so that
|
||||
`java.util.logging` controls the output of logging events produced by
|
||||
|
|
@ -26,13 +26,13 @@ This example demonstrates how to configuring Jetty for logging to
|
|||
|
||||
____
|
||||
[IMPORTANT]
|
||||
While this is a valid setup, the Jetty project recommends always using the link:#example-logging-java-util-logging[slf4j to java.util.logging configuration] for memory and performance reasons.
|
||||
(this naive implementation is very non-performant and is not guaranteed to exist in the future)
|
||||
While this is a valid setup, the Jetty project recommends always using the link:#example-logging-java-util-logging[slf4j to java.util.logging configuration] for memory and performance reasons.
|
||||
This native implementation is very non-performant and is not guaranteed to exist in the future.
|
||||
____
|
||||
|
||||
A convenient replacement `logging` module has been created to bootstrap
|
||||
your `${jetty.base}` directory for logging with java.util.logging.
|
||||
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
|
||||
|
|
@ -57,53 +57,34 @@ INFO: resources enabled in ${jetty.base}/${jetty.base}
|
|||
|
||||
The replacement `logging.mod` performs a number of tasks.
|
||||
|
||||
1. `mybase` is a `${jetty.base}` directory
|
||||
2. The jetty-distribution is unpacked (and untouched) into
|
||||
`/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this
|
||||
demonstration.
|
||||
3. The `curl` command downloads the replacement `logging.mod` and puts
|
||||
it into the `${jetty.base}/modules/` directory for use by mybase only.
|
||||
4. The `start.jar --add-to-start=logging` command performs a number of
|
||||
steps to make the logging module available to the `${jetty.base}`
|
||||
. `mybase` is a `${jetty.base}` directory.
|
||||
. The jetty-distribution is unpacked (and untouched) into `/opt/jetty-dist/` and becomes the `${jetty.home}` directory for this demonstration.
|
||||
. The `curl` command downloads the replacement `logging.mod` and puts it into the `${jetty.base}/modules/` directory for use by `mybase` only.
|
||||
. The `start.jar --add-to-start=logging` command performs a number of steps to make the logging module available to the `${jetty.base}`
|
||||
configuration.
|
||||
1. The `--module=logging` command is added to the
|
||||
`${jetty.base}/start.ini` configuration
|
||||
2. Required `${jetty.base}` directories are created:
|
||||
`${jetty.base}/logs` and `${jetty.base}/resources`
|
||||
3. Required configuration files are downloaded (if not present
|
||||
already): `jetty-logging.properties`, and `logging.properties`
|
||||
+
|
||||
The configuration files are put in the `${jetty.base}/resources/`
|
||||
directory.
|
||||
4. Required `java.util.logging` initialization commands are downloaded
|
||||
(if not present already): `jetty-logging.xml`
|
||||
+
|
||||
The xml file is put in the `${jetty.base}/etc/` directory.
|
||||
5. At this point you have your `mybase` configured so that the jetty
|
||||
server itself will log using java.util.logging, using the
|
||||
java.util.logging configuration found in
|
||||
`mybase/resources/logging.properties`
|
||||
.. The `--module=logging` command is added to the `${jetty.base}/start.ini` configuration.
|
||||
.. Required `${jetty.base}` directories are created: `${jetty.base}/logs` and `${jetty.base}/resources`.
|
||||
.. Required configuration files are downloaded (if not present already): `jetty-logging.properties`, and `logging.properties`
|
||||
* The configuration files are put in the `${jetty.base}/resources/` directory.
|
||||
.. Required `java.util.logging` initialization commands are downloaded (if not present already): `jetty-logging.xml`.
|
||||
* The xml file is put in the `${jetty.base}/etc/` directory.
|
||||
|
||||
You can verify the server classpath by using the `start.jar
|
||||
--list-config` command.
|
||||
At this point the Jetty `mybase` is configured so that the Jetty server itself will log using `java.util.logging`, using the `java.util.logging` configuration found in `mybase/resources/logging.properties`.
|
||||
|
||||
In essence, Jetty is now configured to use
|
||||
`org.eclipse.jetty.util.log.JavaUtilLog`, which emit its own logging
|
||||
events to java.util.logging. Making all Jetty + java.util.logging events
|
||||
emitted by the Jetty server go to java.util.logging for routing (to
|
||||
console, file, etc...)
|
||||
The server classpath can be verified by using the `start.jar --list-config` command.
|
||||
|
||||
If you have any custom java.util.logging handlers that you want to use,
|
||||
put the implementation jar in your `${jetty.base}/lib/logging/`
|
||||
directory and reference them in the
|
||||
`${jetty.base}/resources/logging.properties` file.
|
||||
In essence, Jetty is now configured to use `org.eclipse.jetty.util.log.JavaUtilLog`, which emit its own logging events to `java.util.logging`, making all Jetty and `java.util.logging` events emitted by the Jetty server go to `java.util.logging` for routing (to console, file, etc...).
|
||||
|
||||
If there any custom `java.util.logging` handlers to be used, put the implementation jar in the `${jetty.base}/lib/logging/` directory and reference them in the `${jetty.base}/resources/logging.properties` file.
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
`java.util.logging` is configured via the `${jetty.base}/resources/logging.properties` file during a valid startup of Jetty.
|
||||
|
||||
This means that if there is any startup errors that occur before `java.util.logging` is configured, they will likely be lost and/or not routed through your configuration.
|
||||
(Other logging frameworks are more reliable in that they always initialize and configure on first use, unlike java.util.logging)
|
||||
+
|
||||
While it is possible to configure java.util.logging sooner, even at JVM startup, the example demonstrated here does not show this technique.
|
||||
For more information consult the http://docs.oracle.com/javase/7/docs/api/java/util/logging/LogManager.html[official java.util.logging.LogManager javadoc documentation from Oracle].
|
||||
|
||||
Other logging frameworks are more reliable in that they always initialize and configure on first use, unlike `java.util.logging`.
|
||||
|
||||
* While it is possible to configure `java.util.logging` sooner, even at JVM startup, the example demonstrated here does not show this technique.
|
||||
For more information consult the official `java.util.logging.LogManager` javadoc http://docs.oracle.com/javase/7/docs/api/java/util/logging/LogManager.html[documentation from Oracle].
|
||||
____
|
||||
|
|
@ -15,21 +15,16 @@
|
|||
// ========================================================================
|
||||
|
||||
[[example-logging-java-util-logging]]
|
||||
= Example: Logging with Java's java.util.logging via Slf4j
|
||||
=== Example: Logging with Java's java.util.logging via Slf4j
|
||||
|
||||
It is possible to have the Jetty Server logging configured so that
|
||||
`java.util.logging` controls the output of logging events produced by
|
||||
Jetty.
|
||||
It is possible to have the Jetty Server logging configured so that `java.util.logging` controls the output of logging events produced by Jetty.
|
||||
|
||||
This example demonstrates how to configuring Jetty for logging to
|
||||
`java.util.logging` via http://slf4j.org/manual.html[Slf4j] and the
|
||||
http://slf4j.org/manual.html#swapping[Slf4j binding layer for
|
||||
java.util.logging]. If you want to use the built-in native JavaUtilLog
|
||||
implementation, see #example-logging-java-util-logging-native
|
||||
This example demonstrates how to configuring Jetty for logging to `java.util.logging` via http://slf4j.org/manual.html[Slf4j] and the http://slf4j.org/manual.html#swapping[Slf4j binding layer for java.util.logging].
|
||||
If you want to use the built-in native `JavaUtilLog` implementation, see #example-logging-java-util-logging-native .
|
||||
|
||||
A convenient replacement `logging` module has been created to bootstrap
|
||||
your `${jetty.base}` directory for logging with java.util.logging.
|
||||
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
|
||||
|
|
@ -56,57 +51,35 @@ INFO: resources enabled in ${jetty.base}/start.ini
|
|||
|
||||
The replacement `logging.mod` performs a number of tasks.
|
||||
|
||||
1. `mybase` is a `${jetty.base}` directory
|
||||
2. The jetty-distribution is unpacked (and untouched) into
|
||||
`/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this
|
||||
demonstration.
|
||||
3. The `curl` command downloads the replacement `logging.mod` and puts
|
||||
it into the `${jetty.base}/modules/` directory for use by mybase only.
|
||||
4. The `start.jar --add-to-start=logging` command performs a number of
|
||||
steps to make the logging module available to the `${jetty.base}`
|
||||
configuration.
|
||||
1. The `--module=logging` command is added to the
|
||||
`${jetty.base}/start.ini` configuration
|
||||
2. Required `${jetty.base}` directories are created:
|
||||
`${jetty.base}/logs` and `${jetty.base}/resources`
|
||||
3. Required libraries are downloaded (if not present already):
|
||||
slf4j-api, and slf4j-jdk14.
|
||||
+
|
||||
The libraries are put in the `${jetty.base}/lib/logging/` directory.
|
||||
4. Required configuration files are downloaded (if not present
|
||||
already): `jetty-logging.properties`, and `logging.properties`
|
||||
+
|
||||
The configuration files are put in the `${jetty.base}/resources/`
|
||||
directory.
|
||||
5. Required `java.util.logging` initialization commands are downloaded
|
||||
(if not present already): `jetty-logging.xml`
|
||||
+
|
||||
The xml file is put in the `${jetty.base}/etc/` directory.
|
||||
5. At this point you have your `mybase` configured so that the jetty
|
||||
server itself will log using java.util.logging, using the
|
||||
java.util.logging configuration found in
|
||||
`mybase/resources/logging.properties`
|
||||
. `mybase` is a `${jetty.base}` directory
|
||||
. The jetty-distribution is unpacked (and untouched) into `/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this demonstration.
|
||||
. The `curl` command downloads the replacement `logging.mod` and puts it into the `${jetty.base}/modules/` directory for use by `mybase` only.
|
||||
. The `start.jar --add-to-start=logging` command performs a number of steps to make the logging module available to the `${jetty.base}` configuration.
|
||||
.. The `--module=logging` command is added to the `${jetty.base}/start.ini` configuration.
|
||||
.. Required `${jetty.base}` directories are created: `${jetty.base}/logs` and `${jetty.base}/resources`.
|
||||
.. Required libraries are downloaded (if not present already): slf4j-api, and slf4j-jdk14.
|
||||
* The libraries are put in the `${jetty.base}/lib/logging/` directory.
|
||||
.. Required configuration files are downloaded (if not present already): `jetty-logging.properties`, and `logging.properties`.
|
||||
* The configuration files are put in the `${jetty.base}/resources/` directory.
|
||||
.. Required `java.util.logging` initialization commands are downloaded (if not present already): `jetty-logging.xml`.
|
||||
* The xml file is put in the `${jetty.base}/etc/` directory.
|
||||
|
||||
You can verify the server classpath by using the `start.jar
|
||||
--list-config` command.
|
||||
At this point the Jetty `mybase` is configured so that the Jetty server itself will log using `java.util.logging`, using the `java.util.logging` configuration found in `mybase/resources/logging.properties`.
|
||||
|
||||
In essence, Jetty is now configured to emit its own logging events to
|
||||
slf4j, and slf4j itself is using the static log binder found in
|
||||
slf4j-jdk14.jar. Making all Jetty + Slf4j + java.util.logging events
|
||||
emitted by the Jetty server go to java.util.logging for routing (to
|
||||
console, file, etc...)
|
||||
The server classpath can be verified by using the `start.jar --list-config` command.
|
||||
|
||||
If you have any custom java.util.logging handlers that you want to use,
|
||||
put the implementation jar in your `${jetty.base}/lib/logging/`
|
||||
directory and reference them in the
|
||||
`${jetty.base}/resources/logging.properties` file.
|
||||
In essence, Jetty is now configured to emit its own logging events to slf4j, and slf4j itself is using the static log binder found in `slf4j-jdk14.jar`, making all Jetty + Slf4j + `java.util.logging` events emitted by the Jetty server go to `java.util.logging` for routing (to console, file, etc...).
|
||||
|
||||
If there any custom `java.util.logging` handlers to be used, put the implementation jar in the `${jetty.base}/lib/logging/` directory and reference them in the `${jetty.base}/resources/logging.properties` file.
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
`java.util.logging` is configured via the `${jetty.base}/resources/logging.properties` file during a valid startup of Jetty.
|
||||
|
||||
This means that if there is any startup errors that occur before `java.util.logging` is configured, they will likely be lost and/or not routed through your configuration.
|
||||
(Other logging frameworks are more reliable in that they always initialize and configure on first use, unlike java.util.logging)
|
||||
+
|
||||
While it is possible to configure java.util.logging sooner, even at JVM startup, the example demonstrated here does not show this technique.
|
||||
For more information consult the http://docs.oracle.com/javase/7/docs/api/java/util/logging/LogManager.html[official java.util.logging.LogManager javadoc documentation from Oracle].
|
||||
|
||||
Other logging frameworks are more reliable in that they always initialize and configure on first use, unlike `java.util.logging`.
|
||||
|
||||
* While it is possible to configure `java.util.logging` sooner, even at JVM startup, the example demonstrated here does not show this technique.
|
||||
For more information consult the official `java.util.logging.LogManager` javadoc http://docs.oracle.com/javase/7/docs/api/java/util/logging/LogManager.html[documentation from Oracle].
|
||||
____
|
||||
|
|
@ -15,43 +15,27 @@
|
|||
// ========================================================================
|
||||
|
||||
[[example-logging-logback-centralized]]
|
||||
= Example: Centralized Logging with Logback
|
||||
=== Example: Centralized Logging with Logback
|
||||
|
||||
The term _Centralized Logging_ refers to a forced logging configuration
|
||||
for the Jetty Server and all web applications that are deployed on the
|
||||
server. It routes all logging events from the web applications to a
|
||||
single configuration on the Server side.
|
||||
The term _Centralized Logging_ refers to a forced logging configuration for the Jetty Server and all web applications that are deployed on the server.
|
||||
It routes all logging events from the web applications to a single configuration on the Server side.
|
||||
|
||||
The example below shows how to accomplish this with Jetty and Slf4j,
|
||||
using Logback to manage the final writing of logs to disk.
|
||||
The example below shows how to accomplish this with Jetty and Slf4j, using `Logback` to manage the final writing of logs to disk.
|
||||
|
||||
____
|
||||
[IMPORTANT]
|
||||
This mechanism forces all webapps to use the server's configuration for logging, something that isn't 100% appropriate for all webapps.
|
||||
+
|
||||
An example would be having Jenkins-CI deployed as an webapp, if you force its logging configuration to the server side, you lose the ability on http://jenkins-ci.org/[Jenkins-CI] to see the logs from the various builds (as now those logs are actually going to the main server log).
|
||||
____
|
||||
|
||||
This configuration is essentially the multiple logger configuration with
|
||||
added configuration to the deployers to force a WebAppClassLoader change
|
||||
to use the server classpath over the webapps classpath for the logger
|
||||
specific classes.
|
||||
This configuration is essentially the multiple logger configuration with added configuration to the deployers to force a `WebAppClassLoader` change to use the server classpath over the webapps classpath for the logger specific classes.
|
||||
|
||||
The technique used by this configuration is to provide an
|
||||
link:{JDURL}org/eclipse/jetty/deploy/AppLifeCycle.Binding.html[AppLifeCycle.Binding]
|
||||
against the
|
||||
link:{JDURL}/org/eclipse/jetty/deploy/AppLifeCycle.html[`"deploying"`
|
||||
node] that modifies the
|
||||
link:{JDURL}/org/eclipse/jetty/webapp/WebAppContext.html#addSystemClass(java.lang.String)[WebAppContext.addSystemClass(String)]
|
||||
for the common logging classes. (See
|
||||
https://github.com/jetty-project/jetty-webapp-logging/blob/master/src/main/java/org/eclipse/jetty/webapp/logging/CentralizedWebAppLoggingBinding.java[org.eclipse.jetty.logging.CentralizedWebAppLoggingBinding]
|
||||
for actual implementation)
|
||||
The technique used by this configuration is to provide an link:{JDURL}org/eclipse/jetty/deploy/AppLifeCycle.Binding.html[AppLifeCycle.Binding] against the link:{JDURL}/org/eclipse/jetty/deploy/AppLifeCycle.html[`"deploying"`node] that modifies the link:{JDURL}/org/eclipse/jetty/webapp/WebAppContext.html#addSystemClass(java.lang.String)[WebAppContext.addSystemClass(String)] for the common logging classes.
|
||||
See https://github.com/jetty-project/jetty-webapp-logging/blob/master/src/main/java/org/eclipse/jetty/webapp/logging/CentralizedWebAppLoggingBinding.java[org.eclipse.jetty.logging.CentralizedWebAppLoggingBinding] for actual implementation.
|
||||
|
||||
A convenient replacement `logging` module has been created to bootstrap
|
||||
your `${jetty.base}` directory for capturing all Jetty server logging
|
||||
from multiple logging frameworks into a single logging output file
|
||||
managed by logback.
|
||||
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
|
||||
|
|
@ -96,71 +80,30 @@ INFO: resources enabled in ${jetty.base}/start.ini
|
|||
|
||||
The replacement `logging.mod` performs a number of tasks.
|
||||
|
||||
1. `mybase` is a `${jetty.base}` directory
|
||||
2. The jetty-distribution is unpacked (and untouched) into
|
||||
`/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this
|
||||
demonstration.
|
||||
3. The `curl` command downloads the replacement `logging.mod` and puts
|
||||
it into the `${jetty.base}/modules/` directory for use by mybase only.
|
||||
4. The `start.jar
|
||||
--add-to-start=logging,webapp-logging` command performs a number
|
||||
of steps to make the logging module available to the `${jetty.base}`
|
||||
configuration.
|
||||
1. Several entries are added to the `${jetty.base}/start.ini`
|
||||
configuration
|
||||
1. `--module=logging` is added to enable the logging module
|
||||
2. `--module=webapp-logging` is added to enable the webapp-logging
|
||||
module
|
||||
2. Required `${jetty.base}` directories are created:
|
||||
`${jetty.base}/logs` and `${jetty.base}/resources`
|
||||
3. Required logging libraries are downloaded (if not present already):
|
||||
* slf4j-api.jar - API jar for Slf4j (used by most of the rest of the
|
||||
jars)
|
||||
* log4j-over-slf4j.jar - Slf4j jar that captures all log4j emitted
|
||||
logging events
|
||||
* jul-to-slf4j.jar - Slf4j jar that captures all java.util.logging
|
||||
events
|
||||
* jcl-over-slf4j.jar - Slf4j jar that captures all commons-logging
|
||||
events
|
||||
* logback-classic.jar - the Slf4j adapter jar that routes all of the
|
||||
captured logging events to logback itself.
|
||||
* logback-core.jar - the logback implementation jar, that handles all of
|
||||
the filtering and output of the logging events.
|
||||
+
|
||||
These libraries are put in the `${jetty.base}/lib/logging/` directory.
|
||||
4. Required webapp-logging library are downloaded (if not present
|
||||
already):
|
||||
* jetty-webapp-logging.jar - the jetty side deployment manger
|
||||
app-lifecycle bindings for modifying the WebAppClassloaders of deployed
|
||||
webapps.
|
||||
+
|
||||
This library is put in the `${jetty.base}/lib/webapp-logging/`
|
||||
directory.
|
||||
5. Required configuration files are downloaded (if not present
|
||||
already): `jetty-logging.properties`, and `logback.xml`
|
||||
+
|
||||
The configuration files are put in the `${jetty.base}/resources/`
|
||||
directory.
|
||||
6. Required initialization commands are downloaded (if not present
|
||||
already): `jetty-logging.xml`, `jetty-webapp-logging.xml`, and
|
||||
`jetty-mdc-handler.xml`
|
||||
+
|
||||
These xml files are put in the `${jetty.base}/etc/` directory.
|
||||
5. At this point you have your `mybase` configured so that the jetty
|
||||
server itself will log using slf4j, and all other logging events from
|
||||
other Jetty Server components (such as database drivers, security
|
||||
layers, jsp, mail, and other 3rd party server components) are routed to
|
||||
logback for filtering and output.
|
||||
+
|
||||
All webapps deployed via the DeploymentManager have their
|
||||
WebAppClassLoader modified to use server side classes and configuration
|
||||
for all logging implementations.
|
||||
. `mybase` is a `${jetty.base}` directory.
|
||||
. The jetty-distribution is unpacked (and untouched) into `/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this demonstration.
|
||||
. The `curl` command downloads the replacement `logging.mod` and puts it into the `${jetty.base}/modules/` directory for use by mybase only.
|
||||
. The `start.jar --add-to-start=logging,webapp-logging` command performs a number of steps to make the logging module available to the `${jetty.base}` configuration.
|
||||
.. Several entries are added to the `${jetty.base}/start.ini` configuration.
|
||||
* `--module=logging` is added to enable the logging module.
|
||||
* `--module=webapp-logging` is added to enable the webapp-logging module.
|
||||
.. Required `${jetty.base}` directories are created: `${jetty.base}/logs` and `${jetty.base}/resources`.
|
||||
.. Required logging libraries are downloaded (if not present already) to the `${jetty.base}/lib/logging/` directory:
|
||||
* `slf4j-api.jar` - API jar for Slf4j (used by most of the rest of the jars)
|
||||
* `log4j-over-slf4j.jar` - Slf4j jar that captures all log4j emitted logging events
|
||||
* `jul-to-slf4j.jar` - Slf4j jar that captures all java.util.logging events
|
||||
* `jcl-over-slf4j.jar` - Slf4j jar that captures all commons-logging events
|
||||
* `logback-classic.jar` - the Slf4j adapter jar that routes all of the captured logging events to logback itself.
|
||||
* `logback-core.jar` - the logback implementation jar, that handles all of the filtering and output of the logging events.
|
||||
.. Required webapp-logging library is downloaded (if not present already) to the `${jetty.base}/lib/webapp-logging/` directory:
|
||||
* `jetty-webapp-logging.jar` - the Jetty side deployment manger app-lifecycle bindings for modifying the `WebAppClassloaders` of deployed webapps.
|
||||
.. Required configuration files are downloaded (if not present already) to the `${jetty.base}/resources/` directory: `jetty-logging.properties`, and `logback.xml`.
|
||||
.. Required initialization commands are downloaded (if not present already) to the `${jetty.base}/etc/` directory: `jetty-logging.xml`, `jetty-webapp-logging.xml`, and `jetty-mdc-handler.xml`.
|
||||
|
||||
You can verify the server classpath by using the `start.jar
|
||||
--list-config` command.
|
||||
At this point the Jetty `mybase` is configured so that the jetty server itself will log using slf4j, and all other logging events from other Jetty Server components (such as database drivers, security layers, jsp, mail, and other 3rd party server components) are routed to logback for filtering and output.
|
||||
|
||||
In essence, Jetty is now configured to emit its own logging events to
|
||||
slf4j, and various slf4j bridge jars are acting on behalf of log4j,
|
||||
java.util.logging, and commons-logging, routing all of the logging
|
||||
events to logback (a slf4j adapter) for routing (to console, file,
|
||||
etc...)
|
||||
All webapps deployed via the `DeploymentManager` have their `WebAppClassLoader` modified to use server side classes and configuration for all logging implementations.
|
||||
|
||||
The server classpath can be verified by using the `start.jar --list-config` command.
|
||||
|
||||
In essence, Jetty is now configured to emit its own logging events to slf4j, and various slf4j bridge jars are acting on behalf of log4j, `java.util.logging`, and `commons-logging`, routing all of the logging events to logback (a slf4j adapter) for routing (to console, file, etc...).
|
||||
|
|
|
|||
|
|
@ -15,12 +15,11 @@
|
|||
// ========================================================================
|
||||
|
||||
[[example-logging-logback-sifting]]
|
||||
= Example: MDC Based Sifting of Logs with Logback
|
||||
=== Example: MDC Based Sifting of Logs with Logback
|
||||
|
||||
This page describes how to create log files at the server level and name
|
||||
them based on an arbitrary context. You do this with SLF4J + Logback +
|
||||
Jetty Webapp Logging in the mix. Find example projects for this feature
|
||||
at github:
|
||||
This page describes how to create log files at the server level and name them based on an arbitrary context.
|
||||
This can be done with SLF4J + Logback + Jetty Webapp Logging in the mix.
|
||||
Find example projects for this feature at github:
|
||||
|
||||
....
|
||||
https://github.com/jetty-project/jetty-and-logback-example
|
||||
|
|
@ -30,19 +29,11 @@ https://github.com/jetty-project/jetty-and-logback-example
|
|||
[cols=",",options="header",]
|
||||
|=======================================================================
|
||||
|Modules |Description
|
||||
|/jetty-distro-with-logback-basic/ |Configures the jetty distribution
|
||||
with logback enabled at the server level with an example logback
|
||||
configuration.
|
||||
|/jetty-distro-with-logback-basic/ |Configures the jetty distribution with logback enabled at the server level with an example logback configuration.
|
||||
|
||||
|/jetty-distro-with-logback-sifting/ |Configures the jetty distribution
|
||||
with logback, centralized webapp logging, an MDC handler, and a sample
|
||||
logback configuration that performs sifting based on the incoming Host
|
||||
header on the requests.
|
||||
|/jetty-distro-with-logback-sifting/ |Configures the jetty distribution with logback, centralized webapp logging, an MDC handler, and a sample logback configuration that performs sifting based on the incoming Host header on the requests.
|
||||
|
||||
|/jetty-slf4j-mdc-handler/ |Provides the SLF4J MDC key/value pairs that
|
||||
Jetty needs to perform the sample sifting.
|
||||
|/jetty-slf4j-mdc-handler/ |Provides the SLF4J MDC key/value pairs that Jetty needs to perform the sample sifting.
|
||||
|
||||
|/jetty-slf4j-test-webapp/ |A sample webapp+servlet that accepts
|
||||
arbitrary values on a form POST and logs them via SLF4J, so that you can
|
||||
see the results of this example.
|
||||
|/jetty-slf4j-test-webapp/ |A sample webapp+servlet that accepts arbitrary values on a form POST and logs them via SLF4J, so that you can see the results of this example.
|
||||
|=======================================================================
|
||||
|
|
|
|||
|
|
@ -15,17 +15,14 @@
|
|||
// ========================================================================
|
||||
|
||||
[[example-logging-logback]]
|
||||
= Example: Logging with Logback
|
||||
=== Example: Logging with Logback
|
||||
|
||||
It is possible to have the Jetty Server logging configured so that
|
||||
Logback controls the output of logging events produced by Jetty. This is
|
||||
accomplished by configuring Jetty for logging to `Logback`, which uses
|
||||
http://slf4j.org/manual.html[Slf4j] and the
|
||||
http://logback.qos.ch/[Logback Implementation for Slf4j].
|
||||
It is possible to have the Jetty Server logging configured so that Logback controls the output of logging events produced by Jetty.
|
||||
This is accomplished by configuring Jetty for logging to `Logback`, which uses http://slf4j.org/manual.html[Slf4j] and the http://logback.qos.ch/[Logback Implementation for Slf4j].
|
||||
|
||||
A convenient replacement `logging` module has been created to bootstrap
|
||||
your `${jetty.base}` directory for logging with logback.
|
||||
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
|
||||
|
|
@ -50,37 +47,17 @@ DOWNLOAD: https://raw.githubusercontent.com/jetty-project/logging-modules/master
|
|||
|
||||
The replacement `logging.mod` performs a number of tasks.
|
||||
|
||||
1. `mybase` is a `${jetty.base}` directory
|
||||
2. The jetty-distribution is unpacked (and untouched) into
|
||||
`/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this
|
||||
demonstration.
|
||||
3. The `curl` command downloads the replacement `logging.mod` and puts
|
||||
it into the `${jetty.base}/modules/` directory for use by mybase only.
|
||||
4. The `start.jar --add-to-start=logging` command performs a number of
|
||||
steps to make the logging module available to the `${jetty.base}`
|
||||
configuration.
|
||||
1. The `--module=logging` command is added to the
|
||||
`${jetty.base}/start.ini` configuration
|
||||
2. Required `${jetty.base}` directories are created:
|
||||
`${jetty.base}/logs` and `${jetty.base}/resources`
|
||||
3. Required libraries are downloaded (if not present already):
|
||||
slf4j-api, logback-core, and logback-classic.
|
||||
+
|
||||
The libraries are put in the `${jetty.base}/lib/logging/` directory.
|
||||
4. Required configuration files are downloaded (if not present
|
||||
already): `jetty-logging.properties`, and `logback.xml`
|
||||
+
|
||||
The configuration files are put in the `${jetty.base}/resources/`
|
||||
directory.
|
||||
5. At this point you have your `mybase` configured so that the jetty
|
||||
server itself will log using logback, using the logback configuration
|
||||
found in `mybase/resources/logback.xml`
|
||||
. `mybase` is a `${jetty.base}` directory.
|
||||
. The jetty-distribution is unpacked (and untouched) into `/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this demonstration.
|
||||
. The `curl` command downloads the replacement `logging.mod` and puts it into the `${jetty.base}/modules/` directory for use by `mybase` only.
|
||||
. The `start.jar --add-to-start=logging` command performs a number of steps to make the logging module available to the `${jetty.base}` configuration.
|
||||
.. The `--module=logging` command is added to the `${jetty.base}/start.ini` configuration.
|
||||
.. Required `${jetty.base}` directories are created: `${jetty.base}/logs` and `${jetty.base}/resources`.
|
||||
.. Required libraries are downloaded (if not present already) to the `${jetty.base}/lib/logging/` directory: slf4j-api, logback-core, and logback-classic.
|
||||
.. Required configuration files are downloaded (if not present already) to the `${jetty.base}/lib/resources/` directory.: `jetty-logging.properties`, and `logback.xml`.
|
||||
|
||||
You can verify the server classpath by using the `start.jar
|
||||
--list-config` command.
|
||||
At this point the Jetty `mybase` is configured so that the Jetty server itself will log using Logback, using the Logback configuration found in `mybase/resources/logback.xml`
|
||||
|
||||
In essence, Jetty is now configured to emit its own logging events to
|
||||
slf4j, and slf4j itself is using the static log binder found in
|
||||
logback-classic.jar. Making all Jetty + Slf4j + Logback events emitted
|
||||
by the Jetty server go to Logback for routing (to console, file, syslog,
|
||||
etc...)
|
||||
The server classpath can be verified by using the `start.jar --list-config` command.
|
||||
|
||||
In essence, Jetty is now configured to emit its own logging events to slf4j, and slf4j itself is using the static log binder found in logback-classic.jar, making all Jetty + Slf4j + Logback events emitted by the Jetty server go to Logback for routing (to console, file, syslog, etc...).
|
||||
|
|
|
|||
|
|
@ -15,17 +15,11 @@
|
|||
// ========================================================================
|
||||
|
||||
[[example-slf4j-multiple-loggers]]
|
||||
= Example: Capturing Multiple Logging Frameworks with Slf4j
|
||||
=== Example: Capturing Multiple Logging Frameworks with Slf4j
|
||||
|
||||
This page describes how to configure Jetty for capturing multiple
|
||||
logging frameworks logging events into a single logging implementation
|
||||
handled by Slf4j.
|
||||
This page describes how to configure Jetty for capturing multiple logging frameworks logging events into a single logging implementation handled by Slf4j.
|
||||
|
||||
When using Slf4j, you can configure a single logging solution for the
|
||||
variety of logging libraries available in common use. With careful
|
||||
setup, you can support all of the following logging APIs at the same
|
||||
time, with a single configuration file to control the output of events
|
||||
produces by these APIs.
|
||||
A single logging solution can be configured for the variety of logging libraries available in common use when using Slf4j. With careful setup, all of the following logging APIs can be supported at the same time, with a single configuration file to control the output of events produced.
|
||||
|
||||
Logging APIs that Slf4j supports:
|
||||
|
||||
|
|
@ -35,15 +29,27 @@ Logging APIs that Slf4j supports:
|
|||
* JDK 1.4 Logging (aka `java.util.logging`)
|
||||
* Apache Commons Logging
|
||||
|
||||
To accomplish this you must make some careful choices, starting with a
|
||||
single underlying logging framework. This decision guides the rest of
|
||||
your choices about JARs to place on the Server classpath.
|
||||
To accomplish this configuration a single underlying logging framework should first be chosen.
|
||||
This decision guides the rest of the choices about jar files to place on the server classpath.
|
||||
|
||||
____
|
||||
[CAUTION]
|
||||
There MUST NOT be multiple underlying logging frameworks on the classpath.
|
||||
If there are, the Slf4j framework fails to load.
|
||||
____
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
Some third party libraries provide their own implementations of common logging APIs; be careful not to accidentally include an underlying logging framework.
|
||||
For example, if you are using SpringSource you likely have a `com.springsource.org.apache.log4j.jar` along with a `log4j.jar`, which have the same classes in them.
|
||||
In this example, use the `com.springsource.org.apache.log4j.jar` version and exclude the `log4j.jar`, as the SpringSource version includes extra metadata suitable for using SpringSource.
|
||||
____
|
||||
|
||||
.Slf4j Logging Grid
|
||||
[width="100%",cols="25%,25%,25%,25%",options="header",]
|
||||
|=======================================================================
|
||||
|Logging API |Slf4j Binding Jar |Slf4j Adapter Jar |Underlying Logging
|
||||
Framework
|
||||
|Logging API |Slf4j Binding Jar |Slf4j Adapter Jar |Underlying Logging Framework
|
||||
|
||||
|Logback API |n/a |logback-classic.jar |logback-core.jar
|
||||
|
||||
|Log4j
|
||||
|
|
@ -60,63 +66,27 @@ Framework
|
|||
|=======================================================================
|
||||
|
||||
Logging API::
|
||||
The Logging API that you are either capturing events from and/or using
|
||||
to write out those events (for example, to disk).
|
||||
* The Logging API that you are either capturing events from and/or using to write out those events (for example, to disk).
|
||||
Slf4j Binding JAR::
|
||||
Special JARs, created and maintained by the Slf4j project, that
|
||||
pretend to be the various Logging API implementation classes, but
|
||||
instead just route that Logging API's events to Slf4j to handle.
|
||||
+
|
||||
There MAY be multiple Slf4j binding JARs present on the classpath at
|
||||
the same time.
|
||||
+
|
||||
For a single logging API, if you choose to use the Slf4j binding JAR,
|
||||
then you MUST NOT include the SLf4j adapter JAR or underlying logging
|
||||
framework in the classpath as well.
|
||||
* Special JARs, created and maintained by the Slf4j project, that pretend to be the various Logging API implementation classes, but instead just route that Logging API's events to Slf4j to handle.
|
||||
* There MAY be multiple Slf4j binding JARs present on the classpath at the same time.
|
||||
|
||||
* For a single logging API, if you choose to use the Slf4j binding JAR, then you MUST NOT include the SLf4j adapter JAR or underlying logging framework in the classpath as well.
|
||||
Slf4j Adapter Jar::
|
||||
These JARs are created and maintained by the Slf4j project and route
|
||||
Slf4j logging events to a specific underlying logging framework.
|
||||
+
|
||||
There MUST NOT be multiple Slf4j adapter JARs present on the classpath
|
||||
at the same time.
|
||||
+
|
||||
Logging events that these adapter JARs capture can come from direct
|
||||
use of the Slf4j API or via one of the Slf4j binding JAR
|
||||
implementations.
|
||||
* These JARs are created and maintained by the Slf4j project and route Slf4j logging events to a specific underlying logging framework.
|
||||
* There MUST NOT be multiple Slf4j adapter JARs present on the classpath at the same time.
|
||||
* Logging events that these adapter JARs capture can come from direct use of the Slf4j API or via one of the Slf4j binding JAR implementations.
|
||||
Underlying Logging Framework::
|
||||
This is the last leg of your configuration, the implementation that
|
||||
processes, filters, and outputs the logging events to the console,
|
||||
logging directory on disk, or whatever else the underlying logging
|
||||
framework supports (like Socket, SMTP, Database, or even SysLog in the
|
||||
case of Logback).
|
||||
+
|
||||
____
|
||||
[CAUTION]
|
||||
There MUST NOT be multiple underlying logging frameworks on the classpath.
|
||||
If there are, the Slf4j framework fails to load.
|
||||
____
|
||||
+
|
||||
____
|
||||
[NOTE]
|
||||
Some third party libraries provide their own implementations of common logging APIs; be careful not to accidentally include an underlying logging framework.
|
||||
+
|
||||
For example, if you are using SpringSource you likely have a `com.springsource.org.apache.log4j.jar` along with a `log4j.jar`, which have the same classes in them.
|
||||
In this example, use the `com.springsource.org.apache.log4j.jar` version and exclude the `log4j.jar`, as the SpringSource version includes extra metadata suitable for using SpringSource.
|
||||
____
|
||||
* This is the last leg of the configuration, the implementation that processes, filters, and outputs the logging events to the console, logging directory on disk, or whatever else the underlying logging framework supports (like Socket, SMTP, Database, or even SysLog in the case of Logback).
|
||||
|
||||
The following sections use Logback as the underlying Logging framework.
|
||||
This requires using `logback-classic.jar` and `logback-core.jar`, and
|
||||
excluding any other Slf4j adapter JAR or underlying logging framework.
|
||||
This requires using `logback-classic.jar` and `logback-core.jar`, and excluding any other Slf4j adapter JAR or underlying logging framework.
|
||||
|
||||
It also requires including the other Slf4j binding JARs in the
|
||||
classpath, along with some special initialization for
|
||||
`java.util.logging`.
|
||||
It also requires including the other Slf4j binding JARs in the classpath, along with some special initialization for `java.util.logging`.
|
||||
|
||||
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.
|
||||
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
|
||||
|
|
@ -147,54 +117,24 @@ INFO: resources enabled in ${jetty.base}/start.ini
|
|||
|
||||
The replacement `logging.mod` performs a number of tasks.
|
||||
|
||||
1. `mybase` is a `${jetty.base}` directory
|
||||
2. The jetty-distribution is unpacked (and untouched) into
|
||||
`/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this
|
||||
demonstration.
|
||||
3. The `curl` command downloads the replacement `logging.mod` and puts
|
||||
it into the `${jetty.base}/modules/` directory for use by mybase only.
|
||||
4. The `start.jar --add-to-start=logging` command performs a number of
|
||||
steps to make the logging module available to the `${jetty.base}`
|
||||
configuration.
|
||||
1. The `--module=logging` command is added to the
|
||||
`${jetty.base}/start.ini` configuration
|
||||
2. Required `${jetty.base}` directories are created:
|
||||
`${jetty.base}/logs` and `${jetty.base}/resources`
|
||||
3. Required libraries are downloaded (if not present already):
|
||||
* slf4j-api.jar - API jar for Slf4j (used by most of the rest of the
|
||||
jars)
|
||||
* log4j-over-slf4j.jar - Slf4j jar that captures all log4j emitted
|
||||
logging events
|
||||
* jul-to-slf4j.jar - Slf4j jar that captures all java.util.logging
|
||||
events
|
||||
* jcl-over-slf4j.jar - Slf4j jar that captures all commons-logging
|
||||
events
|
||||
* logback-classic.jar - the Slf4j adapter jar that routes all of the
|
||||
captured logging events to logback itself.
|
||||
* logback-core.jar - the logback implementation jar, that handles all of
|
||||
the filtering and output of the logging events.
|
||||
+
|
||||
These libraries are put in the `${jetty.base}/lib/logging/` directory.
|
||||
4. Required configuration files are downloaded (if not present
|
||||
already): `jetty-logging.properties`, and `logback.xml`
|
||||
+
|
||||
The configuration files are put in the `${jetty.base}/resources/`
|
||||
directory.
|
||||
5. Required `java.util.logging` initialization commands are downloaded
|
||||
(if not present already): `jetty-logging.xml`
|
||||
+
|
||||
The xml file is put in the `${jetty.base}/etc/` directory.
|
||||
5. At this point you have your `mybase` configured so that the jetty
|
||||
server itself will log using slf4j, and all other logging events from
|
||||
other Jetty Server components (such as database drivers, security
|
||||
layers, jsp, mail, and other 3rd party server components) are routed to
|
||||
logback for filtering and output.
|
||||
. `mybase` is a `${jetty.base}` directory.
|
||||
. The jetty-distribution is unpacked (and untouched) into `/opt/jetty-dist/ `and becomes the `${jetty.home}` directory for this demonstration.
|
||||
. The `curl` command downloads the replacement `logging.mod` and puts it into the `${jetty.base}/modules/` directory for use by `mybase` only.
|
||||
. The `start.jar --add-to-start=logging` command performs a number of steps to make the logging module available to the `${jetty.base}` configuration.
|
||||
.. The `--module=logging` command is added to the `${jetty.base}/start.ini` configuration.
|
||||
.. Required `${jetty.base}` directories are created: `${jetty.base}/logs` and `${jetty.base}/resources`.
|
||||
.. Required libraries are downloaded (if not present already) to the the `${jetty.base}/lib/logging/` directory:
|
||||
* `slf4j-api.jar` - API jar for Slf4j (used by most of the rest of the jars)
|
||||
* `log4j-over-slf4j.jar` - Slf4j jar that captures all log4j emitted logging events
|
||||
* `jul-to-slf4j.jar` - Slf4j jar that captures all `java.util.logging` events
|
||||
* `jcl-over-slf4j.jar` - Slf4j jar that captures all `commons-logging` events
|
||||
* `logback-classic.jar` - the Slf4j adapter jar that routes all of the captured logging events to logback itself.
|
||||
* `logback-core.jar` - the logback implementation jar, that handles all of the filtering and output of the logging events.
|
||||
.. Required configuration files are downloaded (if not present already) to the `${jetty.base}/resources/` directory: `jetty-logging.properties`, and `logback.xml`
|
||||
.. Required `java.util.logging` initialization commands are downloaded (if not present already) to the `${jetty.base}/etc/` directory: `jetty-logging.xml`
|
||||
|
||||
You can verify the server classpath by using the `start.jar
|
||||
--list-config` command.
|
||||
At this point the Jetty `mybase` is configured so that the jetty server itself will log using slf4j, and all other logging events from other Jetty server components (such as database drivers, security layers, jsp, mail, and other 3rd party server components) are routed to logback for filtering and output.
|
||||
|
||||
In essence, Jetty is now configured to emit its own logging events to
|
||||
slf4j, and various slf4j bridge jars are acting on behalf of log4j,
|
||||
java.util.logging, and commons-logging, routing all of the logging
|
||||
events to logback (a slf4j adapter) for routing (to console, file,
|
||||
etc...)
|
||||
The server classpath can be verified by using the `start.jar --list-config` command.
|
||||
|
||||
In essence, Jetty is now configured to emit its own logging events to slf4j, and various slf4j bridge jars are acting on behalf of log4j, `java.util.logging`, and `commons-logging`, routing all of the logging events to logback (a Slf4j adapter) for routing (to console, file, etc...).
|
||||
|
|
|
|||
|
|
@ -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
|
||||
....
|
||||
|
|
|
|||
|
|
@ -20,10 +20,10 @@
|
|||
==== Maven Coordinates
|
||||
|
||||
Jetty has existed in Maven Central almost since its inception, however under a couple of different coordinates over the years.
|
||||
When Jetty was based at SourceForge and then The Codehaus it was located under the groupId of `org.mortbay.jetty`.
|
||||
When Jetty was based at SourceForge and then The Codehaus it was located under the `groupId` of `org.mortbay.jetty`.
|
||||
With Jetty 7 the project moved to the Eclipse foundation and to a new `groupId` at that time to reflect its new home.
|
||||
|
||||
The top level POM for the Jetty project is located under the following coordinates.
|
||||
The top level Project Object Model (POM) for the Jetty project is located under the following coordinates.
|
||||
|
||||
[source,xml]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -19,6 +19,7 @@
|
|||
|
||||
To start Jetty on the default port of 8080, run the following command:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> cd $JETTY_HOME
|
||||
> java -jar start.jar
|
||||
|
|
@ -40,6 +41,7 @@ Instead, see how to link:#creating-jetty-base[create a Jetty Base] below.
|
|||
|
||||
Within the standard jetty distribution there is the `demo-base` directory, which demonstrates the recommended way to run Jetty in a directory separately from $JETTY_HOME:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> cd $JETTY_HOME/demo-base/
|
||||
> java -jar $JETTY_HOME/start.jar
|
||||
|
|
@ -75,6 +77,7 @@ ____
|
|||
|
||||
You can see the configuration of the demo-base by using the following commands:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> cd $JETTY_HOME/demo-base/
|
||||
> java -jar $JETTY_HOME/start.jar --list-modules
|
||||
|
|
@ -97,6 +100,7 @@ jetty.base::
|
|||
|
||||
The `jetty.home` and `jetty.base` properties may be explicitly set on the command line, or they can be inferred from the environment if used with commands like:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> cd $JETTY_BASE
|
||||
> java -jar $JETTY_HOME/start.jar
|
||||
|
|
@ -104,6 +108,7 @@ The `jetty.home` and `jetty.base` properties may be explicitly set on the comman
|
|||
|
||||
The following commands: create a new base directory; enables a HTTP connector and the web application deployer; copies a demo webapp to be deployed:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> JETTY_BASE=/tmp/mybase
|
||||
> mkdir $JETTY_BASE
|
||||
|
|
@ -140,6 +145,7 @@ INFO: Base directory was modified
|
|||
|
||||
You can configure Jetty to run on a different port by setting the `jetty.http.port` Property on the command line:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> cd $JETTY_BASE
|
||||
> java -jar $JETTY_HOME/start.jar jetty.http.port=8081
|
||||
|
|
@ -151,13 +157,15 @@ By default, the jetty distribution defines the jetty.http.port property in the `
|
|||
|
||||
____
|
||||
[NOTE]
|
||||
--
|
||||
The configuration by properties works via the following chain:
|
||||
+
|
||||
|
||||
* The start.d/http.ini file is part of the effective command line and contains the --module=http argument which activates the http module.
|
||||
* The modules/http.mod file defines the http module which specifies the etc/jetty-http.xml configuration file and the template ini properties it uses.
|
||||
* The jetty.http.port property is used by the Property XML element in etc/jetty.http.xml to inject the ServerConnector instance with the port.
|
||||
+
|
||||
|
||||
For more information see the link:#quickstart-config[Quickstart Configuration Guide] and link:#configuring-connectors[Configuring Connectors].
|
||||
--
|
||||
____
|
||||
|
||||
[[quickstart-starting-https]]
|
||||
|
|
@ -165,6 +173,7 @@ ____
|
|||
|
||||
To add the HTTPS connector to a jetty configuration, the https module can be activated by the following command:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar $JETTY_HOME/start.jar --add-to-startd=https,http2
|
||||
[...]
|
||||
|
|
@ -192,6 +201,7 @@ ____
|
|||
|
||||
You can configure the SSL connector to run on a different port by setting the `jetty.ssl.port` property on the command line:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> cd $JETTY_BASE
|
||||
> java -jar $JETTY_HOME/start.jar jetty.ssl.port=8444
|
||||
|
|
@ -206,6 +216,7 @@ If you used --add-to-start command, then you can edit this property in the start
|
|||
The job of the `start.jar` is to interpret the command line, `start.ini` and `start.d` to build a Java classpath and list of properties and configuration files to pass to the main class of the Jetty XML configuration mechanism.
|
||||
The `start.jar` mechanism has many options which are documented in the xref:startup[] administration section and you can see them in summary by using the command:
|
||||
|
||||
[source, screen]
|
||||
....
|
||||
> java -jar $JETTY_HOME/start.jar --help
|
||||
....
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,152 @@
|
|||
/*
|
||||
|
||||
Darkula color scheme from the JetBrains family of IDEs
|
||||
|
||||
*/
|
||||
|
||||
|
||||
.hljs {
|
||||
display: block;
|
||||
overflow-x: auto;
|
||||
padding: 0.5em;
|
||||
background: #2b2b2b;
|
||||
-webkit-text-size-adjust: none;
|
||||
}
|
||||
|
||||
.hljs,
|
||||
.hljs-tag,
|
||||
.hljs-title,
|
||||
.css .hljs-rule,
|
||||
.css .hljs-value,
|
||||
.aspectj .hljs-function,
|
||||
.css .hljs-function .hljs-preprocessor,
|
||||
.hljs-pragma {
|
||||
color: #bababa;
|
||||
}
|
||||
|
||||
.hljs-strongemphasis,
|
||||
.hljs-strong,
|
||||
.hljs-emphasis {
|
||||
color: #a8a8a2;
|
||||
}
|
||||
|
||||
.hljs-bullet,
|
||||
.hljs-blockquote,
|
||||
.hljs-horizontal_rule,
|
||||
.hljs-number,
|
||||
.hljs-regexp,
|
||||
.alias .hljs-keyword,
|
||||
.hljs-literal,
|
||||
.hljs-hexcolor {
|
||||
color: #6896ba;
|
||||
}
|
||||
|
||||
.hljs-tag .hljs-value,
|
||||
.hljs-code,
|
||||
.css .hljs-class,
|
||||
.hljs-class .hljs-title:last-child {
|
||||
color: #a6e22e;
|
||||
}
|
||||
|
||||
.hljs-link_url {
|
||||
font-size: 80%;
|
||||
}
|
||||
|
||||
.hljs-emphasis,
|
||||
.hljs-strongemphasis,
|
||||
.hljs-class .hljs-title:last-child,
|
||||
.hljs-typename {
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
.hljs-keyword,
|
||||
.ruby .hljs-class .hljs-keyword:first-child,
|
||||
.ruby .hljs-function .hljs-keyword,
|
||||
.hljs-function,
|
||||
.hljs-change,
|
||||
.hljs-winutils,
|
||||
.hljs-flow,
|
||||
.nginx .hljs-title,
|
||||
.tex .hljs-special,
|
||||
.hljs-header,
|
||||
.hljs-attribute,
|
||||
.hljs-symbol,
|
||||
.hljs-symbol .hljs-string,
|
||||
.hljs-tag .hljs-title,
|
||||
.hljs-value,
|
||||
.alias .hljs-keyword:first-child,
|
||||
.css .hljs-tag,
|
||||
.css .unit,
|
||||
.css .hljs-important {
|
||||
color: #cb7832;
|
||||
}
|
||||
|
||||
.hljs-function .hljs-keyword,
|
||||
.hljs-class .hljs-keyword:first-child,
|
||||
.hljs-aspect .hljs-keyword:first-child,
|
||||
.hljs-constant,
|
||||
.hljs-typename,
|
||||
.css .hljs-attribute {
|
||||
color: #cb7832;
|
||||
}
|
||||
|
||||
.hljs-variable,
|
||||
.hljs-params,
|
||||
.hljs-class .hljs-title,
|
||||
.hljs-aspect .hljs-title {
|
||||
color: #b9b9b9;
|
||||
}
|
||||
|
||||
.hljs-string,
|
||||
.css .hljs-id,
|
||||
.hljs-subst,
|
||||
.hljs-type,
|
||||
.ruby .hljs-class .hljs-parent,
|
||||
.hljs-built_in,
|
||||
.django .hljs-template_tag,
|
||||
.django .hljs-variable,
|
||||
.smalltalk .hljs-class,
|
||||
.django .hljs-filter .hljs-argument,
|
||||
.smalltalk .hljs-localvars,
|
||||
.smalltalk .hljs-array,
|
||||
.hljs-attr_selector,
|
||||
.hljs-pseudo,
|
||||
.hljs-addition,
|
||||
.hljs-stream,
|
||||
.hljs-envvar,
|
||||
.apache .hljs-tag,
|
||||
.apache .hljs-cbracket,
|
||||
.tex .hljs-command,
|
||||
.hljs-prompt,
|
||||
.hljs-link_label,
|
||||
.hljs-link_url,
|
||||
.hljs-name {
|
||||
color: #e0c46c;
|
||||
}
|
||||
|
||||
.hljs-comment,
|
||||
.hljs-annotation,
|
||||
.hljs-pi,
|
||||
.hljs-doctype,
|
||||
.hljs-deletion,
|
||||
.hljs-shebang,
|
||||
.apache .hljs-sqbracket,
|
||||
.tex .hljs-formula {
|
||||
color: #7f7f7f;
|
||||
}
|
||||
|
||||
.hljs-decorator {
|
||||
color: #bab429;
|
||||
}
|
||||
|
||||
.coffeescript .javascript,
|
||||
.javascript .xml,
|
||||
.tex .hljs-formula,
|
||||
.xml .javascript,
|
||||
.xml .vbscript,
|
||||
.xml .css,
|
||||
.xml .hljs-cdata,
|
||||
.xml .php,
|
||||
.php .xml {
|
||||
opacity: 0.5;
|
||||
}
|
||||
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;
|
||||
}
|
||||
|
|
@ -0,0 +1,118 @@
|
|||
/*
|
||||
|
||||
Zenburn style from voldmar.ru (c) Vladimir Epifanov <voldmar@voldmar.ru>
|
||||
based on dark.css by Ivan Sagalaev
|
||||
|
||||
*/
|
||||
|
||||
.hljs {
|
||||
display: block;
|
||||
overflow-x: auto;
|
||||
padding: 0.5em;
|
||||
background: #3f3f3f;
|
||||
color: #dcdcdc;
|
||||
-webkit-text-size-adjust: none;
|
||||
}
|
||||
|
||||
.hljs-keyword,
|
||||
.hljs-tag,
|
||||
.css .hljs-class,
|
||||
.css .hljs-id,
|
||||
.lisp .hljs-title,
|
||||
.nginx .hljs-title,
|
||||
.hljs-request,
|
||||
.hljs-status,
|
||||
.clojure .hljs-attribute {
|
||||
color: #e3ceab;
|
||||
}
|
||||
|
||||
.django .hljs-template_tag,
|
||||
.django .hljs-variable,
|
||||
.django .hljs-filter .hljs-argument {
|
||||
color: #dcdcdc;
|
||||
}
|
||||
|
||||
.hljs-number,
|
||||
.hljs-date {
|
||||
color: #8cd0d3;
|
||||
}
|
||||
|
||||
.dos .hljs-envvar,
|
||||
.dos .hljs-stream,
|
||||
.hljs-variable,
|
||||
.apache .hljs-sqbracket,
|
||||
.hljs-name {
|
||||
color: #efdcbc;
|
||||
}
|
||||
|
||||
.dos .hljs-flow,
|
||||
.diff .hljs-change,
|
||||
.python .exception,
|
||||
.python .hljs-built_in,
|
||||
.hljs-literal,
|
||||
.tex .hljs-special {
|
||||
color: #efefaf;
|
||||
}
|
||||
|
||||
.diff .hljs-chunk,
|
||||
.hljs-subst {
|
||||
color: #8f8f8f;
|
||||
}
|
||||
|
||||
.dos .hljs-keyword,
|
||||
.hljs-decorator,
|
||||
.hljs-title,
|
||||
.hljs-type,
|
||||
.diff .hljs-header,
|
||||
.ruby .hljs-class .hljs-parent,
|
||||
.apache .hljs-tag,
|
||||
.nginx .hljs-built_in,
|
||||
.tex .hljs-command,
|
||||
.hljs-prompt {
|
||||
color: #efef8f;
|
||||
}
|
||||
|
||||
.dos .hljs-winutils,
|
||||
.ruby .hljs-symbol,
|
||||
.ruby .hljs-symbol .hljs-string,
|
||||
.ruby .hljs-string {
|
||||
color: #dca3a3;
|
||||
}
|
||||
|
||||
.diff .hljs-deletion,
|
||||
.hljs-string,
|
||||
.hljs-tag .hljs-value,
|
||||
.hljs-preprocessor,
|
||||
.hljs-pragma,
|
||||
.hljs-built_in,
|
||||
.smalltalk .hljs-class,
|
||||
.smalltalk .hljs-localvars,
|
||||
.smalltalk .hljs-array,
|
||||
.css .hljs-rule .hljs-value,
|
||||
.hljs-attr_selector,
|
||||
.hljs-pseudo,
|
||||
.apache .hljs-cbracket,
|
||||
.tex .hljs-formula,
|
||||
.coffeescript .hljs-attribute {
|
||||
color: #cc9393;
|
||||
}
|
||||
|
||||
.hljs-shebang,
|
||||
.diff .hljs-addition,
|
||||
.hljs-comment,
|
||||
.hljs-annotation,
|
||||
.hljs-pi,
|
||||
.hljs-doctype {
|
||||
color: #7f9f7f;
|
||||
}
|
||||
|
||||
.coffeescript .javascript,
|
||||
.javascript .xml,
|
||||
.tex .hljs-formula,
|
||||
.xml .javascript,
|
||||
.xml .vbscript,
|
||||
.xml .css,
|
||||
.xml .hljs-cdata {
|
||||
opacity: 0.5;
|
||||
}
|
||||
|
||||
|
|
@ -77,7 +77,7 @@ xmlns:date="http://exslt.org/dates-and-times"
|
|||
-->
|
||||
<xsl:element name="link">
|
||||
<xsl:attribute name="rel">stylesheet</xsl:attribute>
|
||||
<xsl:attribute name="href">css/highlighter/github.css</xsl:attribute>
|
||||
<xsl:attribute name="href">css/highlighter/foundation.css</xsl:attribute>
|
||||
</xsl:element>
|
||||
<xsl:element name="script">
|
||||
<xsl:attribute name="src">js/highlight.pack.js</xsl:attribute>
|
||||
|
|
@ -157,7 +157,7 @@ xmlns:date="http://exslt.org/dates-and-times"
|
|||
</h5>
|
||||
<p>
|
||||
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ...
|
||||
scalability guidance for your apps and Ajax/Comet projects ... development services from 1 day to full product delivery
|
||||
scalability guidance for your apps and Ajax/Comet projects ... development services for sponsored feature development
|
||||
</p>
|
||||
</div>
|
||||
|
||||
|
|
@ -220,45 +220,29 @@ xmlns:date="http://exslt.org/dates-and-times"
|
|||
</script>
|
||||
</xsl:template>
|
||||
|
||||
|
||||
<xsl:template match="d:screen">
|
||||
<xsl:element name="div">
|
||||
<xsl:attribute name="class">screenexample</xsl:attribute>
|
||||
<xsl:element name="pre">
|
||||
<xsl:attribute name="class">screen</xsl:attribute>
|
||||
<!--<xsl:value-of select="text()"/>-->
|
||||
<xsl:apply-templates/>
|
||||
</xsl:element>
|
||||
</xsl:element>
|
||||
</xsl:template>
|
||||
|
||||
<!--
|
||||
- synxtax highlighting
|
||||
-->
|
||||
<xsl:template match="d:programlisting">
|
||||
<pre>
|
||||
<code>
|
||||
<xsl:value-of select="text()"/>
|
||||
</code>
|
||||
</pre>
|
||||
<!--
|
||||
|
||||
<xsl:variable name="startinglinenumber">
|
||||
<xsl:choose>
|
||||
<xsl:when test="@startinglinenumber">; first-line: <xsl:value-of select="@startinglinenumber"/></xsl:when>
|
||||
<xsl:otherwise></xsl:otherwise>
|
||||
</xsl:choose>
|
||||
</xsl:variable>
|
||||
|
||||
<xsl:variable name="linenumbering">
|
||||
<xsl:choose>
|
||||
<xsl:when test="@linenumbering='unnumbered'">; gutter: false</xsl:when>
|
||||
<xsl:otherwise></xsl:otherwise>
|
||||
</xsl:choose>
|
||||
</xsl:variable>
|
||||
|
||||
<xsl:variable name="brushstyle">;toolbar: false<xsl:copy-of select="$highlight"/><xsl:copy-of select="$startinglinenumber"/><xsl:copy-of select="$linenumbering"/></xsl:variable>
|
||||
-->
|
||||
<xsl:choose>
|
||||
<xsl:when test="@language = 'screen'">
|
||||
<xsl:element name="div">
|
||||
<xsl:attribute name="class">screenexample</xsl:attribute>
|
||||
<xsl:element name="pre">
|
||||
<xsl:attribute name="class">screen</xsl:attribute>
|
||||
<xsl:value-of select="text()"/>
|
||||
<xsl:apply-templates/>
|
||||
</xsl:element>
|
||||
</xsl:element>
|
||||
</xsl:when>
|
||||
<xsl:otherwise>
|
||||
<pre>
|
||||
<code>
|
||||
<xsl:value-of select="text()"/>
|
||||
</code>
|
||||
</pre>
|
||||
</xsl:otherwise>
|
||||
</xsl:choose>
|
||||
</xsl:template>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ public abstract class ChannelEndPoint extends AbstractEndPoint implements Manage
|
|||
}
|
||||
};
|
||||
|
||||
private final Runnable _runFillableCompleteWrite = new RejectableRunnable("runFillableCompleteWrite")
|
||||
private final Runnable _runCompleteWriteFillable = new RejectableRunnable("runCompleteWriteFillable")
|
||||
{
|
||||
@Override
|
||||
public void run()
|
||||
|
|
@ -333,7 +333,7 @@ public abstract class ChannelEndPoint extends AbstractEndPoint implements Manage
|
|||
}
|
||||
|
||||
// return task to complete the job
|
||||
Runnable task= readable ? (writable ? _runFillableCompleteWrite : _runFillable)
|
||||
Runnable task= readable ? (writable ? _runCompleteWriteFillable : _runFillable)
|
||||
: (writable ? _runCompleteWrite : null);
|
||||
|
||||
if (LOG.isDebugEnabled())
|
||||
|
|
|
|||
|
|
@ -78,11 +78,17 @@ public class ManagedSelector extends AbstractLifeCycle implements Runnable, Dump
|
|||
setStopTimeout(5000);
|
||||
}
|
||||
|
||||
public ExecutionStrategy getExecutionStrategy()
|
||||
{
|
||||
return _strategy;
|
||||
}
|
||||
|
||||
@Override
|
||||
protected void doStart() throws Exception
|
||||
{
|
||||
super.doStart();
|
||||
_selector = _selectorManager.newSelector();
|
||||
_selectorManager.execute(this);
|
||||
}
|
||||
|
||||
public int size()
|
||||
|
|
|
|||
|
|
@ -29,12 +29,11 @@ import java.nio.channels.ServerSocketChannel;
|
|||
import java.nio.channels.SocketChannel;
|
||||
import java.util.concurrent.Executor;
|
||||
|
||||
import org.eclipse.jetty.util.TypeUtil;
|
||||
import org.eclipse.jetty.util.component.AbstractLifeCycle;
|
||||
import org.eclipse.jetty.util.component.ContainerLifeCycle;
|
||||
import org.eclipse.jetty.util.component.Dumpable;
|
||||
import org.eclipse.jetty.util.log.Log;
|
||||
import org.eclipse.jetty.util.log.Logger;
|
||||
import org.eclipse.jetty.util.thread.ExecutionStrategy;
|
||||
import org.eclipse.jetty.util.thread.Scheduler;
|
||||
|
||||
/**
|
||||
|
|
@ -43,7 +42,7 @@ import org.eclipse.jetty.util.thread.Scheduler;
|
|||
* <p>{@link SelectorManager} subclasses implement methods to return protocol-specific
|
||||
* {@link EndPoint}s and {@link Connection}s.</p>
|
||||
*/
|
||||
public abstract class SelectorManager extends AbstractLifeCycle implements Dumpable
|
||||
public abstract class SelectorManager extends ContainerLifeCycle implements Dumpable
|
||||
{
|
||||
public static final int DEFAULT_CONNECT_TIMEOUT = 15000;
|
||||
protected static final Logger LOG = Log.getLogger(SelectorManager.class);
|
||||
|
|
@ -52,6 +51,7 @@ public abstract class SelectorManager extends AbstractLifeCycle implements Dumpa
|
|||
private final Scheduler scheduler;
|
||||
private final ManagedSelector[] _selectors;
|
||||
private long _connectTimeout = DEFAULT_CONNECT_TIMEOUT;
|
||||
private ExecutionStrategy.Factory _executionFactory = ExecutionStrategy.Factory.getDefault();
|
||||
private long _selectorIndex;
|
||||
|
||||
protected SelectorManager(Executor executor, Scheduler scheduler)
|
||||
|
|
@ -98,6 +98,24 @@ public abstract class SelectorManager extends AbstractLifeCycle implements Dumpa
|
|||
_connectTimeout = milliseconds;
|
||||
}
|
||||
|
||||
/**
|
||||
* @return the {@link ExecutionStrategy.Factory} used by {@link ManagedSelector}
|
||||
*/
|
||||
public ExecutionStrategy.Factory getExecutionStrategyFactory()
|
||||
{
|
||||
return _executionFactory;
|
||||
}
|
||||
|
||||
/**
|
||||
* @param _executionFactory the {@link ExecutionStrategy.Factory} used by {@link ManagedSelector}
|
||||
*/
|
||||
public void setExecutionStrategyFactory(ExecutionStrategy.Factory _executionFactory)
|
||||
{
|
||||
if (isRunning())
|
||||
throw new IllegalStateException("Cannot change " + ExecutionStrategy.Factory.class.getSimpleName() + " after start()");
|
||||
this._executionFactory = _executionFactory;
|
||||
}
|
||||
|
||||
/**
|
||||
* @return the selector priority delta
|
||||
* @deprecated not implemented
|
||||
|
|
@ -251,14 +269,13 @@ public abstract class SelectorManager extends AbstractLifeCycle implements Dumpa
|
|||
@Override
|
||||
protected void doStart() throws Exception
|
||||
{
|
||||
super.doStart();
|
||||
for (int i = 0; i < _selectors.length; i++)
|
||||
{
|
||||
ManagedSelector selector = newSelector(i);
|
||||
_selectors[i] = selector;
|
||||
selector.start();
|
||||
execute(selector);
|
||||
addBean(selector);
|
||||
}
|
||||
super.doStart();
|
||||
}
|
||||
|
||||
/**
|
||||
|
|
@ -269,15 +286,15 @@ public abstract class SelectorManager extends AbstractLifeCycle implements Dumpa
|
|||
*/
|
||||
protected ManagedSelector newSelector(int id)
|
||||
{
|
||||
return new ManagedSelector(this, id);
|
||||
return new ManagedSelector(this, id, getExecutionStrategyFactory());
|
||||
}
|
||||
|
||||
@Override
|
||||
protected void doStop() throws Exception
|
||||
{
|
||||
for (ManagedSelector selector : _selectors)
|
||||
selector.stop();
|
||||
super.doStop();
|
||||
for (ManagedSelector selector : _selectors)
|
||||
removeBean(selector);
|
||||
}
|
||||
|
||||
/**
|
||||
|
|
@ -297,6 +314,7 @@ public abstract class SelectorManager extends AbstractLifeCycle implements Dumpa
|
|||
*/
|
||||
protected void endPointClosed(EndPoint endpoint)
|
||||
{
|
||||
endpoint.onClose();
|
||||
}
|
||||
|
||||
/**
|
||||
|
|
@ -341,12 +359,12 @@ public abstract class SelectorManager extends AbstractLifeCycle implements Dumpa
|
|||
{
|
||||
return ((SocketChannel)channel).finishConnect();
|
||||
}
|
||||
|
||||
|
||||
protected boolean isConnectionPending(SelectableChannel channel)
|
||||
{
|
||||
return ((SocketChannel)channel).isConnectionPending();
|
||||
}
|
||||
|
||||
|
||||
protected SelectableChannel doAccept(SelectableChannel server) throws IOException
|
||||
{
|
||||
return ((ServerSocketChannel)server).accept();
|
||||
|
|
@ -370,7 +388,7 @@ public abstract class SelectorManager extends AbstractLifeCycle implements Dumpa
|
|||
{
|
||||
return Selector.open();
|
||||
}
|
||||
|
||||
|
||||
/**
|
||||
* <p>Factory method to create {@link EndPoint}.</p>
|
||||
* <p>This method is invoked as a result of the registration of a channel via {@link #connect(SelectableChannel, Object)}
|
||||
|
|
@ -395,18 +413,4 @@ public abstract class SelectorManager extends AbstractLifeCycle implements Dumpa
|
|||
* @throws IOException if unable to create new connection
|
||||
*/
|
||||
public abstract Connection newConnection(SelectableChannel channel, EndPoint endpoint, Object attachment) throws IOException;
|
||||
|
||||
@Override
|
||||
public String dump()
|
||||
{
|
||||
return ContainerLifeCycle.dump(this);
|
||||
}
|
||||
|
||||
@Override
|
||||
public void dump(Appendable out, String indent) throws IOException
|
||||
{
|
||||
ContainerLifeCycle.dumpObject(out, this);
|
||||
ContainerLifeCycle.dump(out, indent, TypeUtil.asList(_selectors));
|
||||
}
|
||||
|
||||
}
|
||||
|
|
|
|||
|
|
@ -592,6 +592,7 @@ public class HttpChannel implements Runnable, HttpOutput.Interceptor
|
|||
{
|
||||
// The bad message cannot be handled in the current state, so throw
|
||||
// to hopefull somebody that can handle
|
||||
abort(e);
|
||||
throw new BadMessageException(status,reason);
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
{
|
||||
|
|
|
|||
|
|
@ -44,6 +44,7 @@ import org.eclipse.jetty.util.annotation.ManagedAttribute;
|
|||
import org.eclipse.jetty.util.annotation.ManagedObject;
|
||||
import org.eclipse.jetty.util.annotation.Name;
|
||||
import org.eclipse.jetty.util.ssl.SslContextFactory;
|
||||
import org.eclipse.jetty.util.thread.ExecutionStrategy;
|
||||
import org.eclipse.jetty.util.thread.Scheduler;
|
||||
|
||||
/**
|
||||
|
|
@ -74,7 +75,6 @@ import org.eclipse.jetty.util.thread.Scheduler;
|
|||
* The default number of selectors is equal to the number of processors available to the JVM,
|
||||
* which should allow optimal performance even if all the connections used are performing
|
||||
* significant non-blocking work in the callback tasks.
|
||||
*
|
||||
*/
|
||||
@ManagedObject("HTTP connector using NIO ByteChannels and Selectors")
|
||||
public class ServerConnector extends AbstractNetworkConnector
|
||||
|
|
@ -87,24 +87,21 @@ public class ServerConnector extends AbstractNetworkConnector
|
|||
private volatile boolean _reuseAddress = true;
|
||||
private volatile int _lingerTime = -1;
|
||||
|
||||
|
||||
/* ------------------------------------------------------------ */
|
||||
/** HTTP Server Connection.
|
||||
/**
|
||||
* <p>Construct a ServerConnector with a private instance of {@link HttpConnectionFactory} as the only factory.</p>
|
||||
* @param server The {@link Server} this connector will accept connection for.
|
||||
* @param server The {@link Server} this connector will accept connection for.
|
||||
*/
|
||||
public ServerConnector(
|
||||
@Name("server") Server server)
|
||||
{
|
||||
this(server,null,null,null,-1,-1,new HttpConnectionFactory());
|
||||
}
|
||||
|
||||
/* ------------------------------------------------------------ */
|
||||
/** HTTP Server Connection.
|
||||
|
||||
/**
|
||||
* <p>Construct a ServerConnector with a private instance of {@link HttpConnectionFactory} as the only factory.</p>
|
||||
* @param server The {@link Server} this connector will accept connection for.
|
||||
* @param acceptors
|
||||
* the number of acceptor threads to use, or -1 for a default value. Acceptors accept new TCP/IP connections. If 0, then
|
||||
* @param server The {@link Server} this connector will accept connection for.
|
||||
* @param acceptors
|
||||
* the number of acceptor threads to use, or -1 for a default value. Acceptors accept new TCP/IP connections. If 0, then
|
||||
* the selector threads are used to accept connections.
|
||||
* @param selectors
|
||||
* the number of selector threads, or <=0 for a default value. Selectors notice and schedule established connection that can make IO progress.
|
||||
|
|
@ -116,13 +113,12 @@ public class ServerConnector extends AbstractNetworkConnector
|
|||
{
|
||||
this(server,null,null,null,acceptors,selectors,new HttpConnectionFactory());
|
||||
}
|
||||
|
||||
/* ------------------------------------------------------------ */
|
||||
/** HTTP Server Connection.
|
||||
|
||||
/**
|
||||
* <p>Construct a ServerConnector with a private instance of {@link HttpConnectionFactory} as the only factory.</p>
|
||||
* @param server The {@link Server} this connector will accept connection for.
|
||||
* @param acceptors
|
||||
* the number of acceptor threads to use, or -1 for a default value. Acceptors accept new TCP/IP connections. If 0, then
|
||||
* @param server The {@link Server} this connector will accept connection for.
|
||||
* @param acceptors
|
||||
* the number of acceptor threads to use, or -1 for a default value. Acceptors accept new TCP/IP connections. If 0, then
|
||||
* the selector threads are used to accept connections.
|
||||
* @param selectors
|
||||
* the number of selector threads, or <=0 for a default value. Selectors notice and schedule established connection that can make IO progress.
|
||||
|
|
@ -137,10 +133,9 @@ public class ServerConnector extends AbstractNetworkConnector
|
|||
this(server,null,null,null,acceptors,selectors,factories);
|
||||
}
|
||||
|
||||
/* ------------------------------------------------------------ */
|
||||
/** Generic Server Connection with default configuration.
|
||||
/**
|
||||
* <p>Construct a Server Connector with the passed Connection factories.</p>
|
||||
* @param server The {@link Server} this connector will accept connection for.
|
||||
* @param server The {@link Server} this connector will accept connection for.
|
||||
* @param factories Zero or more {@link ConnectionFactory} instances used to create and configure connections.
|
||||
*/
|
||||
public ServerConnector(
|
||||
|
|
@ -150,11 +145,10 @@ public class ServerConnector extends AbstractNetworkConnector
|
|||
this(server,null,null,null,-1,-1,factories);
|
||||
}
|
||||
|
||||
/* ------------------------------------------------------------ */
|
||||
/** HTTP Server Connection.
|
||||
/**
|
||||
* <p>Construct a ServerConnector with a private instance of {@link HttpConnectionFactory} as the primary protocol</p>.
|
||||
* @param server The {@link Server} this connector will accept connection for.
|
||||
* @param sslContextFactory If non null, then a {@link SslConnectionFactory} is instantiated and prepended to the
|
||||
* @param server The {@link Server} this connector will accept connection for.
|
||||
* @param sslContextFactory If non null, then a {@link SslConnectionFactory} is instantiated and prepended to the
|
||||
* list of HTTP Connection Factory.
|
||||
*/
|
||||
public ServerConnector(
|
||||
|
|
@ -164,14 +158,13 @@ public class ServerConnector extends AbstractNetworkConnector
|
|||
this(server,null,null,null,-1,-1,AbstractConnectionFactory.getFactories(sslContextFactory,new HttpConnectionFactory()));
|
||||
}
|
||||
|
||||
/* ------------------------------------------------------------ */
|
||||
/** HTTP Server Connection.
|
||||
/**
|
||||
* <p>Construct a ServerConnector with a private instance of {@link HttpConnectionFactory} as the primary protocol</p>.
|
||||
* @param server The {@link Server} this connector will accept connection for.
|
||||
* @param sslContextFactory If non null, then a {@link SslConnectionFactory} is instantiated and prepended to the
|
||||
* @param server The {@link Server} this connector will accept connection for.
|
||||
* @param sslContextFactory If non null, then a {@link SslConnectionFactory} is instantiated and prepended to the
|
||||
* list of HTTP Connection Factory.
|
||||
* @param acceptors
|
||||
* the number of acceptor threads to use, or -1 for a default value. Acceptors accept new TCP/IP connections. If 0, then
|
||||
* @param acceptors
|
||||
* the number of acceptor threads to use, or -1 for a default value. Acceptors accept new TCP/IP connections. If 0, then
|
||||
* the selector threads are used to accept connections.
|
||||
* @param selectors
|
||||
* the number of selector threads, or <=0 for a default value. Selectors notice and schedule established connection that can make IO progress.
|
||||
|
|
@ -185,10 +178,9 @@ public class ServerConnector extends AbstractNetworkConnector
|
|||
this(server,null,null,null,acceptors,selectors,AbstractConnectionFactory.getFactories(sslContextFactory,new HttpConnectionFactory()));
|
||||
}
|
||||
|
||||
/* ------------------------------------------------------------ */
|
||||
/** Generic SSL Server Connection.
|
||||
* @param server The {@link Server} this connector will accept connection for.
|
||||
* @param sslContextFactory If non null, then a {@link SslConnectionFactory} is instantiated and prepended to the
|
||||
/**
|
||||
* @param server The {@link Server} this connector will accept connection for.
|
||||
* @param sslContextFactory If non null, then a {@link SslConnectionFactory} is instantiated and prepended to the
|
||||
* list of ConnectionFactories, with the first factory being the default protocol for the SslConnectionFactory.
|
||||
* @param factories Zero or more {@link ConnectionFactory} instances used to create and configure connections.
|
||||
*/
|
||||
|
|
@ -200,22 +192,22 @@ public class ServerConnector extends AbstractNetworkConnector
|
|||
this(server, null, null, null, -1, -1, AbstractConnectionFactory.getFactories(sslContextFactory, factories));
|
||||
}
|
||||
|
||||
/** Generic Server Connection.
|
||||
* @param server
|
||||
* The server this connector will be accept connection for.
|
||||
* @param executor
|
||||
/**
|
||||
* @param server
|
||||
* The server this connector will be accept connection for.
|
||||
* @param executor
|
||||
* An executor used to run tasks for handling requests, acceptors and selectors.
|
||||
* If null then use the servers executor
|
||||
* @param scheduler
|
||||
* @param scheduler
|
||||
* A scheduler used to schedule timeouts. If null then use the servers scheduler
|
||||
* @param bufferPool
|
||||
* A ByteBuffer pool used to allocate buffers. If null then create a private pool with default configuration.
|
||||
* @param acceptors
|
||||
* the number of acceptor threads to use, or -1 for a default value. Acceptors accept new TCP/IP connections. If 0, then
|
||||
* @param acceptors
|
||||
* the number of acceptor threads to use, or -1 for a default value. Acceptors accept new TCP/IP connections. If 0, then
|
||||
* the selector threads are used to accept connections.
|
||||
* @param selectors
|
||||
* the number of selector threads, or <=0 for a default value. Selectors notice and schedule established connection that can make IO progress.
|
||||
* @param factories
|
||||
* @param factories
|
||||
* Zero or more {@link ConnectionFactory} instances used to create and configure connections.
|
||||
*/
|
||||
public ServerConnector(
|
||||
|
|
@ -277,7 +269,7 @@ public class ServerConnector extends AbstractNetworkConnector
|
|||
{
|
||||
_manager.setSelectorPriorityDelta(selectorPriorityDelta);
|
||||
}
|
||||
|
||||
|
||||
/**
|
||||
* @return whether this connector uses a channel inherited from the JVM.
|
||||
* @see System#inheritedChannel()
|
||||
|
|
@ -384,7 +376,7 @@ public class ServerConnector extends AbstractNetworkConnector
|
|||
accepted(channel);
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
private void accepted(SocketChannel channel) throws IOException
|
||||
{
|
||||
channel.configureBlocking(false);
|
||||
|
|
@ -486,6 +478,22 @@ public class ServerConnector extends AbstractNetworkConnector
|
|||
_reuseAddress = reuseAddress;
|
||||
}
|
||||
|
||||
/**
|
||||
* @return the ExecutionStrategy factory to use for SelectorManager
|
||||
*/
|
||||
public ExecutionStrategy.Factory getExecutionStrategyFactory()
|
||||
{
|
||||
return _manager.getExecutionStrategyFactory();
|
||||
}
|
||||
|
||||
/**
|
||||
* @param executionFactory the ExecutionStrategy factory to use for SelectorManager
|
||||
*/
|
||||
public void setExecutionStrategyFactory(ExecutionStrategy.Factory executionFactory)
|
||||
{
|
||||
_manager.setExecutionStrategyFactory(executionFactory);
|
||||
}
|
||||
|
||||
protected class ServerConnectorManager extends SelectorManager
|
||||
{
|
||||
public ServerConnectorManager(Executor executor, Scheduler scheduler, int selectors)
|
||||
|
|
|
|||
|
|
@ -18,169 +18,259 @@
|
|||
|
||||
package org.eclipse.jetty.server;
|
||||
|
||||
import static org.hamcrest.Matchers.containsString;
|
||||
import static org.junit.Assert.assertEquals;
|
||||
import static org.junit.Assert.assertThat;
|
||||
|
||||
import java.io.IOException;
|
||||
import java.io.InputStream;
|
||||
import java.io.OutputStream;
|
||||
import java.net.Socket;
|
||||
import java.nio.charset.StandardCharsets;
|
||||
import java.util.concurrent.CountDownLatch;
|
||||
|
||||
import javax.servlet.ServletException;
|
||||
import javax.servlet.http.HttpServletRequest;
|
||||
import javax.servlet.http.HttpServletResponse;
|
||||
|
||||
import org.eclipse.jetty.io.ManagedSelector;
|
||||
import org.eclipse.jetty.server.handler.AbstractHandler;
|
||||
import org.eclipse.jetty.toolchain.test.AdvancedRunner;
|
||||
import org.eclipse.jetty.toolchain.test.TestTracker;
|
||||
import org.eclipse.jetty.util.IO;
|
||||
import org.junit.Before;
|
||||
import org.eclipse.jetty.util.thread.ExecutionStrategy;
|
||||
import org.eclipse.jetty.util.thread.QueuedThreadPool;
|
||||
import org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume;
|
||||
import org.eclipse.jetty.util.thread.strategy.ProduceExecuteConsume;
|
||||
import org.junit.After;
|
||||
import org.junit.Assert;
|
||||
import org.junit.Rule;
|
||||
import org.junit.Test;
|
||||
import org.junit.runner.RunWith;
|
||||
|
||||
@RunWith(AdvancedRunner.class)
|
||||
public class ThreadStarvationTest extends HttpServerTestFixture
|
||||
import static org.hamcrest.Matchers.containsString;
|
||||
import static org.junit.Assert.assertEquals;
|
||||
import static org.junit.Assert.assertFalse;
|
||||
import static org.junit.Assert.assertThat;
|
||||
import static org.junit.Assert.assertTrue;
|
||||
|
||||
public class ThreadStarvationTest
|
||||
{
|
||||
ServerConnector _connector;
|
||||
|
||||
@Rule
|
||||
public TestTracker tracker = new TestTracker();
|
||||
private QueuedThreadPool _threadPool;
|
||||
private Server _server;
|
||||
private ServerConnector _connector;
|
||||
private int _availableThreads;
|
||||
|
||||
@Before
|
||||
public void init() throws Exception
|
||||
private Server prepareServer(Handler handler)
|
||||
{
|
||||
_threadPool.setMinThreads(4);
|
||||
_threadPool.setMaxThreads(4);
|
||||
_threadPool.setDetailedDump(false);
|
||||
_connector = new ServerConnector(_server,1,1);
|
||||
_connector.setIdleTimeout(10000);
|
||||
int threads = 4;
|
||||
_threadPool = new QueuedThreadPool();
|
||||
_threadPool.setMinThreads(threads);
|
||||
_threadPool.setMaxThreads(threads);
|
||||
_threadPool.setDetailedDump(true);
|
||||
_server = new Server(_threadPool);
|
||||
int acceptors = 1;
|
||||
int selectors = 1;
|
||||
_connector = new ServerConnector(_server, acceptors, selectors);
|
||||
_server.addConnector(_connector);
|
||||
_server.setHandler(handler);
|
||||
_availableThreads = threads - acceptors - selectors;
|
||||
return _server;
|
||||
}
|
||||
|
||||
@After
|
||||
public void dispose() throws Exception
|
||||
{
|
||||
_server.stop();
|
||||
}
|
||||
|
||||
@Test
|
||||
public void testReadInput() throws Exception
|
||||
{
|
||||
startServer(_connector,new ReadHandler());
|
||||
System.err.println(_threadPool.dump());
|
||||
|
||||
Socket client=newSocket(_serverURI.getHost(),_serverURI.getPort());
|
||||
client.setSoTimeout(10000);
|
||||
prepareServer(new ReadHandler()).start();
|
||||
|
||||
OutputStream os=client.getOutputStream();
|
||||
InputStream is=client.getInputStream();
|
||||
Socket client = new Socket("localhost", _connector.getLocalPort());
|
||||
|
||||
os.write((
|
||||
"GET / HTTP/1.0\r\n"+
|
||||
"host: "+_serverURI.getHost()+":"+_serverURI.getPort()+"\r\n"+
|
||||
"content-length: 10\r\n" +
|
||||
OutputStream os = client.getOutputStream();
|
||||
InputStream is = client.getInputStream();
|
||||
|
||||
String request = "" +
|
||||
"GET / HTTP/1.0\r\n" +
|
||||
"Host: localhost\r\n" +
|
||||
"Content-Length: 10\r\n" +
|
||||
"\r\n" +
|
||||
"0123456789\r\n").getBytes("utf-8"));
|
||||
"0123456789\r\n";
|
||||
os.write(request.getBytes(StandardCharsets.UTF_8));
|
||||
os.flush();
|
||||
|
||||
String response = IO.toString(is);
|
||||
assertEquals(-1, is.read());
|
||||
assertThat(response,containsString("200 OK"));
|
||||
assertThat(response,containsString("Read Input 10"));
|
||||
|
||||
assertThat(response, containsString("200 OK"));
|
||||
assertThat(response, containsString("Read Input 10"));
|
||||
}
|
||||
|
||||
|
||||
@Test
|
||||
public void testEWYKStarvation() throws Exception
|
||||
public void testEPCStarvation() throws Exception
|
||||
{
|
||||
System.setProperty("org.eclipse.jetty.io.ManagedSelector$SelectorProducer.ExecutionStrategy","org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume");
|
||||
startServer(_connector,new ReadHandler());
|
||||
|
||||
Socket[] client = new Socket[3];
|
||||
OutputStream[] os = new OutputStream[client.length];
|
||||
InputStream[] is = new InputStream[client.length];
|
||||
|
||||
for (int i=0;i<client.length;i++)
|
||||
{
|
||||
client[i]=newSocket(_serverURI.getHost(),_serverURI.getPort());
|
||||
client[i].setSoTimeout(10000);
|
||||
|
||||
os[i]=client[i].getOutputStream();
|
||||
is[i]=client[i].getInputStream();
|
||||
|
||||
os[i].write((
|
||||
"PUT / HTTP/1.0\r\n"+
|
||||
"host: "+_serverURI.getHost()+":"+_serverURI.getPort()+"\r\n"+
|
||||
"content-length: 10\r\n" +
|
||||
"\r\n1").getBytes("utf-8"));
|
||||
os[i].flush();
|
||||
}
|
||||
Thread.sleep(500);
|
||||
System.err.println(_threadPool.dump());
|
||||
|
||||
for (int i=0;i<client.length;i++)
|
||||
{
|
||||
os[i].write(("234567890\r\n").getBytes("utf-8"));
|
||||
os[i].flush();
|
||||
}
|
||||
|
||||
Thread.sleep(500);
|
||||
System.err.println(_threadPool.dump());
|
||||
|
||||
for (int i=0;i<client.length;i++)
|
||||
{
|
||||
String response = IO.toString(is[i]);
|
||||
assertEquals(-1, is[i].read());
|
||||
assertThat(response,containsString("200 OK"));
|
||||
assertThat(response,containsString("Read Input 10"));
|
||||
}
|
||||
testStarvation(new ExecuteProduceConsume.Factory());
|
||||
}
|
||||
|
||||
|
||||
@Test
|
||||
public void testPECStarvation() throws Exception
|
||||
{
|
||||
System.setProperty("org.eclipse.jetty.io.ManagedSelector$SelectorProducer.ExecutionStrategy","org.eclipse.jetty.util.thread.strategy.ProduceExecuteConsume");
|
||||
testStarvation(new ProduceExecuteConsume.Factory());
|
||||
}
|
||||
|
||||
startServer(_connector,new ReadHandler());
|
||||
private void testStarvation(ExecutionStrategy.Factory executionFactory) throws Exception
|
||||
{
|
||||
prepareServer(new ReadHandler());
|
||||
_connector.setExecutionStrategyFactory(executionFactory);
|
||||
_server.start();
|
||||
System.err.println(_threadPool.dump());
|
||||
|
||||
Socket[] client = new Socket[3];
|
||||
|
||||
Socket[] client = new Socket[_availableThreads + 1];
|
||||
OutputStream[] os = new OutputStream[client.length];
|
||||
InputStream[] is = new InputStream[client.length];
|
||||
|
||||
for (int i=0;i<client.length;i++)
|
||||
|
||||
for (int i = 0; i < client.length; i++)
|
||||
{
|
||||
client[i]=newSocket(_serverURI.getHost(),_serverURI.getPort());
|
||||
client[i] = new Socket("localhost", _connector.getLocalPort());
|
||||
client[i].setSoTimeout(10000);
|
||||
|
||||
os[i]=client[i].getOutputStream();
|
||||
is[i]=client[i].getInputStream();
|
||||
os[i] = client[i].getOutputStream();
|
||||
is[i] = client[i].getInputStream();
|
||||
|
||||
os[i].write((
|
||||
"PUT / HTTP/1.0\r\n"+
|
||||
"host: "+_serverURI.getHost()+":"+_serverURI.getPort()+"\r\n"+
|
||||
"content-length: 10\r\n" +
|
||||
"\r\n1").getBytes("utf-8"));
|
||||
String request = "" +
|
||||
"PUT / HTTP/1.0\r\n" +
|
||||
"host: localhost\r\n" +
|
||||
"content-length: 10\r\n" +
|
||||
"\r\n" +
|
||||
"1";
|
||||
os[i].write(request.getBytes(StandardCharsets.UTF_8));
|
||||
os[i].flush();
|
||||
}
|
||||
|
||||
Thread.sleep(500);
|
||||
System.err.println(_threadPool.dump());
|
||||
|
||||
for (int i=0;i<client.length;i++)
|
||||
for (int i = 0; i < client.length; i++)
|
||||
{
|
||||
os[i].write(("234567890\r\n").getBytes("utf-8"));
|
||||
os[i].write(("234567890\r\n").getBytes(StandardCharsets.UTF_8));
|
||||
os[i].flush();
|
||||
}
|
||||
|
||||
Thread.sleep(500);
|
||||
System.err.println(_threadPool.dump());
|
||||
|
||||
for (int i=0;i<client.length;i++)
|
||||
for (int i = 0; i < client.length; i++)
|
||||
{
|
||||
String response = IO.toString(is[i]);
|
||||
assertEquals(-1, is[i].read());
|
||||
assertThat(response,containsString("200 OK"));
|
||||
assertThat(response,containsString("Read Input 10"));
|
||||
assertThat(response, containsString("200 OK"));
|
||||
assertThat(response, containsString("Read Input 10"));
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
|
||||
@Test
|
||||
public void testEPCExitsLowThreadsMode() throws Exception
|
||||
{
|
||||
prepareServer(new ReadHandler());
|
||||
Assert.assertEquals(2, _availableThreads);
|
||||
_connector.setExecutionStrategyFactory(new ExecuteProduceConsume.Factory());
|
||||
_server.start();
|
||||
System.err.println(_server.dump());
|
||||
|
||||
// Two idle threads in the pool here.
|
||||
// The server will accept the socket in normal mode.
|
||||
Socket client = new Socket("localhost", _connector.getLocalPort());
|
||||
client.setSoTimeout(10000);
|
||||
|
||||
Thread.sleep(500);
|
||||
|
||||
// Now steal one thread.
|
||||
CountDownLatch latch = new CountDownLatch(1);
|
||||
_threadPool.execute(() ->
|
||||
{
|
||||
try
|
||||
{
|
||||
latch.await();
|
||||
}
|
||||
catch (InterruptedException ignored)
|
||||
{
|
||||
}
|
||||
});
|
||||
|
||||
InputStream is = client.getInputStream();
|
||||
OutputStream os = client.getOutputStream();
|
||||
|
||||
String request = "" +
|
||||
"PUT / HTTP/1.0\r\n" +
|
||||
"Host: localhost\r\n" +
|
||||
"Content-Length: 10\r\n" +
|
||||
"\r\n" +
|
||||
"1";
|
||||
os.write(request.getBytes(StandardCharsets.UTF_8));
|
||||
os.flush();
|
||||
|
||||
Thread.sleep(500);
|
||||
System.err.println(_threadPool.dump());
|
||||
|
||||
// Request did not send the whole body, Handler
|
||||
// is blocked reading, zero idle threads here,
|
||||
// EPC is in low threads mode.
|
||||
for (ManagedSelector selector : _connector.getSelectorManager().getBeans(ManagedSelector.class))
|
||||
{
|
||||
ExecuteProduceConsume executionStrategy = (ExecuteProduceConsume)selector.getExecutionStrategy();
|
||||
assertTrue(executionStrategy.isLowOnThreads());
|
||||
}
|
||||
|
||||
// Release the stolen thread.
|
||||
latch.countDown();
|
||||
Thread.sleep(500);
|
||||
|
||||
// Send the rest of the body to unblock the reader thread.
|
||||
// This will be run directly by the selector thread,
|
||||
// which therefore will remain in low threads mode.
|
||||
os.write("234567890".getBytes(StandardCharsets.UTF_8));
|
||||
os.flush();
|
||||
|
||||
Thread.sleep(500);
|
||||
System.err.println(_threadPool.dump());
|
||||
|
||||
// Back to two idle threads here, but we are still in
|
||||
// low threads mode because the SelectorProducer has
|
||||
// not returned from the low threads mode.
|
||||
|
||||
String response = IO.toString(is);
|
||||
assertThat(response, containsString("200 OK"));
|
||||
assertThat(response, containsString("Read Input 10"));
|
||||
|
||||
// Send another request.
|
||||
// Accepting a new connection will exit the low threads mode.
|
||||
client = new Socket("localhost", _connector.getLocalPort());
|
||||
client.setSoTimeout(10000);
|
||||
|
||||
Thread.sleep(500);
|
||||
System.err.println(_threadPool.dump());
|
||||
|
||||
for (ManagedSelector selector : _connector.getSelectorManager().getBeans(ManagedSelector.class))
|
||||
{
|
||||
ExecuteProduceConsume executionStrategy = (ExecuteProduceConsume)selector.getExecutionStrategy();
|
||||
assertFalse(executionStrategy.isLowOnThreads());
|
||||
}
|
||||
|
||||
is = client.getInputStream();
|
||||
os = client.getOutputStream();
|
||||
request = "" +
|
||||
"PUT / HTTP/1.0\r\n" +
|
||||
"Host: localhost\r\n" +
|
||||
"Content-Length: 10\r\n" +
|
||||
"\r\n" +
|
||||
"1234567890";
|
||||
|
||||
os.write(request.getBytes(StandardCharsets.UTF_8));
|
||||
os.flush();
|
||||
|
||||
response = IO.toString(is);
|
||||
assertThat(response, containsString("200 OK"));
|
||||
assertThat(response, containsString("Read Input 10"));
|
||||
}
|
||||
|
||||
protected static class ReadHandler extends AbstractHandler
|
||||
{
|
||||
|
|
@ -192,13 +282,13 @@ public class ThreadStarvationTest extends HttpServerTestFixture
|
|||
|
||||
int l = request.getContentLength();
|
||||
int r = 0;
|
||||
while (r<l)
|
||||
while (r < l)
|
||||
{
|
||||
if (request.getInputStream().read()>=0)
|
||||
if (request.getInputStream().read() >= 0)
|
||||
r++;
|
||||
}
|
||||
|
||||
response.getOutputStream().write(("Read Input "+r+"\r\n").getBytes());
|
||||
|
||||
response.getOutputStream().write(("Read Input " + r + "\r\n").getBytes());
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -18,26 +18,20 @@
|
|||
|
||||
package org.eclipse.jetty.servlet;
|
||||
|
||||
import static org.hamcrest.Matchers.containsString;
|
||||
import static org.hamcrest.Matchers.not;
|
||||
import static org.junit.Assert.assertThat;
|
||||
|
||||
import java.io.IOException;
|
||||
import java.nio.charset.StandardCharsets;
|
||||
import java.util.concurrent.TimeUnit;
|
||||
|
||||
import javax.servlet.ServletInputStream;
|
||||
import javax.servlet.http.HttpServlet;
|
||||
import javax.servlet.http.HttpServletRequest;
|
||||
import javax.servlet.http.HttpServletResponse;
|
||||
|
||||
import org.eclipse.jetty.server.LocalConnector;
|
||||
import org.eclipse.jetty.server.Server;
|
||||
import org.eclipse.jetty.server.LocalConnector.LocalEndPoint;
|
||||
import org.eclipse.jetty.util.log.Log;
|
||||
import org.eclipse.jetty.util.log.Logger;
|
||||
import org.eclipse.jetty.util.log.StacklessLogging;
|
||||
import org.hamcrest.Matchers;
|
||||
import org.junit.After;
|
||||
import org.junit.Assert;
|
||||
import org.junit.Before;
|
||||
import org.junit.Test;
|
||||
|
||||
|
|
@ -51,25 +45,20 @@ public class PostServletTest
|
|||
{
|
||||
try
|
||||
{
|
||||
byte[] buffer = new byte[4096];
|
||||
|
||||
ServletInputStream in = request.getInputStream();
|
||||
|
||||
int l = in.read(buffer);
|
||||
while (l>0)
|
||||
{
|
||||
String s=new String(buffer,0,l,StandardCharsets.ISO_8859_1);
|
||||
// System.err.println("READ: "+s);
|
||||
if (s.toLowerCase().contains("flush"))
|
||||
response.flushBuffer();
|
||||
|
||||
l = in.read(buffer);
|
||||
}
|
||||
|
||||
response.flushBuffer();
|
||||
request.getInputStream().read();
|
||||
}
|
||||
catch (IOException e0)
|
||||
catch (Exception e0)
|
||||
{
|
||||
LOG.warn(e0);
|
||||
try
|
||||
{
|
||||
// this read-call should fail immediately
|
||||
request.getInputStream().read();
|
||||
}
|
||||
catch (Exception e1)
|
||||
{
|
||||
LOG.warn(e1.toString());
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -114,39 +103,37 @@ public class PostServletTest
|
|||
req.append("6\r\n");
|
||||
req.append("World\n");
|
||||
req.append("\r\n");
|
||||
req.append("0\r\n");
|
||||
req.append("0\r\n");
|
||||
req.append("\r\n");
|
||||
|
||||
String resp = connector.getResponses(req.toString());
|
||||
|
||||
assertThat("resp", resp, containsString("HTTP/1.1 200 OK"));
|
||||
Assert.assertThat("resp", resp, Matchers.containsString("HTTP/1.1 200 OK"));
|
||||
}
|
||||
|
||||
|
||||
@Test
|
||||
public void testBadPost() throws Exception
|
||||
{
|
||||
StringBuilder req = new StringBuilder();
|
||||
StringBuilder req = new StringBuilder(16*1024);
|
||||
req.append("POST /post HTTP/1.1\r\n");
|
||||
req.append("Host: localhost\r\n");
|
||||
req.append("Connection: close\r\n");
|
||||
req.append("Transfer-Encoding: chunked\r\n");
|
||||
req.append("\r\n");
|
||||
req.append("6\r\n");
|
||||
req.append("Hello ");
|
||||
// intentionally bad (not a valid chunked char here)
|
||||
for (int i=1024;i-->0;)
|
||||
req.append("xxxxxxxxxxxx");
|
||||
req.append("\r\n");
|
||||
req.append("x\r\n");
|
||||
req.append("World\n");
|
||||
req.append("\r\n");
|
||||
req.append("0\r\n");
|
||||
req.append("\r\n");
|
||||
|
||||
try (StacklessLogging scope = new StacklessLogging(ServletHandler.class))
|
||||
{
|
||||
String resp = connector.getResponses(req.toString());
|
||||
assertThat("resp", resp, containsString("HTTP/1.1 400 "));
|
||||
Assert.assertThat("resp", resp, Matchers.containsString("HTTP/1.1 200 "));
|
||||
Assert.assertThat("resp", resp, Matchers.containsString("chunked"));
|
||||
Assert.assertThat("resp", resp, Matchers.not(Matchers.containsString("\r\n0\r\n")));
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@Test
|
||||
public void testBadSplitPost() throws Exception
|
||||
{
|
||||
|
|
@ -162,23 +149,23 @@ public class PostServletTest
|
|||
|
||||
try (StacklessLogging scope = new StacklessLogging(ServletHandler.class))
|
||||
{
|
||||
LocalEndPoint endp=connector.executeRequest(req.toString());
|
||||
LocalConnector.LocalEndPoint endp=connector.executeRequest(req.toString());
|
||||
req.setLength(0);
|
||||
|
||||
Thread.sleep(1000);
|
||||
req.append("x\r\n");
|
||||
req.append("World\n");
|
||||
req.append("\r\n");
|
||||
req.append("0\r\n");
|
||||
req.append("0\r\n");
|
||||
req.append("\r\n");
|
||||
endp.addInput(req.toString());
|
||||
|
||||
|
||||
endp.waitUntilClosedOrIdleFor(1,TimeUnit.SECONDS);
|
||||
String resp = endp.takeOutputString();
|
||||
assertThat("resp", resp, containsString("HTTP/1.1 400 "));
|
||||
Assert.assertThat("resp", resp, Matchers.containsString("HTTP/1.1 400 "));
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@Test
|
||||
public void testBadFlushedPost() throws Exception
|
||||
{
|
||||
|
|
@ -193,22 +180,22 @@ public class PostServletTest
|
|||
|
||||
try (StacklessLogging scope = new StacklessLogging(ServletHandler.class))
|
||||
{
|
||||
LocalEndPoint endp=connector.executeRequest(req.toString());
|
||||
LocalConnector.LocalEndPoint endp=connector.executeRequest(req.toString());
|
||||
req.setLength(0);
|
||||
|
||||
Thread.sleep(1000);
|
||||
req.append("x\r\n");
|
||||
req.append("World\n");
|
||||
req.append("\r\n");
|
||||
req.append("0\r\n");
|
||||
req.append("0\r\n");
|
||||
req.append("\r\n");
|
||||
endp.addInput(req.toString());
|
||||
|
||||
|
||||
endp.waitUntilClosedOrIdleFor(1,TimeUnit.SECONDS);
|
||||
String resp = endp.takeOutputString();
|
||||
assertThat("resp", resp, containsString("HTTP/1.1 200 "));
|
||||
assertThat("resp", resp, containsString("Transfer-Encoding: chunked"));
|
||||
assertThat("resp", resp, not(containsString("\r\n0\r\n")));
|
||||
Assert.assertThat("resp", resp, Matchers.containsString("HTTP/1.1 200 "));
|
||||
Assert.assertThat("resp", resp, Matchers.containsString("Transfer-Encoding: chunked"));
|
||||
Assert.assertThat("resp", resp, Matchers.not(Matchers.containsString("\r\n0\r\n")));
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -19,7 +19,6 @@
|
|||
package org.eclipse.jetty.util.thread.strategy;
|
||||
|
||||
import java.util.concurrent.Executor;
|
||||
import java.util.concurrent.RejectedExecutionException;
|
||||
|
||||
import org.eclipse.jetty.util.log.Log;
|
||||
import org.eclipse.jetty.util.log.Logger;
|
||||
|
|
@ -50,32 +49,33 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
|
|||
private final Locker _locker = new Locker();
|
||||
private final Runnable _runExecute = new RunExecute();
|
||||
private final Producer _producer;
|
||||
private boolean _idle=true;
|
||||
private final ThreadPool _threadPool;
|
||||
private boolean _idle = true;
|
||||
private boolean _execute;
|
||||
private boolean _producing;
|
||||
private boolean _pending;
|
||||
private final ThreadPool _threadpool;
|
||||
private boolean _lowThreads;
|
||||
|
||||
public ExecuteProduceConsume(Producer producer, Executor executor)
|
||||
{
|
||||
super(executor);
|
||||
this._producer = producer;
|
||||
_threadpool = (executor instanceof ThreadPool)?((ThreadPool)executor):null;
|
||||
_threadPool = executor instanceof ThreadPool ? (ThreadPool)executor : null;
|
||||
}
|
||||
|
||||
@Deprecated
|
||||
public ExecuteProduceConsume(Producer producer, Executor executor, ExecutionStrategy lowResourceStrategy)
|
||||
{
|
||||
this(producer,executor);
|
||||
this(producer, executor);
|
||||
}
|
||||
|
||||
@Override
|
||||
public void execute()
|
||||
{
|
||||
if (LOG.isDebugEnabled())
|
||||
LOG.debug("{} execute",this);
|
||||
LOG.debug("{} execute", this);
|
||||
|
||||
boolean produce=false;
|
||||
boolean produce = false;
|
||||
try (Lock locked = _locker.lock())
|
||||
{
|
||||
// If we are idle and a thread is not producing
|
||||
|
|
@ -85,15 +85,15 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
|
|||
throw new IllegalStateException();
|
||||
|
||||
// Then this thread will do the producing
|
||||
produce=_producing=true;
|
||||
produce = _producing = true;
|
||||
// and we are no longer idle
|
||||
_idle=false;
|
||||
_idle = false;
|
||||
}
|
||||
else
|
||||
{
|
||||
// Otherwise, lets tell the producing thread
|
||||
// that it should call produce again before going idle
|
||||
_execute=true;
|
||||
_execute = true;
|
||||
}
|
||||
}
|
||||
|
||||
|
|
@ -105,14 +105,14 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
|
|||
public void dispatch()
|
||||
{
|
||||
if (LOG.isDebugEnabled())
|
||||
LOG.debug("{} spawning",this);
|
||||
boolean dispatch=false;
|
||||
LOG.debug("{} spawning", this);
|
||||
boolean dispatch = false;
|
||||
try (Lock locked = _locker.lock())
|
||||
{
|
||||
if (_idle)
|
||||
dispatch=true;
|
||||
dispatch = true;
|
||||
else
|
||||
_execute=true;
|
||||
_execute = true;
|
||||
}
|
||||
if (dispatch)
|
||||
execute(_runExecute);
|
||||
|
|
@ -122,26 +122,36 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
|
|||
public void run()
|
||||
{
|
||||
if (LOG.isDebugEnabled())
|
||||
LOG.debug("{} run",this);
|
||||
boolean produce=false;
|
||||
LOG.debug("{} run", this);
|
||||
boolean produce = false;
|
||||
try (Lock locked = _locker.lock())
|
||||
{
|
||||
_pending=false;
|
||||
_pending = false;
|
||||
if (!_idle && !_producing)
|
||||
{
|
||||
produce=_producing=true;
|
||||
produce = _producing = true;
|
||||
}
|
||||
}
|
||||
|
||||
if (produce)
|
||||
{
|
||||
// If we are low on threads, this could be the last thread, so we must not consume.
|
||||
// So call produceExecuteConsume instead
|
||||
if (_threadpool!=null && _threadpool.isLowOnThreads() && !produceExecuteConsume())
|
||||
return;
|
||||
|
||||
produceConsume();
|
||||
}
|
||||
|
||||
private void produceConsume()
|
||||
{
|
||||
if (_threadPool != null && _threadPool.isLowOnThreads())
|
||||
{
|
||||
// If we are low on threads we must not produce and consume
|
||||
// in the same thread, but produce and execute to consume.
|
||||
if (!produceExecuteConsume())
|
||||
return;
|
||||
}
|
||||
executeProduceConsume();
|
||||
}
|
||||
|
||||
public boolean isLowOnThreads()
|
||||
{
|
||||
return _lowThreads;
|
||||
}
|
||||
|
||||
/**
|
||||
|
|
@ -150,55 +160,70 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
|
|||
private boolean produceExecuteConsume()
|
||||
{
|
||||
if (LOG.isDebugEnabled())
|
||||
LOG.debug("{} Low Resources",this);
|
||||
while (_threadpool.isLowOnThreads())
|
||||
LOG.debug("{} enter low threads mode", this);
|
||||
_lowThreads = true;
|
||||
try
|
||||
{
|
||||
Runnable task = _producer.produce();
|
||||
if (LOG.isDebugEnabled())
|
||||
LOG.debug("{} produced {}", _producer, task);
|
||||
|
||||
if (task == null)
|
||||
boolean idle = false;
|
||||
while (_threadPool.isLowOnThreads())
|
||||
{
|
||||
// No task, so we are now idle
|
||||
try (Lock locked = _locker.lock())
|
||||
{
|
||||
if (LOG.isDebugEnabled())
|
||||
LOG.debug("{} Idle Low Resources",this);
|
||||
_producing=false;
|
||||
_idle=false;
|
||||
}
|
||||
return false;
|
||||
}
|
||||
Runnable task = _producer.produce();
|
||||
if (LOG.isDebugEnabled())
|
||||
LOG.debug("{} produced {}", _producer, task);
|
||||
|
||||
// Execute the task.
|
||||
execute(task);
|
||||
if (task == null)
|
||||
{
|
||||
// No task, so we are now idle
|
||||
try (Lock locked = _locker.lock())
|
||||
{
|
||||
if (_execute)
|
||||
{
|
||||
_execute = false;
|
||||
_producing = true;
|
||||
_idle = false;
|
||||
continue;
|
||||
}
|
||||
|
||||
_producing = false;
|
||||
idle = _idle = true;
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
// Execute the task.
|
||||
execute(task);
|
||||
}
|
||||
return !idle;
|
||||
}
|
||||
finally
|
||||
{
|
||||
_lowThreads = false;
|
||||
if (LOG.isDebugEnabled())
|
||||
LOG.debug("{} exit low threads mode", this);
|
||||
}
|
||||
if (LOG.isDebugEnabled())
|
||||
LOG.debug("{} No longer Low Resources",this);
|
||||
return true;
|
||||
}
|
||||
|
||||
private void produceConsume()
|
||||
|
||||
private void executeProduceConsume()
|
||||
{
|
||||
if (LOG.isDebugEnabled())
|
||||
LOG.debug("{} produce enter",this);
|
||||
LOG.debug("{} produce enter", this);
|
||||
|
||||
while (true)
|
||||
{
|
||||
// If we got here, then we are the thread that is producing.
|
||||
if (LOG.isDebugEnabled())
|
||||
LOG.debug("{} producing",this);
|
||||
LOG.debug("{} producing", this);
|
||||
|
||||
Runnable task = _producer.produce();
|
||||
|
||||
if (LOG.isDebugEnabled())
|
||||
LOG.debug("{} produced {}",this,task);
|
||||
LOG.debug("{} produced {}", this, task);
|
||||
|
||||
boolean dispatch=false;
|
||||
boolean dispatch = false;
|
||||
try (Lock locked = _locker.lock())
|
||||
{
|
||||
// Finished producing
|
||||
_producing=false;
|
||||
_producing = false;
|
||||
|
||||
// Did we produced a task?
|
||||
if (task == null)
|
||||
|
|
@ -207,14 +232,14 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
|
|||
// Could another one just have been queued with an execute?
|
||||
if (_execute)
|
||||
{
|
||||
_idle=false;
|
||||
_producing=true;
|
||||
_execute=false;
|
||||
_idle = false;
|
||||
_producing = true;
|
||||
_execute = false;
|
||||
continue;
|
||||
}
|
||||
|
||||
// ... and no additional calls to execute, so we are idle
|
||||
_idle=true;
|
||||
_idle = true;
|
||||
break;
|
||||
}
|
||||
|
||||
|
|
@ -223,10 +248,10 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
|
|||
if (!_pending)
|
||||
{
|
||||
// dispatch one
|
||||
dispatch=_pending=true;
|
||||
dispatch = _pending = true;
|
||||
}
|
||||
|
||||
_execute=false;
|
||||
_execute = false;
|
||||
}
|
||||
|
||||
// If we became pending
|
||||
|
|
@ -234,18 +259,18 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
|
|||
{
|
||||
// Spawn a new thread to continue production by running the produce loop.
|
||||
if (LOG.isDebugEnabled())
|
||||
LOG.debug("{} dispatch",this);
|
||||
LOG.debug("{} dispatch", this);
|
||||
if (!execute(this))
|
||||
task=null;
|
||||
task = null;
|
||||
}
|
||||
|
||||
// Run the task.
|
||||
if (LOG.isDebugEnabled())
|
||||
LOG.debug("{} run {}",this,task);
|
||||
LOG.debug("{} run {}", this, task);
|
||||
if (task != null)
|
||||
task.run();
|
||||
if (LOG.isDebugEnabled())
|
||||
LOG.debug("{} ran {}",this,task);
|
||||
LOG.debug("{} ran {}", this, task);
|
||||
|
||||
// Once we have run the task, we can try producing again.
|
||||
try (Lock locked = _locker.lock())
|
||||
|
|
@ -253,15 +278,14 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
|
|||
// Is another thread already producing or we are now idle?
|
||||
if (_producing || _idle)
|
||||
break;
|
||||
_producing=true;
|
||||
_producing = true;
|
||||
}
|
||||
}
|
||||
|
||||
if (LOG.isDebugEnabled())
|
||||
LOG.debug("{} produce exit",this);
|
||||
LOG.debug("{} produce exit", this);
|
||||
}
|
||||
|
||||
|
||||
public Boolean isIdle()
|
||||
{
|
||||
try (Lock locked = _locker.lock())
|
||||
|
|
@ -276,10 +300,10 @@ public class ExecuteProduceConsume extends ExecutingExecutionStrategy implements
|
|||
builder.append("EPC ");
|
||||
try (Lock locked = _locker.lock())
|
||||
{
|
||||
builder.append(_idle?"Idle/":"");
|
||||
builder.append(_producing?"Prod/":"");
|
||||
builder.append(_pending?"Pend/":"");
|
||||
builder.append(_execute?"Exec/":"");
|
||||
builder.append(_idle ? "Idle/" : "");
|
||||
builder.append(_producing ? "Prod/" : "");
|
||||
builder.append(_pending ? "Pend/" : "");
|
||||
builder.append(_execute ? "Exec/" : "");
|
||||
}
|
||||
builder.append(_producer);
|
||||
return builder.toString();
|
||||
|
|
|
|||
|
|
@ -23,6 +23,7 @@ import java.util.concurrent.Executor;
|
|||
import org.eclipse.jetty.util.log.Log;
|
||||
import org.eclipse.jetty.util.log.Logger;
|
||||
import org.eclipse.jetty.util.thread.ExecutionStrategy;
|
||||
import org.eclipse.jetty.util.thread.Locker;
|
||||
|
||||
/**
|
||||
* <p>A strategy where the caller thread iterates over task production, submitting each
|
||||
|
|
@ -32,6 +33,7 @@ public class ProduceConsume implements ExecutionStrategy, Runnable
|
|||
{
|
||||
private static final Logger LOG = Log.getLogger(ExecuteProduceConsume.class);
|
||||
|
||||
private final Locker _locker = new Locker();
|
||||
private final Producer _producer;
|
||||
private final Executor _executor;
|
||||
private State _state = State.IDLE;
|
||||
|
|
@ -45,11 +47,19 @@ public class ProduceConsume implements ExecutionStrategy, Runnable
|
|||
@Override
|
||||
public void execute()
|
||||
{
|
||||
synchronized (this)
|
||||
try (Locker.Lock lock = _locker.lock())
|
||||
{
|
||||
_state = _state == State.IDLE ? State.PRODUCE : State.EXECUTE;
|
||||
if (_state == State.EXECUTE)
|
||||
return;
|
||||
switch(_state)
|
||||
{
|
||||
case IDLE:
|
||||
_state= State.PRODUCE;
|
||||
break;
|
||||
|
||||
case PRODUCE:
|
||||
case EXECUTE:
|
||||
_state= State.EXECUTE;
|
||||
return;
|
||||
}
|
||||
}
|
||||
|
||||
// Iterate until we are complete.
|
||||
|
|
@ -62,12 +72,19 @@ public class ProduceConsume implements ExecutionStrategy, Runnable
|
|||
|
||||
if (task == null)
|
||||
{
|
||||
synchronized (this)
|
||||
try (Locker.Lock lock = _locker.lock())
|
||||
{
|
||||
_state = _state == State.PRODUCE ? State.IDLE : State.PRODUCE;
|
||||
if (_state == State.PRODUCE)
|
||||
continue;
|
||||
return;
|
||||
switch(_state)
|
||||
{
|
||||
case IDLE:
|
||||
throw new IllegalStateException();
|
||||
case PRODUCE:
|
||||
_state= State.IDLE;
|
||||
return;
|
||||
case EXECUTE:
|
||||
_state= State.PRODUCE;
|
||||
continue;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -27,15 +27,12 @@ import java.util.concurrent.Executor;
|
|||
import org.eclipse.jetty.util.BlockingArrayQueue;
|
||||
import org.eclipse.jetty.util.ConcurrentArrayQueue;
|
||||
import org.eclipse.jetty.util.thread.ExecutionStrategy.Producer;
|
||||
import org.hamcrest.Matchers;
|
||||
import org.junit.After;
|
||||
import org.junit.Assert;
|
||||
import org.junit.Before;
|
||||
import org.junit.Test;
|
||||
|
||||
import static org.hamcrest.Matchers.equalTo;
|
||||
import static org.junit.Assert.assertEquals;
|
||||
import static org.junit.Assert.assertThat;
|
||||
|
||||
public class ExecuteProduceConsumeTest
|
||||
{
|
||||
private static final Runnable NULLTASK = () -> {};
|
||||
|
|
@ -80,8 +77,8 @@ public class ExecuteProduceConsumeTest
|
|||
public void after()
|
||||
{
|
||||
// All done and checked
|
||||
assertThat(_produce.size(),equalTo(0));
|
||||
assertThat(_executions.size(),equalTo(0));
|
||||
Assert.assertThat(_produce.size(), Matchers.equalTo(0));
|
||||
Assert.assertThat(_executions.size(), Matchers.equalTo(0));
|
||||
}
|
||||
|
||||
@Test
|
||||
|
|
@ -98,7 +95,7 @@ public class ExecuteProduceConsumeTest
|
|||
_produce.add(t0);
|
||||
_produce.add(NULLTASK);
|
||||
_ewyk.execute();
|
||||
assertThat(t0.hasRun(),equalTo(true));
|
||||
Assert.assertThat(t0.hasRun(), Matchers.equalTo(true));
|
||||
Assert.assertEquals(_ewyk,_executions.poll());
|
||||
}
|
||||
|
||||
|
|
@ -115,7 +112,7 @@ public class ExecuteProduceConsumeTest
|
|||
_ewyk.execute();
|
||||
|
||||
for (Task task : tasks)
|
||||
assertThat(task.hasRun(), equalTo(true));
|
||||
Assert.assertThat(task.hasRun(), Matchers.equalTo(true));
|
||||
Assert.assertEquals(_ewyk,_executions.poll());
|
||||
}
|
||||
|
||||
|
|
@ -137,13 +134,13 @@ public class ExecuteProduceConsumeTest
|
|||
|
||||
// wait for execute thread to block in
|
||||
t0.awaitRun();
|
||||
assertEquals(thread,t0.getThread());
|
||||
Assert.assertEquals(thread,t0.getThread());
|
||||
|
||||
// Should have dispatched only one helper
|
||||
assertEquals(_ewyk,_executions.poll());
|
||||
Assert.assertEquals(_ewyk,_executions.poll());
|
||||
// which is make us idle
|
||||
_ewyk.run();
|
||||
assertThat(_ewyk.isIdle(),equalTo(true));
|
||||
Assert.assertThat(_ewyk.isIdle(), Matchers.equalTo(true));
|
||||
|
||||
|
||||
// unblock task
|
||||
|
|
@ -178,7 +175,7 @@ public class ExecuteProduceConsumeTest
|
|||
t0.unblock();
|
||||
// will run to completion because are become idle
|
||||
thread.join();
|
||||
assertThat(_ewyk.isIdle(),equalTo(true));
|
||||
Assert.assertThat(_ewyk.isIdle(), Matchers.equalTo(true));
|
||||
|
||||
// because we are idle, dispatched thread is noop
|
||||
_ewyk.run();
|
||||
|
|
@ -201,7 +198,7 @@ public class ExecuteProduceConsumeTest
|
|||
|
||||
// wait for execute thread to block in task
|
||||
t0.awaitRun();
|
||||
assertEquals(thread0,t0.getThread());
|
||||
Assert.assertEquals(thread0,t0.getThread());
|
||||
|
||||
// Should have dispatched another helper
|
||||
Assert.assertEquals(_ewyk,_executions.poll());
|
||||
|
|
@ -215,7 +212,7 @@ public class ExecuteProduceConsumeTest
|
|||
Thread.yield();
|
||||
|
||||
// thread1 is blocked in producing
|
||||
assertEquals(thread1,_producer);
|
||||
Assert.assertEquals(thread1,_producer);
|
||||
|
||||
// because we are producing, any other dispatched threads are noops
|
||||
_ewyk.run();
|
||||
|
|
@ -229,7 +226,7 @@ public class ExecuteProduceConsumeTest
|
|||
|
||||
// task will be run by thread1
|
||||
t1.awaitRun();
|
||||
assertEquals(thread1,t1.getThread());
|
||||
Assert.assertEquals(thread1,t1.getThread());
|
||||
|
||||
// and another thread will have been requested
|
||||
Assert.assertEquals(_ewyk,_executions.poll());
|
||||
|
|
@ -240,7 +237,7 @@ public class ExecuteProduceConsumeTest
|
|||
// Now thread1 is producing again
|
||||
while(_producer==null)
|
||||
Thread.yield();
|
||||
assertEquals(thread1,_producer);
|
||||
Assert.assertEquals(thread1,_producer);
|
||||
|
||||
// If we unblock t0, it will decide it is not needed
|
||||
t0.unblock();
|
||||
|
|
@ -254,7 +251,7 @@ public class ExecuteProduceConsumeTest
|
|||
|
||||
// Which will eventually idle the producer
|
||||
thread1.join();
|
||||
assertEquals(null,_producer);
|
||||
Assert.assertEquals(null,_producer);
|
||||
}
|
||||
|
||||
@Test
|
||||
|
|
@ -274,7 +271,7 @@ public class ExecuteProduceConsumeTest
|
|||
|
||||
// wait for execute thread to block in task
|
||||
t0.awaitRun();
|
||||
assertEquals(thread0,t0.getThread());
|
||||
Assert.assertEquals(thread0,t0.getThread());
|
||||
|
||||
// Should have dispatched another helper
|
||||
Assert.assertEquals(_ewyk,_executions.poll());
|
||||
|
|
@ -291,21 +288,21 @@ public class ExecuteProduceConsumeTest
|
|||
// but because there was a pending execute it will try producing again
|
||||
while(_producer==null)
|
||||
Thread.yield();
|
||||
assertEquals(thread0,_producer);
|
||||
Assert.assertEquals(thread0,_producer);
|
||||
|
||||
// and will see new tasks
|
||||
final Task t1 = new Task(true);
|
||||
_produce.add(t1);
|
||||
t1.awaitRun();
|
||||
assertThat(t1.getThread(),equalTo(thread0));
|
||||
Assert.assertThat(t1.getThread(), Matchers.equalTo(thread0));
|
||||
|
||||
// Should NOT have dispatched another helper, because the last is still pending
|
||||
assertThat(_executions.size(),equalTo(0));
|
||||
Assert.assertThat(_executions.size(), Matchers.equalTo(0));
|
||||
|
||||
// When the dispatched thread turns up, it will see the second idle
|
||||
_produce.add(NULLTASK);
|
||||
_ewyk.run();
|
||||
assertThat(_ewyk.isIdle(),equalTo(true));
|
||||
Assert.assertThat(_ewyk.isIdle(), Matchers.equalTo(true));
|
||||
|
||||
// So that when t1 completes it does not produce again.
|
||||
t1.unblock();
|
||||
|
|
|
|||
|
|
@ -202,6 +202,10 @@ public class HttpClientLoadTest extends AbstractTest
|
|||
{
|
||||
start(new LoadHandler());
|
||||
|
||||
client.setByteBufferPool(new LeakTrackingByteBufferPool(new MappedByteBufferPool.Tagged()));
|
||||
client.setMaxConnectionsPerDestination(32768);
|
||||
client.setMaxRequestsQueuedPerDestination(1024 * 1024);
|
||||
|
||||
int runs = 1;
|
||||
int iterations = 256;
|
||||
IntStream.range(0, 16).parallel().forEach(i ->
|
||||
|
|
@ -220,7 +224,9 @@ public class HttpClientLoadTest extends AbstractTest
|
|||
final Thread testThread = Thread.currentThread();
|
||||
Scheduler.Task task = client.getScheduler().schedule(() ->
|
||||
{
|
||||
logger.warn("Interrupting test, it is taking too long{}{}", System.lineSeparator(), client.dump());
|
||||
logger.warn("Interrupting test, it is taking too long{}{}{}{}",
|
||||
System.lineSeparator(), server.dump(),
|
||||
System.lineSeparator(), client.dump());
|
||||
testThread.interrupt();
|
||||
}, iterations * factor, TimeUnit.MILLISECONDS);
|
||||
|
||||
|
|
@ -254,10 +260,10 @@ public class HttpClientLoadTest extends AbstractTest
|
|||
|
||||
// Choose randomly whether to close the connection on the client or on the server
|
||||
boolean clientClose = false;
|
||||
if (!ssl && random.nextBoolean())
|
||||
if (!ssl && random.nextInt(100) < 5)
|
||||
clientClose = true;
|
||||
boolean serverClose = false;
|
||||
if (!ssl && random.nextBoolean())
|
||||
if (!ssl && random.nextInt(100) < 5)
|
||||
serverClose = true;
|
||||
|
||||
int maxContentLength = 64 * 1024;
|
||||
|
|
@ -330,7 +336,11 @@ public class HttpClientLoadTest extends AbstractTest
|
|||
}
|
||||
});
|
||||
if (!await(requestLatch, 5, TimeUnit.SECONDS))
|
||||
logger.warn("Request {} took too long", requestId);
|
||||
{
|
||||
logger.warn("Request {} took too long{}{}{}{}", requestId,
|
||||
System.lineSeparator(), server.dump(),
|
||||
System.lineSeparator(), client.dump());
|
||||
}
|
||||
}
|
||||
|
||||
private boolean await(CountDownLatch latch, long time, TimeUnit unit)
|
||||
|
|
|
|||
Loading…
Reference in New Issue