Merge branch 'jetty-9.3.x' into jetty-9.4.x
This commit is contained in:
Jesse McConnell
commit
55d9ba9307
|
|
@ -17,15 +17,13 @@
|
|||
[[startup-unix-service]]
|
||||
=== Startup a Unix Service using jetty.sh
|
||||
|
||||
The Standalone Jetty distribution ships with a `bin/jetty.sh` script
|
||||
that can be used by various Unix (including OSX) to manage jetty
|
||||
startup.
|
||||
The standalone Jetty distribution ships with a `bin/jetty.sh` script that can be used by various Unix distros (including OSX) to manage Jetty as a startup service.
|
||||
|
||||
This script is suitable for setting up Jetty as a service in Unix.
|
||||
|
||||
==== Quick-Start a Jetty Service
|
||||
|
||||
The minimum steps to get Jetty to run as a Service
|
||||
The minimum steps to get Jetty to run as a Service include:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
|
|
@ -45,20 +43,15 @@ JETTY_HOME=/opt/jetty/jetty-distribution-{VERSION}
|
|||
Starting Jetty: OK Wed Nov 20 10:26:53 MST 2013
|
||||
....
|
||||
|
||||
From this simple demonstration we can see that Jetty started
|
||||
successfully as a Unix Service from the
|
||||
`/opt/jetty/jetty-distribution-{VERSION}` directory.
|
||||
From this demonstration we can see that Jetty started successfully as a Unix Service from the `/opt/jetty/jetty-distribution-{VERSION}` directory.
|
||||
|
||||
This looks all fine and dandy, however you are running a default Jetty
|
||||
on the root user id.
|
||||
This configuration works well but it is running Jetty as the root user.
|
||||
|
||||
==== Practical Setup of a Jetty Service
|
||||
|
||||
There are various ways this can be accomplished, mostly depending on
|
||||
your Unix environment (and possibly corporate policies)
|
||||
There are various ways this can be accomplished, mostly depending on your Unix environment (and possibly corporate policies).
|
||||
|
||||
The techniques outlined here assume an installation on Linux
|
||||
(demonstrated on Ubuntu 12.04.3 LTS).
|
||||
The techniques outlined here assume an installation on Linux (demonstrated on Ubuntu 12.04.3 LTS).
|
||||
|
||||
Prepare some empty directories to work with.
|
||||
|
||||
|
|
@ -72,30 +65,24 @@ Prepare some empty directories to work with.
|
|||
The directory purposes are as follows:
|
||||
|
||||
/opt/jetty::
|
||||
Where the Jetty Distribution will be unpacked into
|
||||
Where the Jetty Distribution will be unpacked into
|
||||
/opt/web/mybase::
|
||||
Where your specific set of webapps will be located, including all of
|
||||
the configuration required of the server to make them operational.
|
||||
Where your specific set of webapps will be located, including all of the configuration required of the server to make them operational.
|
||||
/opt/jetty/temp::
|
||||
This is the temporary directory assigned to Java by the Service Layer
|
||||
(this is what Java sees as the `java.io.tmpdir` System Property)
|
||||
+
|
||||
This is intentionally kept separate from the standard temp directory
|
||||
of `/tmp`, as this location doubles as the Servlet Spec work
|
||||
directory. (It is our experience that the standard temp directory is
|
||||
often managed by various cleanup scripts that wreak havoc on a long
|
||||
running Jetty server
|
||||
This is the temporary directory assigned to Java by the Service Layer (this is what Java sees as the `java.io.tmpdir` System Property).
|
||||
+
|
||||
This is intentionally kept separate from the standard temp directory of `/tmp`, as this location doubles as the Servlet Spec work directory.
|
||||
It is our experience that the standard temp directory is often managed by various cleanup scripts that wreak havoc on a long running Jetty server.
|
||||
|
||||
Jetty $\{project.version} requires Java 7 (or greater) to run. Make sure
|
||||
you have it installed.
|
||||
Jetty 9.3 requires Java 8 (or greater) to run.
|
||||
Make sure you have it installed.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
# apt-get install openjdk-7-jdk
|
||||
....
|
||||
|
||||
Or download Java 7 from:
|
||||
http://www.oracle.com/technetwork/java/javase/downloads/index.html
|
||||
Or download Java 7 from: http://www.oracle.com/technetwork/java/javase/downloads/index.html
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
|
|
@ -126,20 +113,17 @@ OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1ubuntu0.12.04.2)
|
|||
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.
|
||||
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, subs="{sub-order}"]
|
||||
....
|
||||
# useradd --user-group --shell /bin/false --home-dir /opt/jetty/temp jetty
|
||||
....
|
||||
|
||||
This will create a user called `jetty`, belonging to the group called
|
||||
`jetty`, with no shell access (aka `/bin/false`), and home directory at
|
||||
`/opt/jetty/temp`.
|
||||
This will create a user called `jetty`, belonging to the group called `jetty`, with no shell access (aka `/bin/false`), and home directory at `/opt/jetty/temp`.
|
||||
|
||||
Grab a copy of the distribution from the
|
||||
link:#jetty-downloading[Official Eclipse Download Site]
|
||||
Download a copy of the Jetty distribution from the link:#jetty-downloading[Official Eclipse Download Site]
|
||||
|
||||
Unpack it into place.
|
||||
|
||||
|
|
@ -151,25 +135,21 @@ jetty-distribution-{VERSION}/
|
|||
[/opt/jetty]# mkdir /opt/jetty/temp
|
||||
....
|
||||
|
||||
It might seem strange or undesirable to unpack the first portion of the
|
||||
jetty-distribution directory name too. But starting with Jetty 9.1 the
|
||||
split between `${jetty.home}` and `${jetty.base}` allows for easier
|
||||
upgrades of Jetty itself while isolating your webapp specific
|
||||
configuration.
|
||||
It might seem strange or undesirable to unpack the first portion of the jetty-distribution directory name too.
|
||||
But starting with Jetty 9.1 the split between `${jetty.home}` and `${jetty.base}` allows for easier upgrades of Jetty itself while isolating your webapp specific configuration.
|
||||
For more information on the Jetty home and base concepts see the section on managing a Jetty installation <<startup-base-and-home, earlier in this Chapter.>>
|
||||
|
||||
The `/opt/jetty/temp` directory is created as a durable place for Jetty
|
||||
to use for temp and working directories. Many Unix systems will
|
||||
periodically clean out the /tmp directory, this behavior is undesired in
|
||||
a Servlet container and has been known to cause problems. This durable
|
||||
directory at `/opt/jetty/temp` solves for that behavior.
|
||||
The `/opt/jetty/temp` directory is created as a durable place for Jetty to use for temp and working directories.
|
||||
Many Unix systems will periodically clean out the /tmp directory, this behavior is undesired in a Servlet container and has been known to cause problems.
|
||||
This durable directory at `/opt/jetty/temp` solves for that behavior.
|
||||
|
||||
The directory at `/opt/web/mybase` is going to be a `${jetty.base}`, so
|
||||
lets configure it to hold your webapp and its configuration.
|
||||
The directory at `/opt/web/mybase` is going to be a `${jetty.base}`, so lets configure it to hold your webapp and its configuration.
|
||||
|
||||
____
|
||||
[TIP]
|
||||
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.
|
||||
____
|
||||
--
|
||||
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, subs="{sub-order}"]
|
||||
....
|
||||
|
|
@ -190,24 +170,19 @@ WARNING: logging enabled in ${jetty.base}/start.ini
|
|||
start.ini webapps/
|
||||
....
|
||||
|
||||
At this point you have configured your `/opt/web/mybase` to enable the
|
||||
following modules:
|
||||
At this point you have configured your `/opt/web/mybase` to enable the following modules:
|
||||
|
||||
deploy::
|
||||
This is the module that will perform deployment of web applications
|
||||
(WAR files or exploded directories), or Jetty IoC XML context
|
||||
deployables, from the `/opt/web/mybase/webapps` directory.
|
||||
This is the module that will perform deployment of web applications (WAR files or exploded directories), or Jetty IoC XML context deployables, from the `/opt/web/mybase/webapps` directory.
|
||||
http::
|
||||
This sets up a single Connector that listens for basic HTTP requests.
|
||||
+
|
||||
See the created `start.ini` for configuring this connector
|
||||
This sets up a single Connector that listens for basic HTTP requests.
|
||||
+
|
||||
See the created `start.ini` for configuring this connector.
|
||||
logging::
|
||||
When running Jetty as a service it is very important to have logging
|
||||
enabled. This module will enable the basic STDOUT and STDERR capture
|
||||
logging to the `/opt/web/mybase/logs/` directory.
|
||||
When running Jetty as a service it is very important to have logging enabled.
|
||||
This module will enable the basic STDOUT and STDERR capture logging to the `/opt/web/mybase/logs/` directory.
|
||||
|
||||
See xref:start-jar[] for more details and options on setting
|
||||
up and configuring a `${jetty.base}` directory.
|
||||
See xref:start-jar[] for more details and options on setting up and configuring a `${jetty.base}` directory.
|
||||
|
||||
Copy your war file into place.
|
||||
|
||||
|
|
@ -216,12 +191,9 @@ Copy your war file into place.
|
|||
# cp /home/user/projects/mywebsite.war /opt/web/mybase/webapps/
|
||||
....
|
||||
|
||||
Most service installations will want jetty to run on port 80, now is
|
||||
your opportunity to change this from the default value of `8080` to
|
||||
`80`.
|
||||
Most service installations will want Jetty to run on port 80, now is the opportunity to change this from the default value of `8080` to `80`.
|
||||
|
||||
Edit the `/opt/web/mybase/start.ini` and change the `jetty.http.port`
|
||||
value.
|
||||
Edit the `/opt/web/mybase/start.ini` and change the `jetty.http.port` value.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
|
|
@ -229,8 +201,7 @@ value.
|
|||
jetty.port=80
|
||||
....
|
||||
|
||||
Change the permissions on the Jetty distribution, and your webapp
|
||||
directories so that the user you created can access it.
|
||||
Change the permissions on the Jetty distribution and webapp directories so that the user you created can access it.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
|
|
@ -238,8 +209,7 @@ directories so that the user you created can access it.
|
|||
# chown --recursive jetty /opt/web/mybase
|
||||
....
|
||||
|
||||
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.
|
||||
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, subs="{sub-order}"]
|
||||
....
|
||||
|
|
@ -249,12 +219,12 @@ Service that can be managed by the standard `service` calls.
|
|||
# echo "TMPDIR=/opt/jetty/temp" >> /etc/default/jetty
|
||||
....
|
||||
|
||||
Test out the configuration
|
||||
Test out the configuration:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
# service jetty status
|
||||
Checking arguments to Jetty:
|
||||
Checking arguments to Jetty:
|
||||
START_INI = /opt/web/mybase/start.ini
|
||||
JETTY_HOME = /opt/jetty/jetty-distribution-{VERSION}
|
||||
JETTY_BASE = /opt/web/mybase
|
||||
|
|
@ -262,30 +232,28 @@ JETTY_CONF = /opt/jetty/jetty-distribution-{VERSION}/etc/jetty.conf
|
|||
JETTY_PID = /var/run/jetty.pid
|
||||
JETTY_START = /opt/jetty/jetty-distribution-{VERSION}/start.jar
|
||||
JETTY_LOGS = /opt/web/mybase/logs
|
||||
CLASSPATH =
|
||||
CLASSPATH =
|
||||
JAVA = /usr/bin/java
|
||||
JAVA_OPTIONS = -Djetty.state=/opt/web/mybase/jetty.state
|
||||
JAVA_OPTIONS = -Djetty.state=/opt/web/mybase/jetty.state
|
||||
-Djetty.logs=/opt/web/mybase/logs
|
||||
-Djetty.home=/opt/jetty/jetty-distribution-{VERSION}
|
||||
-Djetty.base=/opt/web/mybase
|
||||
-Djetty.base=/opt/web/mybase
|
||||
-Djava.io.tmpdir=/opt/jetty/temp
|
||||
JETTY_ARGS = jetty-logging.xml jetty-started.xml
|
||||
RUN_CMD = /usr/bin/java
|
||||
-Djetty.state=/opt/web/mybase/jetty.state
|
||||
-Djetty.logs=/opt/web/mybase/logs
|
||||
RUN_CMD = /usr/bin/java
|
||||
-Djetty.state=/opt/web/mybase/jetty.state
|
||||
-Djetty.logs=/opt/web/mybase/logs
|
||||
-Djetty.home=/opt/jetty/jetty-distribution-{VERSION}
|
||||
-Djetty.base=/opt/web/mybase
|
||||
-Djetty.base=/opt/web/mybase
|
||||
-Djava.io.tmpdir=/opt/jetty/temp
|
||||
-jar /opt/jetty/jetty-distribution-{VERSION}/start.jar
|
||||
jetty-logging.xml
|
||||
jetty-logging.xml
|
||||
jetty-started.xml
|
||||
....
|
||||
|
||||
You now have a configured `${jetty.base}` in `/opt/web/mybase` and a
|
||||
jetty-distribution in `/opt/jetty/jetty-distribution-{VERSION}`,
|
||||
along with the service level files necessary to start the service.
|
||||
You now have a configured `${jetty.base}` in `/opt/web/mybase` and a jetty-distribution in `/opt/jetty/jetty-distribution-{VERSION}`, along with the service level files necessary to start the service.
|
||||
|
||||
Go ahead, start it.
|
||||
Test the service to make sure it starts up and runs successfully.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
|
|
|
|||
|
|
@ -17,15 +17,11 @@
|
|||
[[startup-windows-service]]
|
||||
=== Startup via Windows Service
|
||||
|
||||
There are no components that ship with the Jetty Distribution to make it
|
||||
a formal Windows Service.
|
||||
There are no components that ship with the Jetty Distribution to make it a formal Windows Service.
|
||||
|
||||
However, we recommend the use of
|
||||
https://commons.apache.org/proper/commons-daemon/procrun.html[Apache
|
||||
ProcRun's Daemon].
|
||||
However, we recommend the use of https://commons.apache.org/proper/commons-daemon/procrun.html[Apache ProcRun's Daemon].
|
||||
|
||||
The techniques outlined here are based on Windows 7 (64-bit), using JDK
|
||||
7 (64-bit), running on an Intel i7 architecture machine.
|
||||
The techniques outlined here are based on Windows 7 (64-bit), using JDK 8 (64-bit), running on an Intel i7 architecture machine.
|
||||
|
||||
Prepare some empty directories to work with.
|
||||
|
||||
|
|
@ -37,7 +33,7 @@ C:\opt> mkdir jetty
|
|||
C:\opt> mkdir logs
|
||||
C:\opt> mkdir myappbase
|
||||
C:\opt> mkdir temp
|
||||
C:\opt> dir
|
||||
C:\opt> dir
|
||||
Volume in drive C has no label.
|
||||
Volume Serial Number is DEAD-BEEF
|
||||
|
||||
|
|
@ -55,28 +51,21 @@ C:\opt> dir
|
|||
The directory purposes are as follows:
|
||||
|
||||
C:\opt::
|
||||
Where the service layer utilities, scripts, and binaries will
|
||||
eventually be
|
||||
Where the service layer utilities, scripts, and binaries will eventually be.
|
||||
C:\opt\logs::
|
||||
Where the logs for the service layer will put its own logs.
|
||||
+
|
||||
Typically you will see the audit logs (install/update/delete),
|
||||
StdOutput, and StdError logs here.
|
||||
Where the logs for the service layer will put its own logs.
|
||||
+
|
||||
Typically you will see the audit logs (install/update/delete), StdOutput, and StdError logs here.
|
||||
C:\opt\jetty::
|
||||
Where the Jetty Distribution will be unpacked into
|
||||
Where the Jetty Distribution will be unpacked into.
|
||||
C:\opt\myappbase::
|
||||
Where your specific set of webapps will be located, including all of
|
||||
the configuration required of the server to make them operational.
|
||||
Where your specific set of webapps will be located, including all of the configuration required of the server to make them operational.
|
||||
C:\opt\temp::
|
||||
This is the temporary directory assigned to Java by the Service Layer
|
||||
(this is what Java sees as the `java.io.tmpdir` System Property)
|
||||
+
|
||||
This is intentionally kept separate from the standard temp directories
|
||||
of Windows, as this location doubles as the Servlet Spec work
|
||||
directory.
|
||||
This is the temporary directory assigned to Java by the Service Layer (this is what Java sees as the `java.io.tmpdir` System Property).
|
||||
+
|
||||
This is intentionally kept separate from the standard temp directories of Windows, as this location doubles as the Servlet Spec work directory.
|
||||
|
||||
Or download Java 7 from:
|
||||
http://www.oracle.com/technetwork/java/javase/downloads/index.html
|
||||
Or download Java 8 from: http://www.oracle.com/technetwork/java/javase/downloads/index.html
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
|
|
@ -86,15 +75,11 @@ Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
|
|||
Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
|
||||
....
|
||||
|
||||
Grab a copy of the ZIP distribution from the
|
||||
link:#jetty-downloading[Official Eclipse Download Site]
|
||||
Download a copy of the ZIP distribution from the link:#jetty-downloading[Official Eclipse Download Site]
|
||||
|
||||
Open it up the downloaded Zip in Windows Explorer and drag the contents
|
||||
of the `jetty-distribution-{VERSION}` directory into place at
|
||||
`C:\opt\jetty`
|
||||
Extract the contents of the `jetty-distribution-{VERSION}` directory to `C:\opt\jetty`
|
||||
|
||||
Once you are complete, the contents of the `C:\opt\jetty` directory
|
||||
should look like this:
|
||||
Once complete, the contents of the `C:\opt\jetty` directory should look like this:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
|
|
@ -125,27 +110,19 @@ C:\opt\jetty>dir
|
|||
11 Dir(s) 306,711,420,928 bytes free
|
||||
....
|
||||
|
||||
Download a copy of the
|
||||
https://commons.apache.org/proper/commons-daemon/binaries.html[native
|
||||
binaries] of
|
||||
https://commons.apache.org/proper/commons-daemon/binaries.html[Apache
|
||||
ProcRun].
|
||||
Download a copy of the https://commons.apache.org/proper/commons-daemon/binaries.html[Apache ProcRun] native binaries.
|
||||
|
||||
You should have downloaded a file named
|
||||
`commons-daemon-1.0.15-bin-windows.zip` (version might be different).
|
||||
Open this ZIP file in Windows Explorer and drag `prunmgr.exe` and
|
||||
`prunsrv.exe` files into the `C:\opt` directory.
|
||||
You should have downloaded a file named `commons-daemon-1.0.15-bin-windows.zip` (the version might be different).
|
||||
Open the ZIP file and extract the `prunmgr.exe` and `prunsrv.exe` files into the `C:\opt` directory.
|
||||
|
||||
Make sure to get the right version of `prunsrv.exe` for your
|
||||
environment. The ZIP file has both 32 bit and 64 bit versions of this
|
||||
file.
|
||||
Make sure to get the right version of `prunsrv.exe` for your environment.
|
||||
The ZIP file has both 32 bit and 64 bit versions of this file.
|
||||
|
||||
Once you are complete, the contents of `C:\opt` directory should look
|
||||
like this:
|
||||
Once you are complete, the contents of `C:\opt` directory should look like this:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
C:\opt> dir
|
||||
C:\opt> dir
|
||||
Volume in drive C has no label.
|
||||
Volume Serial Number is DEAD-BEEF
|
||||
|
||||
|
|
@ -162,11 +139,9 @@ C:\opt> dir
|
|||
2 File(s) 185,344 bytes
|
||||
....
|
||||
|
||||
Now it's time to setup your new `${jetty.base}` directory to have all of
|
||||
your WebApps and the configurations that they need.
|
||||
Now it's time to setup your new `${jetty.base}` directory to have all of 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)
|
||||
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, subs="{sub-order}"]
|
||||
....
|
||||
|
|
@ -199,44 +174,34 @@ C:\opt\myappbase>dir
|
|||
4 Dir(s) 306,711,064,576 bytes free
|
||||
....
|
||||
|
||||
At this point you have configured your `C:\opt\myappbase` to enable the
|
||||
following modules:
|
||||
At this point you have configured your `C:\opt\myappbase` to enable the following modules:
|
||||
|
||||
deploy::
|
||||
This is the module that will perform deployment of web applications
|
||||
(WAR files or exploded directories), or Jetty IoC XML context
|
||||
deployables, from the `C:\opt\myappbase\webapps` directory.
|
||||
This is the module that will perform deployment of web applications (WAR files or exploded directories), or Jetty IoC XML context deployables, from the `C:\opt\myappbase\webapps` directory.
|
||||
http::
|
||||
This sets up a single Connector that listens for basic HTTP requests.
|
||||
+
|
||||
See the created `start.ini` for configuring this connector
|
||||
This sets up a single Connector that listens for basic HTTP requests.
|
||||
+
|
||||
See the created `start.ini` for configuring this connector.
|
||||
logging::
|
||||
When running Jetty as a service it is very important to have logging
|
||||
enabled. This module will enable the basic STDOUT and STDERR capture
|
||||
logging to the `C:\opt\myappbase\logs` directory.
|
||||
When running Jetty as a service it is very important to have logging enabled.
|
||||
This module will enable the basic STDOUT and STDERR capture logging to the `C:\opt\myappbase\logs` directory.
|
||||
|
||||
See xref:start-jar[] for more details and options on setting
|
||||
up and configuring a `${jetty.base}` directory.
|
||||
See the section on xref:start-jar[] for more details and options on setting up and configuring a `${jetty.base}` directory.
|
||||
|
||||
At this point you merely have to copy your WAR files into the webapps
|
||||
directory.
|
||||
At this point you merely have to copy your WAR files into the `{$jetty.base}/webapps` directory.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
C:\opt\myappbase> copy C:\projects\mywebsite.war webapps\
|
||||
....
|
||||
|
||||
At this point you should have your directories, Java, the Jetty
|
||||
distribution, and your webapp specifics setup and ready for operation.
|
||||
At this point you should have your directories, Java, the Jetty distribution, and your webapp specifics setup and ready for operation.
|
||||
|
||||
We will use the
|
||||
https://commons.apache.org/proper/commons-daemon/binaries.html[Apache
|
||||
ProcRun's prunsrv.exe] to install a Jetty Service.
|
||||
We will use the https://commons.apache.org/proper/commons-daemon/binaries.html[Apache ProcRun's prunsrv.exe] to install a Jetty Service.
|
||||
|
||||
The basic command line syntax is outlined in the link above.
|
||||
|
||||
A example `install-jetty-service.bat` is provided here as an example,
|
||||
based on the above directories.
|
||||
A example `install-jetty-service.bat` is provided here as an example, based on the above directories.
|
||||
|
||||
[source,bat]
|
||||
----
|
||||
|
|
@ -315,20 +280,16 @@ echo The Service "%SERVICE_NAME%" has been installed
|
|||
Configuration's of note in this batch file:
|
||||
|
||||
SERVICE_NAME::
|
||||
This is the name of the service that Windows sees. The name in the
|
||||
Services window will show this name.
|
||||
This is the name of the service that Windows sees.
|
||||
The name in the Services window will show this name.
|
||||
STOPKEY::
|
||||
This is the secret key (password) for the ShutdownMonitor, used to
|
||||
issue a formal command to stop the server.
|
||||
This is the secret key (password) for the ShutdownMonitor, used to issue a formal command to stop the server.
|
||||
STOPPORT::
|
||||
The port that the Shutdown Monitor listens on for the stop command.
|
||||
+
|
||||
If you have multiple Jetty servers on the same machine, this port will
|
||||
need to be different for each Service.
|
||||
The port that the Shutdown Monitor listens on for the stop command.
|
||||
+
|
||||
If you have multiple Jetty servers on the same machine, this port will need to be different for each Service.
|
||||
|
||||
Once you have run `prunsrv.exe //IS/<service-name>` (done for you in the
|
||||
above batch file) to install the service, you can use the standard
|
||||
Windows utilities to manage (start/stop/restart) the Jetty service.
|
||||
Once you have run `prunsrv.exe //IS/<service-name>` (done for you in the above batch file) to install the service, you can use the standard Windows utilities to manage (start/stop/restart) the Jetty service.
|
||||
|
||||
Open the Service View and start your service.
|
||||
|
||||
|
|
|
|||
|
|
@ -23,10 +23,8 @@ This document provides information about configuring Java Server Pages (JSP) for
|
|||
==== Which JSP Implementation
|
||||
|
||||
As of Jetty 9.2, Jetty is using Jasper from http://tomcat.apache.org/tomcat-8.0-doc/jasper-howto.html[Apache] as the default JSP container implementation.
|
||||
In previous versions Jasper from http://jsp.java.net[Glassfish] was used, and if you wish to, you can continue to do so.
|
||||
|
||||
By default the Jetty distribution enables the JSP link:#startup-modules[module], and by default, this link:#startup-modules[module] is set to Apache Jasper.
|
||||
To change to use Glassfish Jasper instead, edit the `{jetty.home}/modules/jsp.mod` file and change the line indicated:
|
||||
|
||||
[source, plain, subs="{sub-order}"]
|
||||
----
|
||||
|
|
@ -40,7 +38,7 @@ Note also that it may not be possible to precompile your JSPs with one container
|
|||
|
||||
If you have an embedded setup for your webapp and wish to use JSPs, you will need to ensure that a JSP engine is correctly initialized.
|
||||
|
||||
For both Apache and Glassfish JSP engines, a Servlet Specification 3.1 style link:#servlet-container-initializers[ServletContainerInitializer] is used to accomplish this.
|
||||
For Apache, a Servlet Specification 3.1 style link:#servlet-container-initializers[ServletContainerInitializer] is used to accomplish this.
|
||||
You will need to ensure that this ServletContainerInitializer is run by jetty. Perhaps the easiest way to do this is to enable annotations processing so that Jetty automatically discovers and runs it.
|
||||
The link:#embedded-examples[Embedded Examples] section includes a link:#embedded-webapp-jsp[worked code example] of how to do this.
|
||||
|
||||
|
|
@ -48,7 +46,7 @@ Alternatively, you can manually wire in the appropriate ServletContainerInitiali
|
|||
|
||||
==== Precompiling JSPs
|
||||
|
||||
You can either follow the instructions on precompilation provided by the JSP container of your choice (either http://jsp.java.net[Glassfish] or http://tomcat.apache.org/tomcat-8.0-doc/jasper-howto.html[Apache]), or if you are using maven for your builds, you can use the link:#jetty-jspc-maven-plugin[jetty-jspc-maven] plugin to do it for you.
|
||||
You can either follow the instructions on precompilation provided by Apache, or if you are using Maven for your builds, you can use the link:#jetty-jspc-maven-plugin[jetty-jspc-maven] plugin to do it for you.
|
||||
|
||||
If you have precompiled your JSPs, and have customized the output package prefix (which is `org.apache.jsp` by default), you should configure your webapp context to tell Jetty about this custom package name.
|
||||
You can do this using a servlet context init-param called `org.eclipse.jetty.servlet.jspPackagePrefix`.
|
||||
|
|
@ -69,10 +67,6 @@ Both Jetty Maven plugins - link:#jetty-jspc-maven-plugin[jetty-jspc-maven-plugin
|
|||
____
|
||||
|
||||
[[compiling-jsps]]
|
||||
==== Runtime Compiling JSPs
|
||||
|
||||
Depending on which JSP container you elect to use, the configuration and compilation characteristics will be different.
|
||||
|
||||
===== Apache JSP Container
|
||||
|
||||
By default, the Apache JSP container will look for the Eclipse Java Compiler (jdt).
|
||||
|
|
@ -168,26 +162,6 @@ default as compilation may be expensive and could lead to excessive
|
|||
resource usage. |- |–
|
||||
|=======================================================================
|
||||
|
||||
===== Glassfish JSP Container
|
||||
|
||||
To compile `.jsp` files into Java classes, you need a Java compiler.
|
||||
You can acquire a Java compiler from the JVM if you are using a full JDK, or from a third party Jar.
|
||||
|
||||
By default, the Glassfish JSP container tries to use the compiler that is part of the JDK.
|
||||
*NOTE:* when using the JDK compiler, the system does _not_ save your class files to disk unless you use the `saveBytecode` init-param as described below.
|
||||
|
||||
If you do not have a full JDK, you can configure the Eclipse Java Compiler that Jetty ships in the distro in `{$jetty.home}/lib/jsp/.`
|
||||
You need to define a SystemProperty that prevents the Glassfish JSP engine from defaulting to the in-JVM compiler.
|
||||
|
||||
// This is best done when using the standalone distro by uncommenting the System property `org.apache.jasper.compiler.disablejsr199` in the jsp link:#startup-modules[module]:
|
||||
//
|
||||
// [source,text]
|
||||
// ----
|
||||
// -Dorg.apache.jasper.compiler.disablejsr199=true
|
||||
// ----
|
||||
|
||||
For embedded usages, simply define this as a normal System property.
|
||||
|
||||
[[configuring-jsp-for-jetty]]
|
||||
===== Configuration
|
||||
|
||||
|
|
@ -202,141 +176,9 @@ ____
|
|||
Be careful: for all of these parameters, if the value you set doesn't take effect, try using all lower case instead of camel case, or capitalizing only some of the words in the name, as JSP is inconsistent in its parameter naming strategy.
|
||||
____
|
||||
|
||||
.Understanding Glassfish JSP Parameters
|
||||
[cols=",,,",options="header",]
|
||||
|=======================================================================
|
||||
|init param |Description |Default |`webdefault.xml`
|
||||
|development |`development=true`, recompilation checks occur on each
|
||||
request. See also `
|
||||
modificationTestInterval`. |TRUE |–
|
||||
|
||||
|fork |Should Ant fork its Java compiles of JSP pages? |TRUE |FALSE
|
||||
|
||||
|keepgenerated |Do you want to keep the generated Java files around?
|
||||
|FALSE |–
|
||||
|
||||
|saveBytecode |If class files are generated as byte arrays, should they
|
||||
be saved to disk at the end of compilations? |FALSE |–
|
||||
|
||||
|trimSpaces |Should white spaces between directives or actions be
|
||||
trimmed? |FALSE |–
|
||||
|
||||
|enablePooling |Determines whether tag handler pooling is enabled. |TRUE
|
||||
|–
|
||||
|
||||
|mappedFile |Support for mapped Files. Generates a servlet that has a
|
||||
print statement per line of the JSP file./ |TRUE |–
|
||||
|
||||
|sendErrorToClient |If false, stack traces, etc., are sent to std error
|
||||
instead of the client's browser. |FALSE |–
|
||||
|
||||
|classdebuginfo |Include debugging info in class file. |TRUE |–
|
||||
|
||||
|checkInterval |Interval in seconds between background recompile checks.
|
||||
Only relevant if ` development=false`. |0 |–
|
||||
|
||||
|suppressSmap |Generation of SMAP info for JSR45 debugging. |FALSE |–
|
||||
|
||||
|dumpSmap |Dump SMAP JSR45 info to a file. |FALSE |–
|
||||
|
||||
|genStrAsCharArray |Option for generating Strings. |FALSE |–
|
||||
|
||||
|genStrAsByteArray |Option for generating Strings. |TRUE |–
|
||||
|
||||
|defaultBufferNone | |FALSE |–
|
||||
|
||||
|errorOnUseBeanInvalidClassAttribute | |FALSE |–
|
||||
|
||||
|scratchDir |Directory where servlets are generated. Jetty sets this
|
||||
value according to the [/display/JETTY/Temporary+Directories work dir]
|
||||
settings for the webapp. |– |–
|
||||
|
||||
|compiler |Determined at runtime. For Jetty this is the Eclipse jdt
|
||||
compiler. |– |–
|
||||
|
||||
|compilerTargetVM |Target vm to compile for. |1.5 |–
|
||||
|
||||
|compilerSourceVM |Sets source compliance level for the jdt compiler.
|
||||
|1.5 |–
|
||||
|
||||
|javaEncoding |Pass through the encoding to use for the compilation.
|
||||
|UTF8 |–
|
||||
|
||||
|modificationTestInterval |If `development=true`, interval between
|
||||
recompilation checks, triggered by a request. |0 |–
|
||||
|
||||
|xpoweredBy |Generate an X-Powered-By response header. |FALSE |FALSE
|
||||
|
||||
|usePrecompiled/use-precompiled | |FALSE |–
|
||||
|
||||
|validating/enableTldValidation |Whether or not to validate tag files
|
||||
against the schema. |FALSE |–
|
||||
|
||||
|reload-interval |If `reload-interval=0`, then no runtime checking of
|
||||
JSP, otherwise sets the checking interval for both `development=true`
|
||||
and `development=false`. |– |–
|
||||
|
||||
|initial-capacity/initialCapacity |The initial capacity of the hash maps
|
||||
mapping the name of the JSP to class and JSP file. |– |–
|
||||
|=======================================================================
|
||||
|
||||
Much confusion generally ensues about the `development`, `checkInterval` and `modificationTestInterval` parameters and JSP runtime recompilation.
|
||||
Here is a factoring out of the various options:
|
||||
|
||||
* Check the JSP files for possible recompilation on every request:
|
||||
+
|
||||
[source, xml, subs="{sub-order}"]
|
||||
----
|
||||
|
||||
<init-param>
|
||||
<param-name>development></param-name>
|
||||
<param-value>true></param-value>
|
||||
</init-param>
|
||||
----
|
||||
* Only check approximately every N seconds, where a request triggers the time-lapse calculation.
|
||||
This example checks every 60 seconds:
|
||||
+
|
||||
[source, xml, subs="{sub-order}"]
|
||||
----
|
||||
<init-param>
|
||||
<param-name>development></param-name>
|
||||
<param-value>true></param-value>
|
||||
</init-param>
|
||||
<init-param>
|
||||
<param-name>modificationTestInterval></param-name>
|
||||
<param-value>60></param-value>
|
||||
</init-param>
|
||||
----
|
||||
* Do no checking whatsoever, but still compile the JSP on the very first hit (Be aware that this `reload-interval` parameter is shorthand for
|
||||
a `development=false` and `checkInterval=0` combination):
|
||||
+
|
||||
[source, xml, subs="{sub-order}"]
|
||||
----
|
||||
<init-param>
|
||||
<param-name>reload-interval></param-name>
|
||||
<param-value>-1></param-value>
|
||||
</init-param>
|
||||
----
|
||||
* Don't do any request-time checking, but instead start a background thread to do checks every N seconds.
|
||||
This example checks every 60 seconds:
|
||||
+
|
||||
[source, xml, subs="{sub-order}"]
|
||||
----
|
||||
<init-param>
|
||||
<param-name>development></param-name>
|
||||
<param-value>false></param-value>
|
||||
</init-param>
|
||||
<init-param>
|
||||
<param-name>checkInterval></param-name>
|
||||
<param-value>60></param-value>
|
||||
</init-param>
|
||||
----
|
||||
|
||||
[[modifying-configuration]]
|
||||
==== Modifying Configuration
|
||||
|
||||
Regardless of which JSP container you are using, there are several options for modifying the JspServlet configuration.
|
||||
|
||||
[[overriding-webdefault.xml]]
|
||||
===== Overriding `webdefault.xml`
|
||||
|
||||
|
|
@ -428,14 +270,7 @@ It is also automatically on the classpath for the Jetty Maven plugin, which uses
|
|||
If you are using Jetty in an embedded scenario, and you need to use JSTL, then you must ensure that the JSTL jars are included on the _container's_ classpath - that is the classpath that is the _parent_ of the webapp's classpath.
|
||||
This is a restriction that arises from the JavaEE specification.
|
||||
|
||||
The jars that you will include will depend on the flavor of JSP that you are using.
|
||||
|
||||
====== With Glassfish JSP
|
||||
|
||||
You will need to put the JSTL jars that are present in `{$jetty.home/lib/jsp}` onto the _container's_ classpath.
|
||||
The Glassfish JSP engine will find the JSTL tag definitions inside these jars during startup.
|
||||
|
||||
====== With Apache JSP
|
||||
====== Apache JSP
|
||||
|
||||
You will need to put the jars that are present in the `{$jetty.home}/lib/apache-jstl` directory onto the _container's_ classpath.
|
||||
The Apache JSP engine will find the JSTL tag definitions inside these jars during startup.
|
||||
|
|
@ -461,7 +296,7 @@ The following sections provide information about using JSF TagLibs with Jetty St
|
|||
===== Using JSF Taglibs with Jetty Distribution
|
||||
|
||||
If you want to use JSF with your webapp, you need to copy the JSF implementation Jar (whichever Jar contains the `META-INF/*.tld` files from your chosen JSF implementation) into Jetty's shared container lib directory.
|
||||
You can either put them into the lib directory matching your JSP container of choice (either `{$jetty.home}/lib/jsp` for Glassfish JSP, or `{$jetty.home}/lib/apache-jsp` for Apache JSP), or put them into `{$jetty.home}/lib/ext`.
|
||||
You can either put them into the lib directory for Apache `{$jetty.home}/lib/apache-jsp` or put them into `{$jetty.home}/lib/ext`.
|
||||
|
||||
[[using-jsf-taglibs-with-jetty-maven-plugin]]
|
||||
===== Using JSF Taglibs with Jetty Maven Plugin
|
||||
|
|
|
|||
Loading…
Reference in New Issue