Version: 9.4.5.v20170502 |
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 for sponsored feature development
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.
[jetty-distribution-9.4.5.v20170502]$ java -jar start.jar 2013-09-23 11:27:06.654:INFO:oejs.Server:main: jetty-9.4.5.v20170502 ...
Jetty is a highly modularized web server container. Very little is mandatory and required, and most components are optional; you enable or disable them according to the needs of your environment.
At its most basic, you configure Jetty from two elements:
Instead of editing these directly, Jetty 9.1 introduced more options on how to configure Jetty (these are merely syntactic sugar that eventually resolve into the two basic configuration components).
Jetty Startup Features include:
${jetty.home}
and the environment specific configurations (and binaries) found in ${jetty.base}
(detailed in Managing Jetty Base and Jetty Home.)${jetty.base}/start.ini
(demonstrated in Quick Start Configuration).These are powerful new features, made to support a variety of styles of configuring Jetty, from a simple property based configuration, to handling multiple installations on a server, to customized stacks of technology on top of Jetty, and even the classic, custom XML configurations of old.
For example, if you use the ${jetty.base}
concepts properly, you can upgrade the Jetty distribution without having to remake your entire tree of modifications to Jetty.
Simply separate out your specific modifications to the ${jetty.base}
, and in the future, just upgrade your ${jetty.home}
directory with a new Jetty distribution.
When executed start.jar
performs the following actions:
${jetty.base}/start.d/*.ini
as command line arguments.Loads and parses ${jetty.base}/start.ini
as command line arguments.
start.jar
itself.Resolves any XML configuration files, modules, and libraries using base vs. home resolution steps:
${jetty.base}.
${jetty.home}.
java.io.File
(Relative to System.getProperty
("user.dir") and then as absolute file system path).Determines run mode:
Lists the resolved configuration that will start Jetty.
start.jar
should use to start a forked instance of Jetty.start.jar
to use each line of the specified file as arguments on the command line.Enables debugging output of the startup procedure.
Note: This does not set up debug logging for Jetty itself. For information on logging, please see the section on Configuring Jetty Logging.
${jetty.base}
.
This is useful for capturing startup issues where the Jetty-specific logger has not yet kicked in due to a possible startup configuration error.${jetty.base}
and ${jetty.home}
resolution logic.
Also lists enabled state based on information present on the command line, and all active startup INI files.--list-modules
to see the list of available modules).
This enables all transitive (dependent) modules from the module system as well.
If you use this from the shell command line, it is considered a temporary effect, useful for testing out a scenario.
If you want this module to always be enabled, add this command to your ${jetty.base}/start.ini.
Enables a module by appending lines to the ${jetty.base}/start.ini
file.
The lines that are added are provided by the module-defined INI templates.
Note: Transitive modules are also appended.
If a module contains an .ini template with properties, you can also edit these properties when activating the module.
To do this, simply list the property and its value after the -add-to-start
command, such as in the following example:
$ java -jar start.jar --add-to-start=http jetty.http.port=8379 jetty.http.host=1.2.3.4
Doing this will uncomment the property in the associated .ini file and set it to the value specified.
Used to update a specified property or properties that exist in an existing .ini file.
Jetty scans the command line, ${jetty.base}
and ${jetty.home}
for .ini files that have the specified property and update it accordingly.
$ java -jar ../start.jar --update-ini jetty.http.port=8417 ConfigSource <command-line> ConfigSource ${jetty.base} INFO : http property updated jetty.http.port=8417 INFO : http updated ${jetty.base}/start.d/http.ini ConfigSource ${jetty.home}
${jetty.base}/start.d/
directory.
If a ${jetty.base}/start.ini
file already exists, it is copied to the ${jetty.base}/start.d
directory.With respect to start.ini
and start.d/*.ini
files, only one of these methods should be implemented.
Mixing a start.ini
with module specific ini files in the {$jetty.base}/start.d
directory can lead to server issues unless great care is taken.
Please see Start.ini vs. Start.d for more information.
Advanced feature: Creates a graphviz dot file of the module graph as it exists for the active ${jetty.base}
.
# generate module.dot $ java -jar start.jar --module=websocket --write-module-graph=modules.dot # post process to a PNG file $ dot -Tpng -o modules.png modules.dot
See graphviz.org for details on how to post-process this dotty file into the output best suited for your needs.
${jetty.base}
directory for a specific module.
Useful for modules that have downloadable content that is being overridden with alternatives in the ${jetty.base}`
directory.Caution
This advanced option is for administrators that fully understand the configuration of their
${jetty.base}
and are willing to forego some of the safety checks built into the jetty-start mechanism.
Sends a stop signal to the running Jetty instance.
Note: The server must have been started with various stop properties for this to work.
The port to use to stop the running Jetty server. This is an internal port, opened on localhost, used solely for stopping the running Jetty server. Choose a port that you do not use to serve web traffic.
Required for --stop to function.
The passphrase defined to stop the server.
Required for --stop to function.
The time (in seconds) to wait for confirmation that the running Jetty server has stopped. If not specified, the stopper waits indefinitely for the server to stop.
If the time specified elapses, without a confirmation of server stop, then the --stop
command exits with a non-zero return code.
${jetty.base}
but sits at a layer between ${jetty.base}
and ${jetty.home}
.
This allows for some complex hierarchies of configuration details.${jetty.base}
.
You might need to escape the slash "\|" to use this on some environments.