![]() Version: 9.3.10.M0 |
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-@project.version@]$ java -jar start.jar 2013-09-23 11:27:06.654:INFO:oejs.Server:main: jetty-@project.version@ ...
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:
Starting with Jetty 9.1 you have more options on how to configure Jetty (these are merely syntactic sugar that eventually resolve into the two basic configuration components).
Jetty 9.1 Startup Features include:
${jetty.home}
and
the environment specific configurations (and binaries) found in
${jetty.base}
(detailed in
Managing Jetty Base and Jetty
Home.)All of the pre-built XML configuration files shipped in Jetty are now
parameterized with properties that you can specify in your
${jetty.base}/start.ini
(demonstrated in
Quick Start Configuration).
There is no longer a
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.
${jetty.base}/start.d/*.ini
as
command line arguments.${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}.
Uses default behavior of java.io.File.
(Relative to System.getProperty
("user.dir") and then as absolute file
system path)
Determines run mode:
If you want to start Jetty:
Lists the resolved configuration that will start Jetty. +
start.jar
should use to start
a forked instance of Jetty.${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.${jetty.base}/start.ini.
${jetty.base}/start.ini
file.
+
The lines that are added are provided by the module-defined INI
templates.
+
Note: Transitive modules are also appended.${jetty.base}/start.d/
directory.
+
The content of the new INI is provided by the module-defined ini
templates.
+
Note: Transitive modules are also created in the same directory as
their own INI files.${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 http://graphviz.org/[graphviz.org] for details on http://graphviz.org/content/command-line-invocation[how to post-process this dotty file] into the output best suited for your needs.
Sends a stop signal to the running Jetty instance. + Note: The server must have been started with various stop properties for this to work. +