Merge remote-tracking branch 'origin/jetty-9.4.x' into jetty-9.4.x-ByteAccumulator
This commit is contained in:
commit
a51b5db209
|
@ -4,7 +4,10 @@ updates:
|
|||
directory: "/"
|
||||
schedule:
|
||||
interval: "weekly"
|
||||
time: "14:00"
|
||||
target-branch: "jetty-9.4.x"
|
||||
# Encourage more pull requests from oldest branch
|
||||
open-pull-requests-limit: 20
|
||||
|
||||
- package-ecosystem: "github-actions"
|
||||
directory: "/"
|
||||
|
|
|
@ -11,8 +11,8 @@ pipeline {
|
|||
agent { node { label 'linux' } }
|
||||
steps {
|
||||
container('jetty-build') {
|
||||
timeout( time: 120, unit: 'MINUTES' ) {
|
||||
mavenBuild( "jdk8", "clean install -T3", "maven3",
|
||||
timeout( time: 240, unit: 'MINUTES' ) {
|
||||
mavenBuild( "jdk8", "clean install", "maven3",
|
||||
[[parserName: 'Maven'], [parserName: 'Java']])
|
||||
// Collect up the jacoco execution results (only on main build)
|
||||
jacoco inclusionPattern: '**/org/eclipse/jetty/**/*.class',
|
||||
|
@ -41,8 +41,8 @@ pipeline {
|
|||
agent { node { label 'linux' } }
|
||||
steps {
|
||||
container( 'jetty-build' ) {
|
||||
timeout( time: 120, unit: 'MINUTES' ) {
|
||||
mavenBuild( "jdk11", "clean install -T3 -Djacoco.skip=true ", "maven3",
|
||||
timeout( time: 240, unit: 'MINUTES' ) {
|
||||
mavenBuild( "jdk11", "clean install -Djacoco.skip=true", "maven3",
|
||||
[[parserName: 'Maven'], [parserName: 'Java']])
|
||||
}
|
||||
}
|
||||
|
@ -53,8 +53,8 @@ pipeline {
|
|||
agent { node { label 'linux' } }
|
||||
steps {
|
||||
container( 'jetty-build' ) {
|
||||
timeout( time: 120, unit: 'MINUTES' ) {
|
||||
mavenBuild( "jdk15", "clean install -T3 -Djacoco.skip=true ", "maven3",
|
||||
timeout( time: 240, unit: 'MINUTES' ) {
|
||||
mavenBuild( "jdk15", "clean install -Djacoco.skip=true", "maven3",
|
||||
[[parserName: 'Maven'], [parserName: 'Java']])
|
||||
}
|
||||
}
|
||||
|
@ -65,7 +65,7 @@ pipeline {
|
|||
agent { node { label 'linux' } }
|
||||
steps {
|
||||
container( 'jetty-build' ) {
|
||||
timeout( time: 40, unit: 'MINUTES' ) {
|
||||
timeout( time: 60, unit: 'MINUTES' ) {
|
||||
mavenBuild( "jdk11",
|
||||
"install javadoc:javadoc javadoc:aggregate-jar -DskipTests -Dpmd.skip=true -Dcheckstyle.skip=true",
|
||||
"maven3", [[parserName: 'Maven'], [parserName: 'JavaDoc'], [parserName: 'Java']])
|
||||
|
@ -78,8 +78,8 @@ pipeline {
|
|||
agent { node { label 'linux' } }
|
||||
steps {
|
||||
container( 'jetty-build' ) {
|
||||
timeout( time: 30, unit: 'MINUTES' ) {
|
||||
mavenBuild( "jdk8", "-T3 -Pcompact3 clean install -DskipTests", "maven3",
|
||||
timeout( time: 60, unit: 'MINUTES' ) {
|
||||
mavenBuild( "jdk8", "-Pcompact3 clean install -DskipTests", "maven3",
|
||||
[[parserName: 'Maven'], [parserName: 'Java']])
|
||||
}
|
||||
}
|
||||
|
@ -138,14 +138,14 @@ def mavenBuild(jdk, cmdline, mvnName, consoleParsers) {
|
|||
"MAVEN_OPTS=-Xms2g -Xmx4g -Djava.awt.headless=true"]) {
|
||||
configFileProvider(
|
||||
[configFile(fileId: 'oss-settings.xml', variable: 'GLOBAL_MVN_SETTINGS')]) {
|
||||
sh "mvn -s $GLOBAL_MVN_SETTINGS -Dmaven.repo.local=.repository -Premote-session-tests -Pci -fae -V -B -e -Djetty.testtracker.log=true $cmdline -Dunix.socket.tmp=" +
|
||||
sh "mvn -s $GLOBAL_MVN_SETTINGS -Dmaven.repo.local=.repository -Pci -V -B -e -Djetty.testtracker.log=true $cmdline -Dunix.socket.tmp=" +
|
||||
env.JENKINS_HOME
|
||||
}
|
||||
}
|
||||
}
|
||||
finally
|
||||
{
|
||||
junit testResults: '**/target/surefire-reports/*.xml,**/target/invoker-reports/TEST*.xml'
|
||||
junit testResults: '**/target/surefire-reports/*.xml,**/target/invoker-reports/TEST*.xml', allowEmptyResults: true
|
||||
if(consoleParsers!=null){
|
||||
warnings consoleParsers: consoleParsers
|
||||
}
|
||||
|
|
1
KEYS.txt
1
KEYS.txt
|
@ -6,3 +6,4 @@ Joakim Erdfelt <joakime@apache.org> B59B 67FD 7904 9843 67F9 3180 0818
|
|||
Joakim Erdfelt <joakim@erdfelt.com> BFBB 21C2 46D7 7768 3628 7A48 A04E 0C74 ABB3 5FEA
|
||||
Simone Bordet <simone.bordet@gmail.com> 8B09 6546 B1A8 F026 56B1 5D3B 1677 D141 BCF3 584D
|
||||
Olivier Lamy <olamy@apache.org> F254 B356 17DC 255D 9344 BCFA 873A 8E86 B437 2146
|
||||
Ludovic Orban <lorban@bitronix.be> E224 88CC 94F6 3E3F C928 536C 4241 C082 70D9 99C3
|
||||
|
|
11
VERSION.txt
11
VERSION.txt
|
@ -1,4 +1,13 @@
|
|||
jetty-9.4.35-SNAPSHOT
|
||||
jetty-9.4.36-SNAPSHOT
|
||||
|
||||
jetty-9.4.35.v20201120 - 20 November 2020
|
||||
+ 4711 Reset trailers on recycled response
|
||||
+ 5486 PropertyFileLoginModule retains PropertyUserStores
|
||||
+ 5539 StatisticsServlet output is not valid
|
||||
+ 5562 ArrayTernaryTrie consumes too much memory
|
||||
+ 5575 Add SEARCH as a known HttpMethod
|
||||
+ 5605 CVE-2020-27218 java.io.IOException: unconsumed input during http request parsing
|
||||
+ 5633 Allow to configure HttpClient request authority
|
||||
|
||||
jetty-9.4.34.v20201102 - 02 November 2020
|
||||
+ 5320 Using WebSocketClient with jetty-websocket-httpclient.xml in a Jetty
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-project</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
<relativePath>../../pom.xml</relativePath>
|
||||
</parent>
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
|
@ -37,7 +37,7 @@
|
|||
<configuration>
|
||||
<excludes>**/MANIFEST.MF,javax/**</excludes>
|
||||
<excludeArtifactIds>javax,jetty-test-helper</excludeArtifactIds>
|
||||
<excludeGroupIds>javax,org.eclipse.jetty.orbit,org.slf4j,org.ow2.asm,org.junit</excludeGroupIds>
|
||||
<excludeGroupIds>javax,org.eclipse.jetty.orbit,org.slf4j,org.ow2.asm,org.junit,org.apiguardian,org.opentest4j,org.hamcrest</excludeGroupIds>
|
||||
<outputDirectory>${project.build.directory}/classes</outputDirectory>
|
||||
<overWriteReleases>false</overWriteReleases>
|
||||
<overWriteSnapshots>true</overWriteSnapshots>
|
||||
|
@ -51,13 +51,23 @@
|
|||
</goals>
|
||||
<configuration>
|
||||
<classifier>sources</classifier>
|
||||
<includes>**/*</includes>
|
||||
<includes>org/eclipse/jetty/**</includes>
|
||||
<excludes>
|
||||
META-INF/**, **/Servlet3Continuation*, **/Jetty6Continuation*, **/AppContextLeakPreventer*.java, **/AWTLeakPreventer*.java, **/IntrospectorCleaner*.java, **/PostConstructAnnotationHandler*.java, **/PreDestroyAnnotationHandler*.java, **/ResourceAnnotationHandler*.java, **/ResourcesAnnotationHandler*.java
|
||||
META-INF/**,
|
||||
**/module-info.class,
|
||||
**/Servlet3Continuation*,
|
||||
**/Jetty6Continuation*,
|
||||
**/AppContextLeakPreventer*.java,
|
||||
**/AWTLeakPreventer*.java,
|
||||
**/IntrospectorCleaner*.java,
|
||||
**/PostConstructAnnotationHandler*.java,
|
||||
**/PreDestroyAnnotationHandler*.java,
|
||||
**/ResourceAnnotationHandler*.java,
|
||||
**/ResourcesAnnotationHandler*.java
|
||||
</excludes>
|
||||
<includeGroupIds>org.eclipse.jetty,org.eclipse.jetty.websocket</includeGroupIds>
|
||||
<excludeArtifactIds>javax,jetty-test-helper</excludeArtifactIds>
|
||||
<excludeGroupIds>javax,org.eclipse.jetty.orbit,org.slf4j,org.ow2.asm,org.junit</excludeGroupIds>
|
||||
<excludeGroupIds>javax,org.eclipse.jetty.orbit,org.slf4j,org.ow2.asm,org.junit,org.apiguardian,org.opentest4j,org.hamcrest</excludeGroupIds>
|
||||
<outputDirectory>${project.build.directory}/sources</outputDirectory>
|
||||
<overWriteReleases>true</overWriteReleases>
|
||||
<overWriteSnapshots>true</overWriteSnapshots>
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-project</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
<relativePath>../../pom.xml</relativePath>
|
||||
</parent>
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-project</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<artifactId>apache-jsp</artifactId>
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-project</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<artifactId>apache-jstl</artifactId>
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<modelVersion>4.0.0</modelVersion>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>build-resources</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
<packaging>jar</packaging>
|
||||
<name>Jetty :: Build Resources</name>
|
||||
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>example-async-rest</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>example-async-rest</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty.examples</groupId>
|
||||
<artifactId>examples-parent</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty.examples</groupId>
|
||||
<artifactId>examples-parent</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
<relativePath>../pom.xml</relativePath>
|
||||
</parent>
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-project</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-alpn-parent</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<artifactId>jetty-alpn-client</artifactId>
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-alpn-parent</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-alpn-parent</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-alpn-parent</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-alpn-parent</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
|
|
|
@ -4,7 +4,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-alpn-parent</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
|
|
|
@ -3,7 +3,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-alpn-parent</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-alpn-parent</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<artifactId>jetty-alpn-server</artifactId>
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-project</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<artifactId>jetty-alpn-parent</artifactId>
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-project</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<artifactId>jetty-annotations</artifactId>
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-project</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<artifactId>jetty-ant</artifactId>
|
||||
|
|
|
@ -9,7 +9,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-project</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
|
||||
<build>
|
||||
|
@ -53,336 +53,336 @@
|
|||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>apache-jsp</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>apache-jstl</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-alpn-client</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-alpn-java-client</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-alpn-java-server</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-alpn-openjdk8-client</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-alpn-openjdk8-server</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-alpn-conscrypt-client</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-alpn-conscrypt-server</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-alpn-server</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-annotations</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-ant</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-client</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-continuation</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-deploy</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-distribution</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
<type>zip</type>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-distribution</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
<type>tar.gz</type>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.fcgi</groupId>
|
||||
<artifactId>fcgi-client</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.fcgi</groupId>
|
||||
<artifactId>fcgi-server</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.gcloud</groupId>
|
||||
<artifactId>jetty-gcloud-session-manager</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-home</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
<type>zip</type>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-home</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
<type>tar.gz</type>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-http</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.http2</groupId>
|
||||
<artifactId>http2-client</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.http2</groupId>
|
||||
<artifactId>http2-common</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.http2</groupId>
|
||||
<artifactId>http2-hpack</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.http2</groupId>
|
||||
<artifactId>http2-http-client-transport</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.http2</groupId>
|
||||
<artifactId>http2-server</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-http-spi</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>infinispan-common</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>infinispan-remote-query</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>infinispan-embedded-query</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-hazelcast</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-io</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-jaas</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-jaspi</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-jmx</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-jndi</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.memcached</groupId>
|
||||
<artifactId>jetty-memcached-sessions</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-nosql</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.osgi</groupId>
|
||||
<artifactId>jetty-osgi-boot</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.osgi</groupId>
|
||||
<artifactId>jetty-osgi-boot-jsp</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.osgi</groupId>
|
||||
<artifactId>jetty-osgi-boot-warurl</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.osgi</groupId>
|
||||
<artifactId>jetty-httpservice</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-plus</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-proxy</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-quickstart</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-rewrite</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-security</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-openid</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-server</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-servlet</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-servlets</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-spring</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-unixsocket</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-util</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-util-ajax</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-webapp</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.websocket</groupId>
|
||||
<artifactId>javax-websocket-client-impl</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.websocket</groupId>
|
||||
<artifactId>javax-websocket-server-impl</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.websocket</groupId>
|
||||
<artifactId>websocket-api</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.websocket</groupId>
|
||||
<artifactId>websocket-client</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.websocket</groupId>
|
||||
<artifactId>websocket-common</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.websocket</groupId>
|
||||
<artifactId>websocket-server</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.websocket</groupId>
|
||||
<artifactId>websocket-servlet</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-xml</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</dependency>
|
||||
</dependencies>
|
||||
</dependencyManagement>
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-project</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-project</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
|
|
|
@ -562,7 +562,13 @@ public class HttpClient extends ContainerLifeCycle
|
|||
return new Origin(scheme, host, port, tag);
|
||||
}
|
||||
|
||||
protected HttpDestination resolveDestination(Origin origin)
|
||||
/**
|
||||
* <p>Returns, creating it if absent, the destination with the given origin.</p>
|
||||
*
|
||||
* @param origin the origin that identifies the destination
|
||||
* @return the destination for the given origin
|
||||
*/
|
||||
public HttpDestination resolveDestination(Origin origin)
|
||||
{
|
||||
return destinations.computeIfAbsent(origin, o ->
|
||||
{
|
||||
|
|
|
@ -120,7 +120,13 @@ public abstract class HttpConnection implements Connection, Attachable
|
|||
if (version.getVersion() <= 11)
|
||||
{
|
||||
if (!headers.containsKey(HttpHeader.HOST.asString()))
|
||||
headers.put(getHttpDestination().getHostField());
|
||||
{
|
||||
URI uri = request.getURI();
|
||||
if (uri != null)
|
||||
headers.put(HttpHeader.HOST, uri.getAuthority());
|
||||
else
|
||||
headers.put(getHttpDestination().getHostField());
|
||||
}
|
||||
}
|
||||
|
||||
// Add content headers
|
||||
|
|
|
@ -253,15 +253,13 @@ public abstract class HttpDestination extends ContainerLifeCycle implements Dest
|
|||
abort(x);
|
||||
}
|
||||
|
||||
public void send(Request request, Response.CompleteListener listener)
|
||||
{
|
||||
((HttpRequest)request).sendAsync(this, listener);
|
||||
}
|
||||
|
||||
protected void send(HttpRequest request, List<Response.ResponseListener> listeners)
|
||||
{
|
||||
if (!getScheme().equalsIgnoreCase(request.getScheme()))
|
||||
throw new IllegalArgumentException("Invalid request scheme " + request.getScheme() + " for destination " + this);
|
||||
if (!getHost().equalsIgnoreCase(request.getHost()))
|
||||
throw new IllegalArgumentException("Invalid request host " + request.getHost() + " for destination " + this);
|
||||
int port = request.getPort();
|
||||
if (port >= 0 && getPort() != port)
|
||||
throw new IllegalArgumentException("Invalid request port " + port + " for destination " + this);
|
||||
send(new HttpExchange(this, request, listeners));
|
||||
}
|
||||
|
||||
|
|
|
@ -40,6 +40,7 @@ import java.util.concurrent.ExecutionException;
|
|||
import java.util.concurrent.TimeUnit;
|
||||
import java.util.concurrent.TimeoutException;
|
||||
import java.util.concurrent.atomic.AtomicReference;
|
||||
import java.util.function.BiConsumer;
|
||||
import java.util.function.BiFunction;
|
||||
import java.util.function.LongConsumer;
|
||||
import java.util.function.Supplier;
|
||||
|
@ -722,7 +723,7 @@ public class HttpRequest implements Request
|
|||
public ContentResponse send() throws InterruptedException, TimeoutException, ExecutionException
|
||||
{
|
||||
FutureResponseListener listener = new FutureResponseListener(this);
|
||||
send(this, listener);
|
||||
send(listener);
|
||||
|
||||
try
|
||||
{
|
||||
|
@ -761,15 +762,20 @@ public class HttpRequest implements Request
|
|||
@Override
|
||||
public void send(Response.CompleteListener listener)
|
||||
{
|
||||
send(this, listener);
|
||||
sendAsync(client::send, listener);
|
||||
}
|
||||
|
||||
private void send(HttpRequest request, Response.CompleteListener listener)
|
||||
void sendAsync(HttpDestination destination, Response.CompleteListener listener)
|
||||
{
|
||||
sendAsync(destination::send, listener);
|
||||
}
|
||||
|
||||
private void sendAsync(BiConsumer<HttpRequest, List<Response.ResponseListener>> sender, Response.CompleteListener listener)
|
||||
{
|
||||
if (listener != null)
|
||||
responseListeners.add(listener);
|
||||
sent();
|
||||
client.send(request, responseListeners);
|
||||
sender.accept(this, responseListeners);
|
||||
}
|
||||
|
||||
void sent()
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-project</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<artifactId>jetty-continuation</artifactId>
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-project</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<artifactId>jetty-deploy</artifactId>
|
||||
|
|
|
@ -1,6 +1,8 @@
|
|||
<?xml version="1.0"?><!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_3.dtd">
|
||||
|
||||
<!-- =============================================================== --><!-- Mixin the Weld / CDI classes to the class loader --><!-- =============================================================== -->
|
||||
<!-- =============================================================== -->
|
||||
<!-- Mixin the Weld / CDI classes to the class loader -->
|
||||
<!-- =============================================================== -->
|
||||
|
||||
<Configure id="Server" class="org.eclipse.jetty.server.Server">
|
||||
<!-- Bind the jetty-web-decorate.xml to every deployed webapp -->
|
||||
|
|
|
@ -1,6 +1,12 @@
|
|||
<?xml version="1.0"?><!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_3.dtd">
|
||||
|
||||
<!-- =============================================================== --><!-- Create the deployment manager --><!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --><!-- The deplyment manager handles the lifecycle of deploying web --><!-- applications. Apps are provided by instances of the --><!-- AppProvider interface. --><!-- =============================================================== -->
|
||||
<!-- =============================================================== -->
|
||||
<!-- Create the deployment manager -->
|
||||
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
|
||||
<!-- The deplyment manager handles the lifecycle of deploying web -->
|
||||
<!-- applications. Apps are provided by instances of the -->
|
||||
<!-- AppProvider interface. -->
|
||||
<!-- =============================================================== -->
|
||||
<Configure id="Server" class="org.eclipse.jetty.server.Server">
|
||||
|
||||
<Call name="addBean">
|
||||
|
|
|
@ -1,6 +1,10 @@
|
|||
<?xml version="1.0"?><!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_3.dtd">
|
||||
|
||||
<!-- ============================================================= --><!-- Configure the Jetty Server instance with an ID "Server" --><!-- by adding an HTTP connector. --><!-- This configuration must be used in conjunction with jetty.xml --><!-- ============================================================= -->
|
||||
<!-- ============================================================= -->
|
||||
<!-- Configure the Jetty Server instance with an ID "Server" -->
|
||||
<!-- by adding an HTTP connector. -->
|
||||
<!-- This configuration must be used in conjunction with jetty.xml -->
|
||||
<!-- ============================================================= -->
|
||||
<Configure id="Server" class="org.eclipse.jetty.server.Server">
|
||||
|
||||
<!-- =========================================================== -->
|
||||
|
|
|
@ -1,8 +1,27 @@
|
|||
<?xml version="1.0"?><!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_3.dtd">
|
||||
|
||||
<!-- =============================================================== --><!-- Documentation of this file format can be found at: --><!-- https://www.eclipse.org/jetty/documentation/current/ --><!-- --><!-- Additional configuration files are available in $JETTY_HOME/etc --><!-- and can be mixed in. See start.ini file for the default --><!-- configuration files. --><!-- --><!-- For a description of the configuration mechanism, see the --><!-- output of: --><!-- java -jar start.jar -? --><!-- =============================================================== -->
|
||||
<!-- =============================================================== -->
|
||||
<!-- Documentation of this file format can be found at: -->
|
||||
<!-- https://www.eclipse.org/jetty/documentation/current/ -->
|
||||
<!-- -->
|
||||
<!-- Additional configuration files are available in $JETTY_HOME/etc -->
|
||||
<!-- and can be mixed in. See start.ini file for the default -->
|
||||
<!-- configuration files. -->
|
||||
<!-- -->
|
||||
<!-- For a description of the configuration mechanism, see the -->
|
||||
<!-- output of: -->
|
||||
<!-- java -jar start.jar -? -->
|
||||
<!-- =============================================================== -->
|
||||
|
||||
<!-- =============================================================== --><!-- Configure a Jetty Server instance with an ID "Server" --><!-- Other configuration files may also configure the "Server" --><!-- ID, in which case they are adding configuration to the same --><!-- instance. If other configuration have a different ID, they --><!-- will create and configure another instance of Jetty. --><!-- Consult the javadoc of o.e.j.server.Server for all --><!-- configuration that may be set here. --><!-- =============================================================== -->
|
||||
<!-- =============================================================== -->
|
||||
<!-- Configure a Jetty Server instance with an ID "Server" -->
|
||||
<!-- Other configuration files may also configure the "Server" -->
|
||||
<!-- ID, in which case they are adding configuration to the same -->
|
||||
<!-- instance. If other configuration have a different ID, they -->
|
||||
<!-- will create and configure another instance of Jetty. -->
|
||||
<!-- Consult the javadoc of o.e.j.server.Server for all -->
|
||||
<!-- configuration that may be set here. -->
|
||||
<!-- =============================================================== -->
|
||||
<Configure id="Server" class="org.eclipse.jetty.server.Server">
|
||||
|
||||
<!-- =========================================================== -->
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-project</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<artifactId>jetty-distribution</artifactId>
|
||||
|
|
|
@ -1,145 +1,21 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<parent>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
<artifactId>jetty-project</artifactId>
|
||||
<version>9.4.35-SNAPSHOT</version>
|
||||
<version>9.4.36-SNAPSHOT</version>
|
||||
</parent>
|
||||
|
||||
<modelVersion>4.0.0</modelVersion>
|
||||
<artifactId>jetty-documentation</artifactId>
|
||||
<name>Jetty :: Documentation</name>
|
||||
<packaging>pom</packaging>
|
||||
<properties>
|
||||
<html.directory>${project.build.directory}/current</html.directory>
|
||||
<javadoc.version>${project.version}</javadoc.version>
|
||||
</properties>
|
||||
|
||||
<build>
|
||||
<plugins>
|
||||
<plugin>
|
||||
<artifactId>maven-resources-plugin</artifactId>
|
||||
<executions>
|
||||
<execution>
|
||||
<id>copy-assets</id>
|
||||
<phase>process-resources</phase>
|
||||
<goals>
|
||||
<goal>copy-resources</goal>
|
||||
</goals>
|
||||
<configuration>
|
||||
<resources>
|
||||
<resource>
|
||||
<directory>src/main/resources</directory>
|
||||
<includes>
|
||||
<include>**</include>
|
||||
</includes>
|
||||
</resource>
|
||||
</resources>
|
||||
<outputDirectory>${html.directory}</outputDirectory>
|
||||
</configuration>
|
||||
</execution>
|
||||
</executions>
|
||||
</plugin>
|
||||
<plugin>
|
||||
<groupId>org.asciidoctor</groupId>
|
||||
<artifactId>asciidoctor-maven-plugin</artifactId>
|
||||
<executions>
|
||||
<execution>
|
||||
<id>output-html</id>
|
||||
<phase>compile</phase>
|
||||
<goals>
|
||||
<goal>process-asciidoc</goal>
|
||||
</goals>
|
||||
<configuration>
|
||||
<backend>docbook</backend>
|
||||
<doctype>book</doctype>
|
||||
<sourceDocumentName>index.adoc</sourceDocumentName>
|
||||
<attributes>
|
||||
<sub-order>attributes+</sub-order>
|
||||
<imagesdir />
|
||||
<linkcss>true</linkcss>
|
||||
<allow-uri-read>true</allow-uri-read>
|
||||
<toc>true</toc>
|
||||
<revnumber>${project.version}</revnumber>
|
||||
<JDURL>https://eclipse.org/jetty/javadoc/${javadoc.version}</JDURL>
|
||||
<JXURL>https://download.eclipse.org/jetty/stable-9/xref</JXURL>
|
||||
<SRCDIR>${basedir}/..</SRCDIR>
|
||||
<GITBROWSEURL>https://github.com/eclipse/jetty.project/tree/jetty-9.4.x</GITBROWSEURL>
|
||||
<MVNCENTRAL>https://repo1.maven.org/maven2</MVNCENTRAL>
|
||||
<VERSION>${project.version}</VERSION>
|
||||
</attributes>
|
||||
</configuration>
|
||||
</execution>
|
||||
</executions>
|
||||
</plugin>
|
||||
<plugin>
|
||||
<groupId>com.agilejava.docbkx</groupId>
|
||||
<artifactId>docbkx-maven-plugin</artifactId>
|
||||
<version>2.0.17</version>
|
||||
<executions>
|
||||
<execution>
|
||||
<id>html</id>
|
||||
<phase>compile</phase>
|
||||
<goals>
|
||||
<goal>generate-html</goal>
|
||||
</goals>
|
||||
<configuration>
|
||||
<htmlStylesheet>css/docbook.css</htmlStylesheet>
|
||||
<htmlCustomization>${project.basedir}/src/main/docbkx-stylesheet/html/docbook.xsl</htmlCustomization>
|
||||
<preProcess>
|
||||
<!-- pull over the images from the source material -->
|
||||
<copy todir="target/docbkx/html/images" flatten="true">
|
||||
<fileset dir="src/main/asciidoc">
|
||||
<include name="**/*.png" />
|
||||
<include name="**/*.jpg" />
|
||||
<include name="**/*.svg" />
|
||||
<include name="**/*.dot" />
|
||||
</fileset>
|
||||
</copy>
|
||||
<copy todir="target/docbkx/html/images">
|
||||
<fileset dir="src/main/docbkx-resources/images" />
|
||||
</copy>
|
||||
<copy todir="target/docbkx/html/css">
|
||||
<fileset dir="src/main/docbkx-resources/css" />
|
||||
</copy>
|
||||
<copy todir="target/docbkx/html/fonts">
|
||||
<fileset dir="src/main/docbkx-resources/fonts" />
|
||||
</copy>
|
||||
<copy todir="target/docbkx/html/js">
|
||||
<fileset dir="src/main/docbkx-resources/js" />
|
||||
</copy>
|
||||
</preProcess>
|
||||
</configuration>
|
||||
</execution>
|
||||
</executions>
|
||||
<configuration>
|
||||
<!-- shared configuration -->
|
||||
<sourceDirectory>${project.build.directory}/generated-docs</sourceDirectory>
|
||||
<includes>index.xml</includes>
|
||||
<generatedSourceDirectory>${project.build.directory}/docbkx/generated</generatedSourceDirectory>
|
||||
<chunkedOutput>true</chunkedOutput>
|
||||
<highlightSource>true</highlightSource>
|
||||
</configuration>
|
||||
<dependencies>
|
||||
<dependency>
|
||||
<groupId>net.sf.docbook</groupId>
|
||||
<artifactId>docbook-xml</artifactId>
|
||||
<version>5.1b4-all</version>
|
||||
<classifier>resources</classifier>
|
||||
<type>zip</type>
|
||||
<scope>runtime</scope>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>net.sf.xslthl</groupId>
|
||||
<artifactId>xslthl</artifactId>
|
||||
<version>2.1.3</version>
|
||||
<scope>runtime</scope>
|
||||
</dependency>
|
||||
<dependency>
|
||||
<groupId>org.eclipse.jetty.toolchain</groupId>
|
||||
<artifactId>jetty-xslt-tools</artifactId>
|
||||
<version>1.3</version>
|
||||
<scope>runtime</scope>
|
||||
</dependency>
|
||||
</dependencies>
|
||||
</plugin>
|
||||
<plugin>
|
||||
<artifactId>maven-assembly-plugin</artifactId>
|
||||
|
@ -160,85 +36,4 @@
|
|||
</plugin>
|
||||
</plugins>
|
||||
</build>
|
||||
<profiles>
|
||||
<!--
|
||||
Couple of different approaches to generating pdf's
|
||||
-->
|
||||
<profile>
|
||||
<id>generate-pdf</id>
|
||||
<build>
|
||||
<plugins>
|
||||
<plugin>
|
||||
<groupId>com.agilejava.docbkx</groupId>
|
||||
<artifactId>docbkx-maven-plugin</artifactId>
|
||||
<executions>
|
||||
<execution>
|
||||
<id>generate-pdf</id>
|
||||
<phase>compile</phase>
|
||||
<goals>
|
||||
<goal>generate-pdf</goal>
|
||||
</goals>
|
||||
<configuration>
|
||||
<includes>index.xml</includes>
|
||||
<fop1Extensions>1</fop1Extensions>
|
||||
<paperType>A4</paperType>
|
||||
<foCustomization>src/main/docbkx-stylesheet/fo/docbook.xsl</foCustomization>
|
||||
</configuration>
|
||||
</execution>
|
||||
</executions>
|
||||
<dependencies>
|
||||
<dependency>
|
||||
<groupId>net.sf.offo</groupId>
|
||||
<artifactId>fop-hyph</artifactId>
|
||||
<version>1.2</version>
|
||||
<scope>runtime</scope>
|
||||
</dependency>
|
||||
</dependencies>
|
||||
</plugin>
|
||||
<plugin>
|
||||
<groupId>org.asciidoctor</groupId>
|
||||
<artifactId>asciidoctor-maven-plugin</artifactId>
|
||||
<dependencies>
|
||||
<dependency>
|
||||
<groupId>org.asciidoctor</groupId>
|
||||
<artifactId>asciidoctorj-pdf</artifactId>
|
||||
<version>1.5.0-alpha.11</version>
|
||||
</dependency>
|
||||
</dependencies>
|
||||
<executions>
|
||||
<execution>
|
||||
<id>output-pdf</id>
|
||||
<phase>generate-sources</phase>
|
||||
<goals>
|
||||
<goal>process-asciidoc</goal>
|
||||
</goals>
|
||||
<configuration>
|
||||
<backend>pdf</backend>
|
||||
<sourceHighlighter>rouge</sourceHighlighter>
|
||||
<sourceDocumentName>index.adoc</sourceDocumentName>
|
||||
<attributes>
|
||||
<imagesdir />
|
||||
<version>${project.version}</version>
|
||||
<linkcss>true</linkcss>
|
||||
<allow-uri-read>true</allow-uri-read>
|
||||
<toc>true</toc>
|
||||
<revnumber>${project.version}</revnumber>
|
||||
<JDURL>https://download.eclipse.org/jetty/stable-9/apidocs</JDURL>
|
||||
<JXURL>https://download.eclipse.org/jetty/stable-9/xref</JXURL>
|
||||
<SRCDIR>${basedir}/../jetty.project/</SRCDIR>
|
||||
<GITBROWSEURL>https://github.com/eclipse/jetty.project/tree/jetty-9.4.x</GITBROWSEURL>
|
||||
<icons>font</icons>
|
||||
<pagenums />
|
||||
<toc />
|
||||
<idprefix />
|
||||
<idseparator>-</idseparator>
|
||||
</attributes>
|
||||
</configuration>
|
||||
</execution>
|
||||
</executions>
|
||||
</plugin>
|
||||
</plugins>
|
||||
</build>
|
||||
</profile>
|
||||
</profiles>
|
||||
</project>
|
||||
</project>
|
|
@ -90,19 +90,18 @@ or alternatively you need the link:#alpn-openjdk8-agent[Jetty ALPN agent].
|
|||
|
||||
In the case of the Jetty ALPN boot library, start the JVM as follows:
|
||||
|
||||
[source, plain, subs="{sub-order}"]
|
||||
[source, plain]
|
||||
----
|
||||
java -Xbootclasspath/p:<path_to_alpn_boot_jar> ...
|
||||
----
|
||||
|
||||
Where `path_to_alpn_boot_jar` is the path on the file system for the `alpn-boot` artifact, such as the one at the Maven coordinates `org.mortbay.jetty.alpn:alpn-boot`.
|
||||
|
||||
____
|
||||
[IMPORTANT]
|
||||
====
|
||||
Be certain to get the
|
||||
link:#alpn-versions[ALPN boot artifact version that matches the version of your JRE].
|
||||
____
|
||||
|
||||
====
|
||||
[[alpn-openjdk8-agent]]
|
||||
==== ALPN agent and OpenJDK 8
|
||||
|
||||
|
@ -121,13 +120,13 @@ transforms, if necessary, the relevant OpenJDK classes to provide the ALPN suppo
|
|||
|
||||
To use the Jetty ALPN agent, start the JVM as follows:
|
||||
|
||||
[source, plain, subs="{sub-order}"]
|
||||
[source, plain]
|
||||
----
|
||||
java -javaagent:<path_to_alpn_agent_jar> ...
|
||||
----
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
The Jetty ALPN agent works with any Java 8 version. It is _required_ if you use
|
||||
an OpenJDK version up to `1.8.0_242` included, and it is _optional_ if you use an
|
||||
OpenJDK version equal or greater than `1.8.0_252`.
|
||||
|
@ -135,8 +134,7 @@ OpenJDK version equal or greater than `1.8.0_252`.
|
|||
The Jetty ALPN agent can be left on the command line even when using an OpenJDK version
|
||||
equal or greater than `1.8.0_252` but we recommend to remove it from the command line
|
||||
when you use OpenJDK `1.8.0_252` or later.
|
||||
____
|
||||
|
||||
====
|
||||
[[alpn-conscrypt]]
|
||||
==== ALPN and Conscrypt
|
||||
|
||||
|
@ -166,19 +164,18 @@ This jar contains a `Fragment-Host` directive that ensures the ALPN classes will
|
|||
|
||||
You can download the https://repo1.maven.org/maven2/org/eclipse/jetty/osgi/jetty-osgi-alpn/[jetty-osgi-alpn jar] from Maven Central.
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
OSGi *requires* a `ServiceLoader` implementation for Jetty to function properly.
|
||||
OSGi leverages http://aries.apache.org/modules/spi-fly.html[Apache Aries SPI Fly] for this functionality.
|
||||
You can read more about OSGi and `ServiceLoader` http://blog.osgi.org/2013/02/javautilserviceloader-in-osgi.html[here.]
|
||||
____
|
||||
|
||||
====
|
||||
[[alpn-troubleshooting]]
|
||||
==== ALPN Troubleshooting
|
||||
|
||||
When starting the Jetty server, especially when using Jetty embedded, it may be possible that you see an error similar to this:
|
||||
|
||||
[source, plain, subs="{sub-order}"]
|
||||
[source, plain]
|
||||
----
|
||||
IllegalStateException: no ALPN processor
|
||||
----
|
||||
|
@ -217,7 +214,7 @@ Refer to `ALPN` Javadocs and to the examples below for further details about cli
|
|||
[[alpn-openjdk8-client-example]]
|
||||
==== Client Example
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
SSLContext sslContext = ...;
|
||||
SSLSocket sslSocket = (SSLSocket)context.getSocketFactory().createSocket("localhost", server.getLocalPort());
|
||||
|
@ -257,7 +254,7 @@ The ALPN implementation calls `ALPN.ClientProvider` methods `protocols()`, `unsu
|
|||
|
||||
The example for `SSLEngine` is identical, and you just need to replace the `SSLSocket` instance with an `SSLEngine` instance.
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
SSLEngine sslEngine = ...;
|
||||
ALPN.put(sslEngine, new ALPN.ServerProvider()
|
||||
|
@ -294,7 +291,7 @@ Failing to do so will cause a memory leak.
|
|||
You can write and run unit tests that use the ALPN implementation.
|
||||
The solution that we use with Maven is to specify an additional command line argument to the Surefire plugin:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<project>
|
||||
|
||||
|
@ -328,9 +325,9 @@ The solution that we use with Maven is to specify an additional command line arg
|
|||
|
||||
You can enable debug logging for the ALPN implementation in this way:
|
||||
|
||||
....
|
||||
----
|
||||
ALPN.debug = true;
|
||||
....
|
||||
----
|
||||
|
||||
Since the ALPN class is in the boot classpath, we chose not to use logging libraries because we do not want to override application logging library choices; therefore the logging is performed directly on `System.err`.
|
||||
|
||||
|
@ -427,20 +424,20 @@ This section is for Jetty developers that need to update the ALPN implementation
|
|||
|
||||
Clone the OpenJDK repository with the following command:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
$ hg clone https://hg.openjdk.java.net/jdk8u/jdk8u jdk8u
|
||||
$ cd !$
|
||||
$ ./get_source.sh
|
||||
....
|
||||
----
|
||||
|
||||
To update the source to a specific tag, use the following command:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
$ ./make/scripts/hgforest.sh update <tag-name>
|
||||
|
||||
....
|
||||
----
|
||||
|
||||
The list of OpenJDK tags can be obtained from this page:
|
||||
https://hg.openjdk.java.net/jdk8u/jdk8u/tags[OpenJDK 8 Tags].
|
||||
|
|
|
@ -39,7 +39,7 @@ Below is an example application that sets up the standard `test-spec.war` webapp
|
|||
It can also be found in the Jetty GitHub repository on the examples/embedded page as link:{GITBROWSEURL}/examples/embedded/src/main/java/org/eclipse/jetty/embedded[`ServerWithAnnotations.java`.]
|
||||
Note that the `test-spec.war` uses not only annotations, but also link:#jndi[JNDI], so this example also enables their processing (via the link:#jndi-configuration-classes[org.eclipse.jetty.plus.webapp.EnvConfiguration], link:#jndi-configuration-classes[org.eclipse.jetty.plus.webapp.PlusConfiguration] and their related jars).
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/ServerWithAnnotations.java[]
|
||||
----
|
||||
|
|
|
@ -24,10 +24,10 @@
|
|||
You will need to place the following Jetty jar files onto the classpath of your application.
|
||||
You can obtain them from the https://www.eclipse.org/jetty/download.html[Jetty distribution], or the https://repo1.maven.org/maven2/org/eclipse/jetty/jetty-annotations[Maven repository]:
|
||||
|
||||
....
|
||||
----
|
||||
jetty-plus.jar
|
||||
jetty-annotations.jar
|
||||
....
|
||||
----
|
||||
|
||||
You will also need the http://asm.ow2.org/[asm] jar, which you can obtain from link:{MVNCENTRAL}/org/eclipse/jetty/orbit/org.objectweb.asm/3.3.1.v201105211655/org.objectweb.asm-3.3.1.v201105211655.jar[this link.]
|
||||
|
||||
|
@ -39,7 +39,7 @@ The example also adds in the configuration classes that are responsible for JNDI
|
|||
|
||||
The code is as follows:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
import org.eclipse.jetty.security.HashLoginService;
|
||||
import org.eclipse.jetty.server.Server;
|
||||
|
@ -101,7 +101,7 @@ On lines 30, 33 and 37 JNDI resources that we will be able to reference with @Re
|
|||
|
||||
With the setup above, a servlet that uses annotations and Jetty will honour the annotations when the webapp is deployed can be created:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
import javax.annotation.security.DeclareRoles;
|
||||
import javax.annotation.security.RunAs;
|
||||
|
|
|
@ -119,13 +119,12 @@ By default Jetty will call them in the following order:
|
|||
|
||||
As is the case with annotation scanning, the link:#using-extra-classpath-method[extraClasspath] is fully considered for `ServletContainerInitializer` callbacks. `ServletContainerInitializer` derived from a classes directory on the `extraClasspath` and jars from an `extraClasspath` for the webapp are called in step 2 and 3, respectively.
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
As of Jetty-9.4.4, unless the `web.xml` is version 3.0 or greater, only `ServletContainerInitializers` that are on the container classpath will be discovered.
|
||||
Users wishing to use `ServletContainerInitializers` from within the webapp with older versions of `web.xml` must either upgrade their `web.xml` version, or call `WebAppContext.setConfigurationDiscovered(true)` either programmatically or in xml.
|
||||
Upgrading the `web.xml` version is preferable.
|
||||
____
|
||||
|
||||
====
|
||||
===== Controlling the order of ServletContainerInitializer invocation
|
||||
|
||||
If you need `ServletContainerInitializer` classes called in a specific order that is different from that outlined above, you can use the link:#context_attributes[context attribute] `org.eclipse.jetty.containerInitializerOrder`.
|
||||
|
@ -135,7 +134,7 @@ It will match all `ServletContainerInitializer` classed not explicitly named in
|
|||
|
||||
Here is an example, setting the context attribute in code (although you can also do the link:#intro-jetty-configuration-webapps[same in xml]):
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
WebAppContext context = new WebAppContext();
|
||||
context.setAttribute("org.eclipse.jetty.containerInitializerOrder",
|
||||
|
@ -154,7 +153,7 @@ In this case, you can define the `org.eclipse.jetty.containerInitializerExclusio
|
|||
This is a regular expression that defines http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html[patterns] of classnames that you want to exclude.
|
||||
Here's an example, setting the context attribute in code, although you may do exactly the link:#intro-jetty-configuration-webapps[same in xml]:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
WebAppContext context = new WebAppContext();
|
||||
context.setAttribute("org.eclipse.jetty.containerInitializerExclusionPattern",
|
||||
|
|
|
@ -79,7 +79,7 @@ Default value is the empty list.
|
|||
|
||||
A typical configuration could be:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<web-app>
|
||||
|
||||
|
|
|
@ -38,7 +38,7 @@ The debug handler can be added to Jetty by activating the debug module.
|
|||
|
||||
==== Embedded usage
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
Server server = new Server(8080);
|
||||
RolloverFileOutputStream outputStream = new RolloverFileOutputStream("MeinLogPfad/yyyy_mm_dd.request.log", true,10);
|
||||
|
|
|
@ -34,12 +34,12 @@ As in the example below, if a resource to be served is not matched within the re
|
|||
This class is a useful template to either extend and embrace or simply provide a similar implementation for customizing to your needs.
|
||||
There is also an link:#error-handler[Error Handler] that services errors related to the servlet api specification, so it is best to not get the two confused.
|
||||
|
||||
_____
|
||||
[NOTE]
|
||||
====
|
||||
The `DefaultHandler` will also handle serving out the `flav.ico` file should a request make it through all of the other handlers without being resolved.
|
||||
_____
|
||||
====
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
Server server = new Server(8080);
|
||||
HandlerList handlers = new HandlerList();
|
||||
|
|
|
@ -55,7 +55,7 @@ Place the configuration in a webapp's `web.xml` or `jetty-web.xml`.
|
|||
The default configuration allows 25 requests per connection at a time, servicing more important requests first, and queuing up the rest.
|
||||
This example allow 30 requests at a time:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<filter>
|
||||
<filter-name>DoSFilter</filter-name>
|
||||
|
|
|
@ -37,12 +37,11 @@ Some user-agents might be excluded from compression to avoid common browser bugs
|
|||
The `GzipHandler` can be added to the entire server by enabling the `gzip.mod` module.
|
||||
It may also be added to individual contexts in a context xml file.
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
Jetty 9 only compresses using GZip.
|
||||
Using deflate HTTP compression is not supported and will not function.
|
||||
____
|
||||
|
||||
====
|
||||
[[gzip-filter-rules]]
|
||||
==== Gzip Rules
|
||||
|
||||
|
@ -63,13 +62,11 @@ The link:#default-servlet[DefaultServlet] is capable of serving pre-compressed s
|
|||
The `GzipHandler` installs an output interceptor which passes through to the `DefaultServlet`.
|
||||
If the content served by `DefaultServlet` is already compressed, the `GzipHandler` does nothing; if it is not compressed, the content is compressed on-the-fly.
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
Automatic precompression by the `DefaultServlet` can be configured.
|
||||
Read more about the `DefaultServlet` link:#default-servlet[here.]
|
||||
____
|
||||
|
||||
|
||||
====
|
||||
[[gzip-filter-init]]
|
||||
==== Gzip Configuration
|
||||
|
||||
|
|
|
@ -50,12 +50,11 @@ This filter will perform the following actions on each response:
|
|||
* Set the Expires header to approximately one year in the future.
|
||||
* Add a Date header with the current system time.
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
Each action must be separated by a comma.
|
||||
____
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
====
|
||||
[source, xml]
|
||||
----
|
||||
<filter>
|
||||
<filter-name>HeaderFilter</filter-name>
|
||||
|
|
|
@ -45,7 +45,7 @@ You create a new xref:configuring-contexts[context xml] file in `{$jetty/.base}/
|
|||
Below is an example.
|
||||
This is a permanent redirection, which also preserves `pathinfo` and query strings on the redirect:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_3.dtd">
|
||||
|
|
|
@ -83,7 +83,7 @@ Place the configuration in a webapp's `web.xml` or `jetty-web.xml`.
|
|||
The default configuration processes ten requests at a time, servicing more important requests first and queuing up the rest.
|
||||
This example processes fifty requests at a time:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<filter>
|
||||
<filter-name>QoSFilter</filter-name>
|
||||
|
@ -126,7 +126,7 @@ This allows a context external mechanism (for example, JMX via `ContextHandler.M
|
|||
You can use the `<filter-mapping>` syntax to map the QoSFilter to a servlet, either by using the servlet name, or by using a URL pattern.
|
||||
In this example, a URL pattern applies the QoSFilter to every request within the web application context:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<filter-mapping>
|
||||
<filter-name>QoSFilter</filter-name>
|
||||
|
@ -147,7 +147,7 @@ To customize the priority, subclass QoSFilter and then override the `getPriority
|
|||
You can then use this subclass as your QoS filter.
|
||||
Here's an example:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
public class ParsePriorityQoSFilter extends QoSFilter
|
||||
{
|
||||
|
|
|
@ -31,16 +31,14 @@
|
|||
|
||||
This handler will serve static content and handle If-Modified-Since headers and is suitable for simple serving of static content.
|
||||
|
||||
____
|
||||
[IMPORTANT]
|
||||
====
|
||||
There is no caching done with this handler, so if you are looking for a more fully featured way of serving static content look to the xref:default-servlet[].
|
||||
____
|
||||
|
||||
____
|
||||
====
|
||||
[NOTE]
|
||||
====
|
||||
Requests for resources that do not exist are let pass (Eg no 404's).
|
||||
____
|
||||
|
||||
====
|
||||
==== Improving the Look and Feel
|
||||
|
||||
The resource handler has a default stylesheet which you can change by calling `setStyleSheet(String location)` with the location of a file on the system that it can locate through the resource loading system.
|
||||
|
@ -51,7 +49,7 @@ The default css is called `jetty-dir.css` and is located in the `jetty-util` pac
|
|||
The following is an example of a split fileserver, able to serve static content from multiple directory locations.
|
||||
Since this handler does not return 404's on content you are able to iteratively try multiple resource handlers to resolve content.
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
include::{SRCDIR}/examples/embedded/src/main/java/org/eclipse/jetty/embedded/SplitFileServer.java[]
|
||||
----
|
||||
|
|
|
@ -31,21 +31,21 @@ The most common use is to rewrite request URIs, but it is capable of much more:
|
|||
|
||||
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, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
$ java -jar start.jar --add-to-start=rewrite
|
||||
....
|
||||
----
|
||||
|
||||
_____
|
||||
[NOTE]
|
||||
====
|
||||
If you are running the standard Jetty distribution with the sample test webapp, there will be a demo of the rewrite module at http://localhost:8080/test/rewrite/
|
||||
_____
|
||||
====
|
||||
|
||||
==== Usage
|
||||
|
||||
The rewrite module enables the following Jetty xml config file on the execution path:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
include::{SRCDIR}/jetty-rewrite/src/main/config/etc/jetty-rewrite.xml[]
|
||||
----
|
||||
|
@ -54,7 +54,7 @@ As the commented out code shows, you configure the `RewriteHandler` by adding va
|
|||
|
||||
There is an example of link:#rewrite-rules[rules] configuration in the standard distribution in the `demo-base/etc/demo-rewrite-rules.xml` file:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
include::{SRCDIR}/tests/test-webapps/test-jetty-webapp/src/main/config/demo-base/etc/demo-rewrite-rules.xml[]
|
||||
----
|
||||
|
@ -63,7 +63,7 @@ include::{SRCDIR}/tests/test-webapps/test-jetty-webapp/src/main/config/demo-base
|
|||
|
||||
This is an example for embedded Jetty, which does something similar to the configuration file example above:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
Server server = new Server();
|
||||
|
||||
|
|
|
@ -36,7 +36,7 @@ If `_exitJvm` is set to true a hard `System.exit()` call is being made.
|
|||
This is an example of how you can setup this handler directly with the Server.
|
||||
It can also be added as a part of handler chain or collection.
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
Server server = new Server(8080);
|
||||
HandlerList handlers = new HandlerList();
|
||||
|
@ -48,7 +48,7 @@ It can also be added as a part of handler chain or collection.
|
|||
|
||||
This is an example that you can use to call the shutdown handler from within java.
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
public static void attemptShutdown(int port, String shutdownCookie) {
|
||||
try {
|
||||
|
|
|
@ -35,18 +35,18 @@ Jetty currently has two main statistics collection mechanisms:
|
|||
* The `StatisticsHandler` class may be used to collect statistics for HTTP requests.
|
||||
|
||||
The `StatisticsHandler` and `ConnectionStatistics` are not included in the default Jetty configuration, these need to be configured manually or enabled using the Jetty `stats` module on the command line.
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
$ java -jar {$jetty.home}/start.jar --add-to-start=stats
|
||||
....
|
||||
----
|
||||
|
||||
In addition to these, the `SessionHandler` and `DefaultSessionCache` classes collect statistics for sessions.
|
||||
These statistics are enabled by default and are accessible via JMX interface.
|
||||
|
||||
_____
|
||||
[NOTE]
|
||||
====
|
||||
To view statistics, you have to be able to connect to Jetty using either JConsole or some other JMX agent. See xref:using-jmx[] for more information.
|
||||
_____
|
||||
====
|
||||
|
||||
[[request-statistics]]
|
||||
==== Request Statistics
|
||||
|
@ -58,7 +58,7 @@ You can enable the `StatisticsHandler` by activating the `stats` modules on the
|
|||
Alternately, if you are making multiple changes to the Jetty configuration, you could include statistics handler configuration into your own Jetty xml configuration.
|
||||
The following fragment shows how to configure a top level statistics handler:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<Configure id="Server" class="org.eclipse.jetty.server.Server">
|
||||
<Call name="insertHandler">
|
||||
|
@ -77,7 +77,7 @@ The current and maximum number of connections are the only "live" statistics.
|
|||
|
||||
The following example shows how to turn on connection statistics in the Jetty XML format.
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<Configure id="Server" class="org.eclipse.jetty.server.Server">
|
||||
<Call name="addBeanToAllConnectors">
|
||||
|
@ -91,7 +91,7 @@ The following example shows how to turn on connection statistics in the Jetty XM
|
|||
A special variant of `ConnectionStatistics` called `IncludeExcludeConnectionStatistics` allows you to refine which types of connection you want to collect statistics for.
|
||||
|
||||
The following example shows how this can be used to record statistics only for WebSocket connections.
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<Configure id="Server" class="org.eclipse.jetty.server.Server">
|
||||
<Call name="addBeanToAllConnectors">
|
||||
|
|
|
@ -31,12 +31,12 @@ 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, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
$ mkdir -p /usr/jetty/wordpress
|
||||
$ cd /usr/jetty/wordpress
|
||||
$ java -jar $JETTY_HOME/start.jar --add-to-start=fcgi,http,deploy
|
||||
....
|
||||
----
|
||||
|
||||
Therefore `$JETTY_BASE=/usr/jetty/wordpress`.
|
||||
|
||||
|
@ -46,7 +46,7 @@ For FastCGI there is no web application that needs developed - all the work has
|
|||
As such you only need to deploy a Jetty context XML file that configures the web application directly.
|
||||
Copy and paste the following content as `$JETTY_BASE/webapps/jetty-wordpress.xml`:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_3.dtd">
|
||||
|
@ -138,11 +138,11 @@ Refer to the link:{JDURL}/org/eclipse/jetty/fcgi/server/proxy/FastCGIProxyServle
|
|||
|
||||
The last step is to start Jetty (see xref:startup[]) and navigate to `http://localhost:8080` with your browser and enjoy WordPress:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
$ cd $JETTY_BASE
|
||||
$ java -jar /opt/jetty/start.jar
|
||||
....
|
||||
----
|
||||
|
||||
[[configuring-fastcgi-http2]]
|
||||
==== Configuring Jetty to Proxy HTTP/2 to FastCGI
|
||||
|
@ -151,11 +151,11 @@ In order to configure Jetty to listen for HTTP/2 requests from clients that are
|
|||
|
||||
Enabling the `http2` is easy; in additions to the modules you have enabled above, add the `http2` module:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
$ cd $JETTY_BASE
|
||||
$ java -jar $JETTY_HOME/start.jar --add-to-start=http2
|
||||
....
|
||||
----
|
||||
|
||||
The command above adds the `http2` module (and its dependencies) to the existing modules and uses the default Jetty keystore to provide the key material required by TLS.
|
||||
You will want to use your own keystore with your own private key and certificate for your own domain.
|
||||
|
@ -171,10 +171,10 @@ 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, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
$ cd $JETTY_BASE
|
||||
$ java -jar $JETTY_HOME/start.jar
|
||||
....
|
||||
----
|
||||
|
||||
If you don't have a HTTP/2 enabled browser, WordPress will still be available over HTTP/1.1.
|
||||
|
|
|
@ -34,19 +34,18 @@ The instructions that follow are for Linux.
|
|||
|
||||
You will need HAProxy 1.5 or later, because it provides support for SSL and ALPN, both required by HTTP/2. Most Linux distributions have the HAProxy package available to be installed out of the box. For example on Ubuntu 15.04:
|
||||
|
||||
[source,screen, subs="{sub-order}"]
|
||||
....
|
||||
[source,screen]
|
||||
----
|
||||
$ sudo apt-get install haproxy
|
||||
....
|
||||
----
|
||||
|
||||
Alternatively you can download the HAProxy source code and build it on your environment by following the README bundled with the HAProxy source code tarball.
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
HAProxy supports ALPN only if built with OpenSSL 1.0.2 or greater.
|
||||
Use `haproxy -vv` to know with which OpenSSL version HAProxy has been built.
|
||||
____
|
||||
|
||||
====
|
||||
[[http2-haproxy-ssl]]
|
||||
==== Setup SSL for HAProxy
|
||||
|
||||
|
@ -62,8 +61,8 @@ HAProxy will need a single file containing the X509 certificates and the private
|
|||
|
||||
Let's use `keytool` to generate a self signed certificate:
|
||||
|
||||
[source,screen, subs="{sub-order}"]
|
||||
....
|
||||
[source,screen]
|
||||
----
|
||||
$ keytool -genkeypair -keyalg RSA -keystore keystore.p12 -storetype pkcs12 -storepass storepwd -ext SAN=DNS:domain.com
|
||||
What is your first and last name?
|
||||
[Unknown]: *.domain.com
|
||||
|
@ -79,31 +78,31 @@ What is the two-letter country code for this unit?
|
|||
[Unknown]: IT
|
||||
Is CN=*.domain.com, OU=Unit, O=Domain, L=Torino, ST=TO, C=IT correct?
|
||||
[no]: yes
|
||||
....
|
||||
----
|
||||
|
||||
The above command will generate a self signed certificate and private key for `domain.com` and subdomains, stored in the `keystore.p12` file in PKCS#12 format.
|
||||
We need to extract the certificate and the private key in PEM format.
|
||||
|
||||
To extract the certificate into `certificate.pem`:
|
||||
|
||||
[source,screen, subs="{sub-order}"]
|
||||
....
|
||||
[source,screen]
|
||||
----
|
||||
$ keytool -exportcert -keystore keystore.p12 -storetype pkcs12 -storepass storepwd -rfc -file certificate.pem
|
||||
....
|
||||
----
|
||||
|
||||
To export the private key into `private_key.pem`:
|
||||
|
||||
[source,screen, subs="{sub-order}"]
|
||||
....
|
||||
[source,screen]
|
||||
----
|
||||
$ openssl pkcs12 -in keystore.p12 -nodes -nocerts -out private_key.pem -passin pass:storepwd
|
||||
....
|
||||
----
|
||||
|
||||
At this point you just need to concatenate the two files into one, in the correct order:
|
||||
|
||||
[source,screen, subs="{sub-order}"]
|
||||
....
|
||||
[source,screen]
|
||||
----
|
||||
$ cat certificate.pem private_key.pem > domain.pem
|
||||
....
|
||||
----
|
||||
|
||||
The `domain.pem` file will be used later by HAProxy.
|
||||
|
||||
|
@ -113,8 +112,8 @@ The `domain.pem` file will be used later by HAProxy.
|
|||
Now we can setup `haproxy.cfg` to configure HAProxy.
|
||||
This is a minimal configuration:
|
||||
|
||||
[source, ,subs="{sub-order}"]
|
||||
....
|
||||
[source]
|
||||
----
|
||||
global
|
||||
tune.ssl.default-dh-param 1024
|
||||
|
||||
|
@ -137,7 +136,7 @@ default_backend be_http
|
|||
backend be_http
|
||||
mode tcp
|
||||
server domain 127.0.0.1:8282
|
||||
....
|
||||
----
|
||||
|
||||
The HAProxy configuration file works in the following way.
|
||||
The `fe_http` front-end accepts connections on port 80 and redirects them to use the `https` scheme.
|
||||
|
@ -157,32 +156,31 @@ Since the `http2c` module depends on the `http` module, the `http` module will b
|
|||
|
||||
Additionally, you will also enable the `deploy` module to be able to deploy a sample web application:
|
||||
|
||||
[source,screen, subs="{sub-order}"]
|
||||
....
|
||||
[source,screen]
|
||||
----
|
||||
$ JETTY_BASE=haproxy-jetty-http2
|
||||
$ mkdir $JETTY_BASE
|
||||
$ cd $JETTY_BASE
|
||||
$ java -jar $JETTY_HOME/start.jar --add-to-start=http2c,deploy
|
||||
....
|
||||
----
|
||||
|
||||
Now let's deploy a demo web application and start Jetty:
|
||||
|
||||
[source,screen, subs="{sub-order}"]
|
||||
....
|
||||
[source,screen]
|
||||
----
|
||||
$ cd $JETTY_BASE
|
||||
$ cp $JETTY_HOME/demo-base/webapps/async-rest.war $JETTY_BASE/webapps/
|
||||
$ java -jar $JETTY_HOME/start.jar jetty.http.host=127.0.0.1 jetty.http.port=8282
|
||||
....
|
||||
----
|
||||
|
||||
Now you can browse https://domain.com/async-rest (replace `domain.com` with your own domain, or with `localhost`, to make this example work).
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
You want the Jetty connector that listens on port 8282 to be available only to HAProxy, and not to remote clients.
|
||||
For this reason, you want to specify the `jetty.http.host` property on the command line (or in `start.ini`/ `start.d/http.ini` to make this setting persistent) to bind the Jetty connector only on the loopback interface (127.0.0.1), making it available to HAProxy but not to remote clients.
|
||||
If your Jetty instance runs on a different machine and/or on a different (sub)network, you may want to adjust both the back-end section of the HAProxy configuration file and the `jetty.http.host` property to match accordingly.
|
||||
____
|
||||
|
||||
====
|
||||
Browsers supporting HTTP/2 will connect to HAProxy, which will decrypt the traffic and send it to Jetty.
|
||||
Likewise, HTTP/1.1 clients will connect to HAProxy, which will decrypt the traffic and send it to Jetty.
|
||||
|
||||
|
|
|
@ -24,8 +24,8 @@ existing connector.
|
|||
Thus configuring HTTP/2 is a combination of configuring common properties on the connector and HTTP/2 specific properties on the connection factory.
|
||||
The modules and XML files involved can be seen with the following commands:
|
||||
|
||||
[source,screen, subs="{sub-order}"]
|
||||
....
|
||||
[source,screen]
|
||||
----
|
||||
$ java -jar $JETTY_HOME/start.jar --list-modules
|
||||
...
|
||||
1) alpn-impl <transitive>
|
||||
|
@ -48,17 +48,16 @@ $ java -jar $JETTY_HOME/start.jar --list-config
|
|||
...
|
||||
${jetty.home}/etc/jetty-http2.xml
|
||||
${jetty.home}/etc/jetty-https.xml
|
||||
....
|
||||
----
|
||||
|
||||
The common properties associated with connectors (host,port, timeouts, etc.) can be set in the module ini files (or `start.ini` if `--add-to-start` was used): `${jetty.base}/start.d/http.ini` and `${jetty.base}/start.d/ssl.ini`.
|
||||
These properties are instantiated in the associated XML files: `${jetty.home}/etc/jetty-http.xml`; `${jetty.home}/etc/jetty-ssl.xml`, plus the SSL keystore is instantiated in `${jetty.home}/etc/jetty-ssl-context.xml`.
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
If you are planning to edit XML files, make sure to copy them to your `{$jetty.base}/etc/` directory before doing so.
|
||||
The XML files that come with the Jetty distribution should *not* be modified directly.
|
||||
____
|
||||
|
||||
====
|
||||
HTTP/2 specific properties can be set in the module ini files: `${jetty.base}/start.d/http2.ini` and `${jetty.base}/start.d/http2c.ini`, which are instantiated in the associated XML files: `${jetty.home}/etc/jetty-http2.xml`; `${jetty.home}/etc/jetty-http2c.xml`, respectively.
|
||||
Currently there are very few HTTP/2 configuration properties and the default values are reasonable:
|
||||
|
||||
|
|
|
@ -24,7 +24,7 @@ This will reduce the amount of round-trips necessary to retrieve all the resourc
|
|||
|
||||
HTTP/2 Push can be automated in your application by configuring a link:{JDURL}/org/eclipse/jetty/servlets/PushCacheFilter.html[`PushCacheFilter`] in the `web.xml`, in this way:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<web-app
|
||||
|
|
|
@ -22,29 +22,29 @@
|
|||
This section is written assuming that a link:#startup-base-and-home[Jetty base directory] is being used.
|
||||
A demo Jetty base that supports HTTP/1, HTTPS/1 and deployment from a webapps directory can be created with the commands:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
$ JETTY_BASE=http2-demo
|
||||
$ mkdir $JETTY_BASE
|
||||
$ cd $JETTY_BASE
|
||||
$ java -jar $JETTY_HOME/start.jar --add-to-start=http,https,deploy
|
||||
....
|
||||
----
|
||||
|
||||
The commands above create a `$JETTY_BASE` directory called `http2-demo`, and initializes the `http,` `https` and `deploy` modules (and their dependencies) to run a typical Jetty Server on port 8080 (for HTTP/1) and 8443 (for HTTPS/1).
|
||||
Note that the HTTPS module downloads a demo keystore file with a self signed certificate, which needs to be replaced by a Certificate Authority issued certificate for real deployment.
|
||||
|
||||
To add HTTP/2 to this demo base, it is just a matter of enabling the `http2` module with the following command:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
$ java -jar $JETTY_HOME/start.jar --add-to-start=http2
|
||||
....
|
||||
----
|
||||
|
||||
This command does not create a new connector, but instead simply adds the HTTP/2 protocol to the existing HTTPS/1 connector, so that it now supports both protocols on port 8443.
|
||||
To do this, it also transitively enables the ALPN module for protocol negotiation.
|
||||
The support for each protocol can be seen in the info logging when the server is started:
|
||||
|
||||
[source,screen, subs="{sub-order}"]
|
||||
[source,screen]
|
||||
----
|
||||
$ java -jar $JETTY_HOME/start.jar
|
||||
...
|
||||
|
@ -62,13 +62,13 @@ Note that a browser pointed at this server with URL starting with `http://localh
|
|||
HTTP/2 can be enabled on the plain text connector and the server restarted with the following command:
|
||||
|
||||
[source,screen]
|
||||
....
|
||||
----
|
||||
$ java -jar $JETTY_HOME/start.jar --add-to-start=http2c
|
||||
$ java -jar $JETTY_HOME/start.jar
|
||||
..
|
||||
2015-06-17 14:16:12.549:INFO:oejs.ServerConnector:main: Started ServerConnector@6f32cd1e{HTTP/1.1,[http/1.1, h2c, h2c-17]}{0.0.0.0:8080}
|
||||
2015-06-17 14:16:12.782:INFO:oejs.ServerConnector:main: Started ServerConnector@711f39f9{SSL,[ssl, alpn, h2, h2-17, http/1.1]}{0.0.0.0:8443}
|
||||
..
|
||||
....
|
||||
----
|
||||
|
||||
No major browser currently supports plain text HTTP/2, so the 8080 port will only be able to use HTTP/2 with specific clients (eg `curl`) that use the upgrade mechanism or assume HTTP/2.
|
||||
|
|
|
@ -25,12 +25,11 @@ The requirements for running HTTP/2 are JDK 8 or greater, and typically also ALP
|
|||
|
||||
A server deployed over TLS (SSL) normally advertises the HTTP/2 protocol via the TLS extension Application Layer Protocol Negotiation link:#alpn[(ALPN)].
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
To use HTTP/2 in Jetty via a TLS connector you need to add the link:#alpn-starting[ALPN boot jar] in the boot classpath.
|
||||
This is done automatically when using the Jetty distribution's start.jar link:#startup-modules[module system], but must be configured directly otherwise.
|
||||
____
|
||||
|
||||
====
|
||||
[[http2-security-update]]
|
||||
==== Jetty HTTP/2 Security Update
|
||||
|
||||
|
|
|
@ -26,17 +26,17 @@ When following the instructions given below, please also ensure that you make an
|
|||
|
||||
The simplest way to enable support is to add the JMX-Remote support module to your `{$jetty.base}`.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
[mybase]$ java /opt/jetty-dist/start.jar --add-to-start=jmx-remote, jmx
|
||||
INFO: jmx-remote initialised in ${jetty.base}/start.ini
|
||||
INFO: jmx initialised in ${jetty.base}/start.ini
|
||||
....
|
||||
----
|
||||
|
||||
Then open the `{$jetty.base}/start.ini` (or `{$jetty.base}/start.d/jmx-remote.ini`) file and edit the properties to suit your needs:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
#
|
||||
# Initialize module jmx-remote
|
||||
#
|
||||
|
@ -45,7 +45,7 @@ Then open the `{$jetty.base}/start.ini` (or `{$jetty.base}/start.d/jmx-remote.in
|
|||
## Enable for an open port accessible by remote machines
|
||||
jetty.jmxrmihost=localhost
|
||||
jetty.jmxrmiport=1099
|
||||
....
|
||||
----
|
||||
|
||||
[[jetty-jconsole-monitoring]]
|
||||
==== Monitoring Jetty with JConsole
|
||||
|
@ -57,18 +57,17 @@ To monitor Jetty's server status with JConsole, start Jetty and then start JCons
|
|||
After you start Jetty, you will see a dialog box in JConsole with a list of running processes to which you can connect.
|
||||
It should look something like so:
|
||||
|
||||
image:images/jconsole1.jpg[image,width=576]
|
||||
image:administration/jmx/images/jconsole1.jpg[image,width=576]
|
||||
|
||||
____
|
||||
[IMPORTANT]
|
||||
====
|
||||
If you don't see your Jetty process in the list of processes you can connect to, quickly switch tabs, or close and reopen a new "New Connection" dialog window.
|
||||
This forces JConsole to refresh the list, and recognize your newly-started Jetty process.
|
||||
____
|
||||
|
||||
====
|
||||
Select the start.jar entry and click the "Connect" button.
|
||||
A new JConsole window opens:
|
||||
|
||||
image:images/jconsole2.jpg[image,width=576]
|
||||
image:administration/jmx/images/jconsole2.jpg[image,width=576]
|
||||
|
||||
From this window you can monitor memory usage, thread usage, classloading and VM statistics.
|
||||
You can also perform operations such as a manual garbage collect.
|
||||
|
@ -80,7 +79,7 @@ The MBean tab of JConsole allows access to managed objects within the Java appli
|
|||
If you also want to interact with the Jetty JMX implementation via JConsole, you need to start Jetty JMX in a form that JConsole can access.
|
||||
See xref:using-jmx[] for more information.
|
||||
|
||||
image:images/jconsole3.png[image,width=576]
|
||||
image:administration/jmx/images/console3.png[image,width=576]
|
||||
|
||||
[[jetty-jmc-monitoring]]
|
||||
==== Monitoring Jetty with JMC
|
||||
|
@ -92,18 +91,17 @@ To monitor Jetty's server status with JMC, start Jetty and then start JMC by typ
|
|||
After you start Jetty, you will see a dialog box in JMC with a list of running processes to which you can connect.
|
||||
It should look something like so:
|
||||
|
||||
image:images/jmc1.png[image,width=576]
|
||||
image:administration/jmx/images/jmc1.png[image,width=576]
|
||||
|
||||
____
|
||||
[IMPORTANT]
|
||||
====
|
||||
If you don't see your Jetty process in the list of processes you can connect to, quickly switch tabs, or close and reopen a new "New Connection" dialog window.
|
||||
This forces JMC to refresh the list, and recognize your newly-started Jetty process.
|
||||
____
|
||||
|
||||
====
|
||||
Double-click the start.jar entry or right-click the start.jar entry and select "Start JMX Console".
|
||||
A new JMC window opens on the right:
|
||||
|
||||
image:images/jmc2.png[image,width=576]
|
||||
image:administration/jmx/images/jmc2.png[image,width=576]
|
||||
|
||||
From this window you can monitor memory usage, thread usage, classloading and VM statistics.
|
||||
You can also perform operations such as a manual garbage collect.
|
||||
|
@ -115,4 +113,4 @@ The MBean tab of JMC allows access to managed objects within the Java applicatio
|
|||
If you also want to interact with the Jetty JMX implementation via JMC, you need to start Jetty JMX in a form that JMC can access.
|
||||
See xref:using-jmx[] for more information.
|
||||
|
||||
image:images/jmc3.png[image,width=576]
|
||||
image:administration/jmx/images/jmc3.png[image,width=576]
|
||||
|
|
|
@ -105,7 +105,7 @@ description::
|
|||
|
||||
The following is an example of each of the annotations mentioned above in practice.
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
|
||||
package com.acme;
|
||||
|
|
|
@ -48,7 +48,7 @@ In these cases, you have to enable link:#jmx-remote-access[JMX Remote Access].
|
|||
JMX is not enabled by default in the Jetty distribution.
|
||||
To enable JMX in the Jetty distribution run the following, where `{$jetty.home}` is the directory where you have the Jetty distribution installed, and `${jetty.base}` is the directory where you have your Jetty configuration (see link:#startup-base-and-home[the documentation for Jetty base vs. home examples]):
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
$ cd ${jetty.base}
|
||||
$ java -jar {$jetty.home}/start.jar --add-to-start=jmx
|
||||
|
@ -80,7 +80,7 @@ Because logging is initialized prior to the `MBeanContainer` (even before the `S
|
|||
|
||||
If you are using the link:#jetty-maven-plugin[Jetty Maven plugin] you should copy the `${jetty.home}/etc/jetty-jmx.xml` file into your webapp project somewhere, such as `src/main/config/etc/`, then add a `<jettyXml>` element to the `<configuration>` element of the Jetty Maven Plugin:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<plugin>
|
||||
<groupid>org.eclipse.jetty</groupid>
|
||||
|
@ -124,14 +124,14 @@ Connecting to the remote JVM is a two step process:
|
|||
The configuration for the RMI registry and the RMI server is specified by a `JMXServiceURL`.
|
||||
The string format of an RMI `JMXServiceURL` is:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
service:jmx:rmi://<rmi_server_host>:<rmi_server_port>/jndi/rmi://<rmi_registry_host>:<rmi_registry_port>/jmxrmi
|
||||
----
|
||||
|
||||
Default values are:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
rmi_server_host = localhost
|
||||
rmi_server_port = 1099
|
||||
|
@ -149,7 +149,7 @@ If you need to allow JMX remote access through a firewall, you must open both th
|
|||
|
||||
Examples:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
service:jmx:rmi:///jndi/rmi:///jmxrmi
|
||||
rmi_server_host = local host address
|
||||
|
@ -183,7 +183,7 @@ This is especially important when binding the RMI server host to the loopback ad
|
|||
|
||||
Similarly to link:#jmx-standalone-jetty[enabling JMX in a standalone Jetty server], you enable the `jmx-remote` module:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
$ cd ${jetty.base}
|
||||
$ java -jar {$jetty.home}/start.jar --add-to-start=jmx-remote
|
||||
|
@ -193,7 +193,7 @@ $ java -jar {$jetty.home}/start.jar --add-to-start=jmx-remote
|
|||
|
||||
When running Jetty embedded into an application, create and configure a `ConnectorServer`:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
Server server = new Server();
|
||||
|
||||
|
@ -213,11 +213,10 @@ The `JMXServiceURL` above specifies that the RMI server binds to the wildcard ad
|
|||
===== JMX Remote Access Authorization
|
||||
|
||||
The standard `JMXConnectorServer` provides several options to authorize access.
|
||||
For a complete guide to controlling authentication and authorization in JMX, see https://blogs.oracle.com/lmalventosa/entry/jmx_authentication_authorization[Authentication and Authorization in JMX RMI connectors].
|
||||
|
||||
To authorize access to the `JMXConnectorServer` you can use this configuration, where the `jmx.password` and `jmx.access` files have the format specified in the blog entry above:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<New id="ConnectorServer" class="org.eclipse.jetty.jmx.ConnectorServer">
|
||||
<Arg>
|
||||
|
@ -251,7 +250,7 @@ To authorize access to the `JMXConnectorServer` you can use this configuration,
|
|||
|
||||
Similarly, in code:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
JMXServiceURL jmxURL = new JMXServiceURL("rmi", null, 1099, "/jndi/rmi:///jmxrmi");
|
||||
Map<String, Object> env = new HashMap<>();
|
||||
|
@ -269,7 +268,7 @@ The JMX communication via RMI happens by default in clear-text.
|
|||
|
||||
It is possible to configure the `ConnectorServer` with a `SslContextFactory` so that the JMX communication via RMI is encrypted:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<New id="ConnectorServer" class="org.eclipse.jetty.jmx.ConnectorServer">
|
||||
<Arg>
|
||||
|
@ -288,7 +287,7 @@ It is possible to configure the `ConnectorServer` with a `SslContextFactory` so
|
|||
|
||||
Similarly, in code:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
SslContextFactory.Server sslContextFactory = new SslContextFactory.Server();
|
||||
sslContextFactory.setKeyStorePath("/path/to/keystore");
|
||||
|
@ -313,7 +312,7 @@ If that is not the case (for example the certificate is self-signed), then you n
|
|||
|
||||
For example, trying to connect using the JDK standard `JMXConnector` with both the RMI server and the RMI registry to `domain.com`:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
// System properties necessary for an RMI client to trust a self-signed certificate.
|
||||
System.setProperty("javax.net.ssl.trustStore", "/path/to/trustStore");
|
||||
|
@ -331,7 +330,7 @@ try (JMXConnector client = JMXConnectorFactory.connect(jmxURL, clientEnv))
|
|||
|
||||
Similarly, to launch JMC:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
$ jmc -vmargs -Djavax.net.ssl.trustStore=/path/to/trustStore -Djavax.net.ssl.trustStorePassword=secret
|
||||
----
|
||||
|
@ -347,7 +346,7 @@ In this case you want to configure the `ConnectorServer` with a `JMXServiceURL`
|
|||
|
||||
Then you setup the local port forwarding with the SSH tunnel:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
$ ssh -L 1099:localhost:1099 <user>@<machine_host>
|
||||
----
|
||||
|
|
|
@ -25,7 +25,7 @@
|
|||
Sometimes it is useful to pass configuration information to a webapp at runtime that you either cannot or cannot conveniently code into a `web.xml` env-entry.
|
||||
In such cases, you can use the `org.eclipse.jetty.plus.jndi.EnvEntry` class, and even override an entry of the same name in `web.xml`.
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<New class="org.eclipse.jetty.plus.jndi.EnvEntry">
|
||||
<Arg></Arg>
|
||||
|
@ -57,7 +57,7 @@ Be aware that if you take advantage of this feature, your web application is __n
|
|||
|
||||
To use the `env-entry` configured above, use code in your `servlet/filter/etc.`, such as:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
import javax.naming.InitialContext;
|
||||
|
||||
|
@ -103,7 +103,7 @@ Jetty can use any DataSource implementation available on its classpath.
|
|||
In this example, the DataSource is from the http://db.apache.org/derby[Derby] relational database, but you can use any implementation of a `javax.sql.DataSource`.
|
||||
This example configures it as scoped to a web app with the id of __wac__:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<Configure id='wac' class="org.eclipse.jetty.webapp.WebAppContext">
|
||||
<New id="myds" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
|
@ -124,7 +124,7 @@ If you do not have the appropriate `resource-ref` set up in your `web.xml`, it i
|
|||
|
||||
Here's an example `web.xml` declaration for the datasource above:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<resource-ref>
|
||||
<res-ref-name>jdbc/myds</res-ref-name>
|
||||
|
@ -135,7 +135,7 @@ Here's an example `web.xml` declaration for the datasource above:
|
|||
|
||||
To look up your DataSource in your `servlet/filter/etc.`:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
import javax.naming.InitialContext;
|
||||
import javax.sql.DataSource;
|
||||
|
@ -152,12 +152,11 @@ public class MyClass {
|
|||
}
|
||||
----
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
Careful! When configuring Resources, ensure that the type of object you configure matches the type of object you expect to look up in `java:comp/env`.
|
||||
For database connection factories, this means that the object you register as a Resource _must_ implement the `javax.sql.DataSource` interface.
|
||||
____
|
||||
|
||||
====
|
||||
For more examples of datasource configurations, see xref:jndi-datasource-examples[].
|
||||
|
||||
[[configuring-jms-queues-topics-connectionfactories]]
|
||||
|
@ -167,7 +166,7 @@ Jetty can bind any implementation of the JMS destinations and connection factori
|
|||
You just need to ensure the implementation Jars are available on Jetty's classpath.
|
||||
Here is an example of binding an http://activemq.apache.org[ActiveMQ] in-JVM connection factory:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<Configure id='wac' class="org.eclipse.jetty.webapp.WebAppContext">
|
||||
<New id="cf" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
|
@ -184,7 +183,7 @@ Here is an example of binding an http://activemq.apache.org[ActiveMQ] in-JVM con
|
|||
|
||||
The entry in `web.xml` would be:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<resource-ref>
|
||||
<res-ref-name>jms/connectionFactory</res-ref-name>
|
||||
|
@ -200,7 +199,7 @@ TODO: put in an example of a QUEUE from progress demo
|
|||
|
||||
Jetty also provides infrastructure for access to `javax.mail.Sessions` from within an application:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<Configure id='wac' class="org.eclipse.jetty.webapp.WebAppContext">
|
||||
<New id="mail" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
|
@ -226,12 +225,11 @@ Jetty also provides infrastructure for access to `javax.mail.Sessions` from with
|
|||
This setup creates an instance of the `org.eclipse.jetty.jndi.factories.MailSessionReference` class, calls it's setter methods to set up the authentication for the mail system, and populates a set of Properties, setting them on the `MailSessionReference` instance.
|
||||
The result is that an application can look up `java:comp/env/mail/Session` at runtime and obtain access to a `javax.mail.Session` that has the necessary configuration to permit it to send email via SMTP.
|
||||
|
||||
____
|
||||
[TIP]
|
||||
====
|
||||
You can set the password to be plain text, or use Jetty's link:#configuring-security-secure-passwords[Secure Password Obfuscation] (OBF:) mechanism to make the config file a little more secure from prying eyes.
|
||||
Remember that you cannot use the other Jetty encryption mechanisms of MD5 and Crypt because they do not allow you to recover the original password, which the mail system requires.
|
||||
____
|
||||
|
||||
====
|
||||
[[configuring-xa-transactions]]
|
||||
==== Configuring XA Transactions
|
||||
|
||||
|
@ -240,7 +238,7 @@ Jetty does not ship with one as standard, but you can plug in the one you prefer
|
|||
You can configure a transaction manager using the link:{JDURL}/org/eclipse/jetty/plus/jndi/Transaction.html[JNDI Transaction] object in a Jetty config file.
|
||||
The following example configures the http://www.atomikos.com/[Atomikos] transaction manager:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<New id="tx" class="org.eclipse.jetty.plus.jndi.Transaction">
|
||||
<Arg>
|
||||
|
@ -257,7 +255,7 @@ For example:
|
|||
|
||||
In a context xml file:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<Configure id='wac' class="org.eclipse.jetty.webapp.WebAppContext">
|
||||
<New id="myds" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
|
@ -275,7 +273,7 @@ In a context xml file:
|
|||
|
||||
In a `web.xml` file:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<resource-ref>
|
||||
<res-ref-name>jdbc/mydatasource</res-ref-name>
|
||||
|
@ -293,7 +291,7 @@ For the example above, you can refer to the `jdbc/mydatasource` resource as `jdb
|
|||
|
||||
In a context xml file declare `jdbc/mydatasource`:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<Configure id='wac' class="org.eclipse.jetty.webapp.WebAppContext">
|
||||
<New id="myds" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
|
@ -312,7 +310,7 @@ In a context xml file declare `jdbc/mydatasource`:
|
|||
Then in a `WEB-INF/jetty-env.xml` file, link the name `jdbc/mydatasource` to the name you want to reference it as in
|
||||
`web.xml`, which in this case is `jdbc/mydatasource1`:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<New id="map1" class="org.eclipse.jetty.plus.jndi.Link">
|
||||
<Arg><Ref refid='wac'/></Arg>
|
||||
|
@ -323,7 +321,7 @@ Then in a `WEB-INF/jetty-env.xml` file, link the name `jdbc/mydatasource` to the
|
|||
|
||||
Now you can refer to `jdbc/mydatasource1` in the `web.xml` like this:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<resource-ref>
|
||||
<res-ref-name>jdbc/mydatasource1</res-ref-name>
|
||||
|
|
|
@ -21,14 +21,13 @@
|
|||
|
||||
Here are examples of configuring a JNDI datasource for various databases.
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
Read xref:configuring-datasources[] in xref:jndi-configuration[] for more information about configuring datasources.
|
||||
____
|
||||
|
||||
====
|
||||
All of these examples correspond to a `resource-ref` in `web.xml`.
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<resource-ref>
|
||||
<description>My DataSource Reference</description>
|
||||
|
@ -42,11 +41,10 @@ These examples assume that all of the datasources are declared at the JVM scope,
|
|||
You can configure all JNDI resources in a `jetty.xml` file, a `WEB-INF/jetty-env.xml` file, or a context XML file.
|
||||
See the section xref:jndi-where-to-declare[] for more information.
|
||||
|
||||
____
|
||||
[IMPORTANT]
|
||||
====
|
||||
You must provide Jetty with the libraries necessary to instantiate the datasource you have configured by putting the corresponding Jar in `JETTY_HOME/lib/ext`.
|
||||
____
|
||||
|
||||
====
|
||||
[[pooling-datasources]]
|
||||
==== Pooling DataSources
|
||||
|
||||
|
@ -71,7 +69,7 @@ The following is a list of the pooled datasource examples we have worked with in
|
|||
Connection pooling, available at http://search.maven.org/remotecontent?filepath=com/zaxxer/HikariCP/1.4.0/HikariCP-1.4.0.jar[HikariCP Download].
|
||||
All configuration options for HikariCP are described here: https://github.com/brettwooldridge/HikariCP[HikariCP documentation].
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<New id="DSTest" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
<Arg></Arg>
|
||||
|
@ -102,7 +100,7 @@ All configuration options for HikariCP are described here: https://github.com/br
|
|||
Connection pooling, available at http://jolbox.com/index.html?page=http://jolbox.com/download.html[BoneCP Download].
|
||||
All configuration options for BoneCP are described here: http://jolbox.com/bonecp/downloads/site/apidocs/com/jolbox/bonecp/BoneCPDataSource.html[BoneCP API].
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
|
||||
<New id="DSTest" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
|
@ -128,7 +126,7 @@ All configuration options for BoneCP are described here: http://jolbox.com/bonec
|
|||
|
||||
Connection pooling, available at https://repo1.maven.org/maven2/c3p0/c3p0/0.9.1.2/c3p0-0.9.1.2.jar[c3p0 Jar].
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<New id="DSTest" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
<Arg></Arg>
|
||||
|
@ -149,7 +147,7 @@ Connection pooling, available at https://repo1.maven.org/maven2/c3p0/c3p0/0.9.1.
|
|||
|
||||
Connection pooling, available at https://repo1.maven.org/maven2/commons-dbcp/commons-dbcp/1.2/commons-dbcp-1.2.jar[dbcp Jar].
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<New id="DSTest" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
<Arg></Arg>
|
||||
|
@ -171,7 +169,7 @@ Connection pooling, available at https://repo1.maven.org/maven2/commons-dbcp/com
|
|||
|
||||
Connection pooling + XA transactions.
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<New id="DSTest" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
<Arg></Arg>
|
||||
|
@ -206,7 +204,7 @@ Connection pooling + XA transactions.
|
|||
|
||||
Implements `javax.sql.DataSource` and `javax.sql.ConnectionPoolDataSource`.
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<New id="DSTest" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
<Arg></Arg>
|
||||
|
@ -226,7 +224,7 @@ Implements `javax.sql.DataSource` and `javax.sql.ConnectionPoolDataSource`.
|
|||
|
||||
Implements `javax.sql.ConnectionPoolDataSource`.
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
|
||||
<New id="DSTest" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
|
@ -252,7 +250,7 @@ Implements `javax.sql.ConnectionPoolDataSource`.
|
|||
|
||||
Implements `javax.sql.ConnectionPoolDataSource`.
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<New id="DSTest" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
<Arg></Arg>
|
||||
|
@ -288,7 +286,7 @@ The following is a list of the non-pooled datasource examples:
|
|||
|
||||
Implements `javax.sql.DataSource` and `javax.sql.ConnectionPoolDataSource`.
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<New id="DSTest" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
<Arg></Arg>
|
||||
|
@ -310,7 +308,7 @@ Implements `javax.sql.DataSource` and `javax.sql.ConnectionPoolDataSource`.
|
|||
|
||||
Implements `javax.sql.DataSource` and `javax.sql.ConnectionPoolDataSource`.
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<New id="DSTest" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
<Arg></Arg>
|
||||
|
@ -343,7 +341,7 @@ For more information, refer to: http://docs.oracle.com/cd/B14117_01/java.101/b10
|
|||
|
||||
Implements `javax.sql.DataSource`.
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<New id="DSTest" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
<Arg></Arg>
|
||||
|
@ -365,7 +363,7 @@ Implements `javax.sql.DataSource`.
|
|||
|
||||
Implements `javax.sql.DataSource`.
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<New id="DSTest" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
<Arg></Arg>
|
||||
|
@ -387,7 +385,7 @@ Implements `javax.sql.DataSource`.
|
|||
|
||||
Implements `javax.sql.DataSource`.
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<New id="DSTest" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
<Arg></Arg>
|
||||
|
|
|
@ -23,10 +23,10 @@
|
|||
|
||||
In addition to the jars that you require for your application, and the jars needed for core Jetty, you will need to place the following jars onto your classpath:
|
||||
|
||||
....
|
||||
----
|
||||
jetty-jndi.jar
|
||||
jetty-plus.jar
|
||||
....
|
||||
----
|
||||
|
||||
If you are using transactions, you will also need the `javax.transaction` api.
|
||||
You can obtain this jar link:{MVNCENTRAL}/org/eclipse/jetty/orbit/javax.transaction/1.1.1.v201105210645/javax.transaction-1.1.1.v201105210645.jar[here.]
|
||||
|
@ -39,7 +39,7 @@ Note that this jar also requires the `javax.activation` classes, which is availa
|
|||
Here is an example class that sets up some JNDI entries and deploys a webapp that references these JNDI entries in code.
|
||||
We'll use some mocked up classes for the transaction manager and the DataSource in this example for simplicity:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
import java.util.Properties;
|
||||
import org.eclipse.jetty.server.Server;
|
||||
|
|
|
@ -23,12 +23,12 @@ If you are using the standard distribution of Jetty, you must enable the _JNDI_
|
|||
As the _plus_ module depends on the _JNDI_ module, you only need to enable the _plus_ module to enable both.
|
||||
Assuming you have Jetty installed in `/opt/jetty`, and you have made a link:#startup-base-and-home[jetty base] in `/opt/jetty/my-base`, do:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
cd /opt/jetty
|
||||
cd my-base
|
||||
java -jar $JETTY_HOME/start.jar --add-to-start=plus
|
||||
....
|
||||
----
|
||||
|
||||
You can now start Jetty and use JNDI within your webapps.
|
||||
See link:#using-jndi[Using JNDI] for information on how to add entries to the JNDI environment that Jetty can look up within webapps.
|
||||
|
@ -37,9 +37,9 @@ If you have extra jars associated with your JNDI resources, for example a databa
|
|||
You will then need to enable the _ext_ module to ensure the jars in the `ext/` directory are on the classpath.
|
||||
Assuming you have Jetty installed in `/opt/jetty`, and you have made a link:#startup-base-and-home[jetty base] in `/opt/jetty/my-base`, do:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
cd /opt/jetty
|
||||
cd my-base
|
||||
java -jar $JETTY_HOME/start.jar --add-to-start=ext
|
||||
....
|
||||
----
|
||||
|
|
|
@ -24,7 +24,7 @@
|
|||
You can configure naming resources to reference in a `web.xml` file and access from within the `java:comp/env` naming environment of the webapp during execution.
|
||||
Specifically, you can configure support for the following `web.xml` elements:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<env-entry/>
|
||||
<resource-ref/>
|
||||
|
@ -52,7 +52,7 @@ For the link between a `web.xml` resource name and a naming entry
|
|||
|
||||
Declarations of each of these types follow the same general pattern:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<New class="org.eclipse.jetty.plus.jndi.xxxx">
|
||||
<Arg><!-- scope --></Arg>
|
||||
|
@ -91,7 +91,7 @@ The name is unique across the JVM instance, and is visible to all application co
|
|||
You represent this scope by a `null` first parameter to the resource declaration.
|
||||
For example:
|
||||
+
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
|
||||
<New id="cf" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
|
@ -109,7 +109,7 @@ The name is unique to a Server instance, and is only visible to code associated
|
|||
You represent this scope by referencing the Server instance as the first parameter to the resource declaration.
|
||||
For example:
|
||||
+
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<Configure id="Server" class="org.eclipse.jetty.Server">
|
||||
<New id="cf" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
|
@ -128,7 +128,7 @@ The name is unique to the WebAppContext instance, and is only visible to code as
|
|||
You represent this scope by referencing the `WebAppContext` instance as the first parameter to the resource declaration.
|
||||
For example:
|
||||
+
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<Configure id='wac' class="org.eclipse.jetty.webapp.WebAppContext">
|
||||
<New id="cf" class="org.eclipse.jetty.plus.jndi.Resource">
|
||||
|
|
|
@ -34,11 +34,10 @@ DEBUG::
|
|||
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.
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
Jetty logging produces no FATAL or SEVERE events.
|
||||
____
|
||||
|
||||
====
|
||||
[[selecting-log-framework]]
|
||||
==== Selecting the Log Framework
|
||||
|
||||
|
@ -51,12 +50,11 @@ Configure the Jetty logging layer via the `org.eclipse.jetty.util.log.Log` class
|
|||
* 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].
|
||||
____
|
||||
|
||||
====
|
||||
[[configuring-jetty-stderrlog]]
|
||||
==== The jetty-logging.properties file
|
||||
|
||||
|
|
|
@ -28,12 +28,12 @@ There is one entry per request received, and commonly in the standard NCSA forma
|
|||
A standard request log entry includes the client IP address, date, method, URL, result, size, referrer, user agent and latency.
|
||||
For example:
|
||||
|
||||
....
|
||||
----
|
||||
123.4.5.6 - - [20/Jul/2016:10:16:17 +0000]
|
||||
"GET /jetty/tut/XmlConfiguration.html HTTP/1.1"
|
||||
200 76793 "http://localhost:8080/jetty/tut/logging.html"
|
||||
"Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040614 Firefox/0.8" 342
|
||||
....
|
||||
----
|
||||
|
||||
[[implementing-request-log]]
|
||||
==== Implementing a Request Log
|
||||
|
@ -49,7 +49,7 @@ If neither of these options meets your needs, you can implement a custom request
|
|||
|
||||
To enable the Request Log module for the entire server via the Jetty distribution, it first needs to be enabled on the command line:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
$ java -jar ../start.jar --add-to-start=requestlog
|
||||
|
||||
|
@ -60,15 +60,14 @@ INFO: Base directory was modified
|
|||
|
||||
The above command will add a new `requestlog.ini` file to your link:#start-vs-startd[`{$jetty.base}/start.d` directory].
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
By default, request logs are not set to be appended, meaning a the log file is wiped clean upon sever restart.
|
||||
You can change this setting by editing the `requestlog.ini` and un-commenting the line that reads `jetty.requestlog.append=true`.
|
||||
____
|
||||
|
||||
====
|
||||
The equivalent code for embedded usages of Jetty is:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
NCSARequestLog requestLog = new NCSARequestLog("/var/logs/jetty/jetty-yyyy_mm_dd.request.log");
|
||||
requestLog.setAppend(true);
|
||||
|
@ -120,7 +119,7 @@ Both timezones are set to GMT by default.
|
|||
|
||||
To configure a separate request log for specific a web application, add the following to the context XML file.
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<Configure class="org.eclipse.jetty.webapp.WebAppContext">
|
||||
...
|
||||
|
|
|
@ -26,15 +26,15 @@ Please note that enabling these modules provides typical and basic functionality
|
|||
|
||||
Enabling these frameworks in the Jetty distribution is as easy as activating any other module, by adding `--add-to-start=<module name>` to the start command for your server, such as:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
[my-base]$ java -jar ../start.jar --add-to-start=logging-jetty
|
||||
INFO : logging-jetty initialized in ${jetty.base}/start.d/logging-jetty.ini
|
||||
INFO : resources transitively enabled
|
||||
MKDIR : ${jetty.base}/resources
|
||||
COPY : ${jetty.home}/modules/logging-jetty/resources/jetty-logging.properties to ${jetty.base}/resources/jetty-logging.properties
|
||||
INFO : Base directory was modified
|
||||
....
|
||||
----
|
||||
|
||||
As noted above, Jetty supports a wide array of logging technologies.
|
||||
If a particular logging framework requires additional jar files, Jetty will automatically download these as part of enabling the associated module and any dependent modules will be transitively enabled.
|
||||
|
@ -83,8 +83,8 @@ Jetty uses the SLF4J api as a binding to provide logging information to addition
|
|||
It can also be used on it's own to provide simple server logging.
|
||||
To enable the SLF4J framework, you need to activate the `logging-slf4j` module.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
[my-base]$ java -jar ../start.jar --add-to-start=logging-slf4j
|
||||
|
||||
ALERT: There are enabled module(s) with licenses.
|
||||
|
@ -126,14 +126,14 @@ ERROR : Unsatisfied module dependencies: logging-slf4j
|
|||
|
||||
Usage: java -jar $JETTY_HOME/start.jar [options] [properties] [configs]
|
||||
java -jar $JETTY_HOME/start.jar --help # for more information
|
||||
....
|
||||
----
|
||||
|
||||
As you probably noticed, the system gives an `ERROR` when trying to enable the `logging-slf4j` on it's own.
|
||||
The `logging-slf4j` module itself provides the SLF4J api, but as SLF4J is often used as a binding for other logging frameworks does not by default provide an implementation.
|
||||
To enable the simple SLF4J implementation, we will also need to activate the `slf4j-simple-impl` module.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
[my-base]$ java -jar ../start.jar --add-to-start=slf4j-simple-impl
|
||||
INFO : slf4j-simple-impl initialized in ${jetty.base}/start.d/slf4j-simple-impl.ini
|
||||
INFO : resources transitively enabled
|
||||
|
@ -153,7 +153,7 @@ INFO : Base directory was modified
|
|||
└── start.d
|
||||
├── logging-slf4j.ini
|
||||
└── slf4j-simple-impl.ini
|
||||
....
|
||||
----
|
||||
|
||||
Jetty is now configured to log using the SLF4J framework.
|
||||
A standard SLF4J properties file is located in `${jetty.base}/resources/simplelogger.properties`.
|
||||
|
@ -165,8 +165,8 @@ It is possible to have the Jetty Server logging configured so that Log4j or Log4
|
|||
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].
|
||||
Implementation of Log4j can be done by enabling the `logging-log4j` module.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
[my-base]$ java -jar ../start.jar --add-to-start=logging-log4j
|
||||
|
||||
ALERT: There are enabled module(s) with licenses.
|
||||
|
@ -227,15 +227,15 @@ INFO : Base directory was modified
|
|||
│ └── log4j.xml
|
||||
└── start.d
|
||||
└── logging-log4j.ini
|
||||
....
|
||||
----
|
||||
|
||||
Jetty is now configured to log using the Log4j framework.
|
||||
A standard Log4j configuration file is located in `${jetty.base}/resources/log4j.xml`.
|
||||
|
||||
Or, to set up Log4j2, enable the `logging-log4j2` module.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
[my-base]$ java -jar ../start.jar --add-to-start=logging-log4j2
|
||||
|
||||
ALERT: There are enabled module(s) with licenses.
|
||||
|
@ -299,7 +299,7 @@ INFO : Base directory was modified
|
|||
│ └── log4j2.xml
|
||||
└── start.d
|
||||
└── logging-log4j2.ini
|
||||
....
|
||||
----
|
||||
|
||||
At this point Jetty is configured so that the Jetty server itself will log using Log4j2, using the Log4j2 configuration found in `{$jetty.base}/resources/log4j2.xml`.
|
||||
|
||||
|
@ -311,8 +311,8 @@ This is accomplished by configuring Jetty for logging to `Logback`, which uses h
|
|||
|
||||
To set up Jetty logging via Logback, enable the `logging-logback` module.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
[my-base]$ java -jar ../start.jar --add-to-start=logging-logback
|
||||
|
||||
ALERT: There are enabled module(s) with licenses.
|
||||
|
@ -382,7 +382,7 @@ INFO : Base directory was modified
|
|||
│ └── logback.xml
|
||||
└── start.d
|
||||
└── logging-logback.ini
|
||||
....
|
||||
----
|
||||
|
||||
At this point Jetty is configured so that the Jetty server itself will log using Logback, using the Logback configuration found in `{$jetty.base}/resources/logback.xml`.
|
||||
|
||||
|
@ -394,8 +394,8 @@ It is possible to have the Jetty Server logging configured so that `java.util.lo
|
|||
|
||||
This example demonstrates how to configuring Jetty for logging to `java.util.logging` via http://slf4j.org/manual.html[SLF4J] as a binding layer.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
[my-base]$ java -jar ../start.jar --add-to-start=logging-jul
|
||||
|
||||
ALERT: There are enabled module(s) with licenses.
|
||||
|
@ -448,7 +448,7 @@ INFO : Base directory was modified
|
|||
│ └── slf4j-jdk14-1.7.21.jar
|
||||
└── start.d
|
||||
└── logging-jul.ini
|
||||
....
|
||||
----
|
||||
|
||||
Jetty is now configured to log using the JUL framework.
|
||||
A standard JUL properties file is located in `${jetty.base}/etc/java-util-logging.properties`.
|
||||
|
@ -459,8 +459,8 @@ By default, enabling the above modules will output log information to the consol
|
|||
Included in the distribution is the `console-capture` module, which can be used in lieu of additional configuration to the selected logging module to capture this output to a `logs` directory in your `${jetty.base}`.
|
||||
To enable this functionality, activate the `console-capture` module.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
[my-base]$ java -jar ../start.jar --add-to-start=console-capture
|
||||
INFO : console-capture initialized in ${jetty.base}/start.d/console-capture.ini
|
||||
MKDIR : ${jetty.base}/logs
|
||||
|
@ -471,24 +471,24 @@ INFO : Base directory was modified
|
|||
├── logs
|
||||
└── start.d
|
||||
└── console-capture.ini
|
||||
....
|
||||
----
|
||||
|
||||
As an example, here is the output from Logback before using the `console-capture` module:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
[my-base]$ java -jar ../start.jar
|
||||
419 [main] INFO org.eclipse.jetty.util.log - Logging initialized @508ms to org.eclipse.jetty.util.log.Slf4jLog
|
||||
540 [main] INFO org.eclipse.jetty.server.Server - jetty-9.4.0-SNAPSHOT
|
||||
575 [main] INFO o.e.jetty.server.AbstractConnector - Started ServerConnector@3c0ecd4b{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
|
||||
575 [main] INFO org.eclipse.jetty.server.Server - Started @668ms
|
||||
....
|
||||
----
|
||||
|
||||
After enabling `console-capture`, the output is as follows, which displays the location the log is being saved to:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
[my-base]$ java -jar ../start.jar
|
||||
151 [main] INFO org.eclipse.jetty.util.log - Logging initialized @238ms to org.eclipse.jetty.util.log.Slf4jLog
|
||||
196 [main] INFO org.eclipse.jetty.util.log - Console stderr/stdout captured to /installs/jetty-distribution/mybase/logs/2016_10_21.jetty.log
|
||||
....
|
||||
----
|
||||
|
|
|
@ -31,8 +31,8 @@ Included in the Jetty distribution is a logging module named `console-capture` t
|
|||
|
||||
To enable this feature, simply activate the `console-capture` module on the command line:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
[my-base]$ java -jar ../start.jar --add-to-start=console-capture
|
||||
INFO : console-capture initialized in ${jetty.base}/start.d/console-capture.ini
|
||||
MKDIR : ${jetty.base}/logs
|
||||
|
@ -43,23 +43,21 @@ INFO : Base directory was modified
|
|||
├── logs
|
||||
└── start.d
|
||||
└── console-capture.ini
|
||||
....
|
||||
----
|
||||
|
||||
The default configuration for logging output will create a file `${jetty.base}/logs/yyyy_mm_dd.stderrout.log` which allows configuration of the output directory by setting the `jetty.logs` property.
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
By default, logs are not set to be appended, meaning a the log file is wiped clean upon sever restart.
|
||||
You can change this setting by editing the `console-capture.ini` and un-commenting the line that reads `jetty.console-capture.append=true`.
|
||||
____
|
||||
|
||||
|
||||
====
|
||||
Just enabling the `console-capture` will simply output the values of STDERR and STDOUT to a log file.
|
||||
To customize the log further, a module named `logging-jetty` is available to provides a default properties file to configure.
|
||||
As with `console-capture`, you activate the `logging-jetty` on the command line.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
[my-base]$ java -jar ../start.jar --add-to-start=logging-jetty
|
||||
INFO : logging-jetty initialized in ${jetty.base}/start.d/logging-jetty.ini
|
||||
INFO : resources transitively enabled
|
||||
|
@ -75,14 +73,14 @@ INFO : Base directory was modified
|
|||
└── start.d
|
||||
├── console-capture.ini
|
||||
└── logging-jetty.ini
|
||||
....
|
||||
----
|
||||
|
||||
Once activated, you can find the properties file at `${jetty.base}/resources/jetty-logging.properties`.
|
||||
By default, the following parameters are defined.
|
||||
To change them, un-comment the line and substitute your naming scheme and configuration choices.
|
||||
|
||||
[source, properties, subs="{sub-order}"]
|
||||
....
|
||||
[source, properties]
|
||||
----
|
||||
## Force jetty logging implementation
|
||||
#org.eclipse.jetty.util.log.class=org.eclipse.jetty.util.log.StdErrLog
|
||||
|
||||
|
@ -95,7 +93,7 @@ To change them, un-comment the line and substitute your naming scheme and config
|
|||
|
||||
## Show the source file of a log location?
|
||||
#com.example.SOURCE=false
|
||||
....
|
||||
----
|
||||
|
||||
There are a number of properties that can be defined in the configuration that will affect the behavior of StdErr logging with `console-capture`.
|
||||
|
||||
|
@ -125,23 +123,23 @@ There are a number of properties that can be defined in the configuration that w
|
|||
+
|
||||
* Example when set to false:
|
||||
+
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
2016-10-21 15:31:01.248:INFO::main: Logging initialized @332ms to org.eclipse.jetty.util.log.StdErrLog
|
||||
2016-10-21 15:31:01.370:INFO:oejs.Server:main: jetty-9.4.0-SNAPSHOT
|
||||
2016-10-21 15:31:01.400:INFO:oejs.AbstractConnector:main: Started ServerConnector@2c330fbc{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
|
||||
2016-10-21 15:31:01.400:INFO:oejs.Server:main: Started @485ms
|
||||
....
|
||||
----
|
||||
+
|
||||
* Example when set to true:
|
||||
+
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
2016-10-21 15:31:35.020:INFO::main: Logging initialized @340ms to org.eclipse.jetty.util.log.StdErrLog
|
||||
2016-10-21 15:31:35.144:INFO:org.eclipse.jetty.server.Server:main: jetty-9.4.0-SNAPSHOT
|
||||
2016-10-21 15:31:35.174:INFO:org.eclipse.jetty.server.AbstractConnector:main: Started ServerConnector@edf4efb{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
|
||||
2016-10-21 15:31:35.175:INFO:org.eclipse.jetty.server.Server:main: Started @495ms
|
||||
....
|
||||
----
|
||||
|
||||
[[deprecated-parameters]]
|
||||
==== Deprecated Parameters
|
||||
|
|
|
@ -23,8 +23,8 @@ This is accomplished by configuring Jetty for logging to http://logging.apache.o
|
|||
|
||||
A convenient replacement `logging` module has been created to bootstrap your `${jetty.base}` directory for logging with log4j.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
[mybase]$ mkdir modules
|
||||
[mybase]$ cd modules
|
||||
|
||||
|
@ -46,7 +46,7 @@ INFO: resources initialised transitively
|
|||
INFO: resources enabled in ${jetty.base}/start.ini
|
||||
|
||||
[mybase]$ java -jar /opt/jetty-dist/start.jar
|
||||
....
|
||||
----
|
||||
|
||||
The replacement `logging.mod` performs a number of tasks.
|
||||
|
||||
|
|
|
@ -25,16 +25,15 @@ Jetty.
|
|||
This example demonstrates how to configuring Jetty for logging to
|
||||
`java.util.logging` via Jetty's own JavaUtilLog implementation.
|
||||
|
||||
____
|
||||
[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 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`.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
[mybase]$ mkdir modules
|
||||
[mybase]$ cd modules
|
||||
|
||||
|
@ -54,7 +53,7 @@ INFO: resources initialised transitively
|
|||
INFO: resources enabled in ${jetty.base}/${jetty.base}
|
||||
|
||||
[mybase]$ java -jar /opt/jetty-dist/start.jar
|
||||
....
|
||||
----
|
||||
|
||||
The replacement `logging.mod` performs a number of tasks.
|
||||
|
||||
|
@ -78,8 +77,8 @@ In essence, Jetty is now configured to use `org.eclipse.jetty.util.log.JavaUtilL
|
|||
|
||||
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.
|
||||
|
@ -88,4 +87,4 @@ Other logging frameworks are more reliable in that they always initialize and co
|
|||
|
||||
* 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].
|
||||
____
|
||||
====
|
||||
|
|
|
@ -25,8 +25,8 @@ If you want to use the built-in native `JavaUtilLog` implementation, see #exampl
|
|||
|
||||
A convenient replacement `logging` module has been created to bootstrap your `${jetty.base}` directory for logging with `java.util.logging`.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
[mybase]$ mkdir modules
|
||||
[mybase]$ cd modules
|
||||
|
||||
|
@ -48,7 +48,7 @@ INFO: resources initialised transitively
|
|||
INFO: resources enabled in ${jetty.base}/start.ini
|
||||
|
||||
[mybase]$ java -jar /opt/jetty-dist/start.jar
|
||||
....
|
||||
----
|
||||
|
||||
The replacement `logging.mod` performs a number of tasks.
|
||||
|
||||
|
@ -73,8 +73,8 @@ In essence, Jetty is now configured to emit its own logging events to slf4j, and
|
|||
|
||||
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.
|
||||
|
@ -83,4 +83,4 @@ Other logging frameworks are more reliable in that they always initialize and co
|
|||
|
||||
* 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].
|
||||
____
|
||||
====
|
||||
|
|
|
@ -24,12 +24,11 @@ It routes all logging events from the web applications to a single configuration
|
|||
|
||||
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.
|
||||
|
||||
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
|
||||
|
@ -38,8 +37,8 @@ See https://github.com/jetty-project/jetty-webapp-logging/blob/master/jetty-weba
|
|||
|
||||
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,subs="{sub-order}"]
|
||||
....
|
||||
[source,screen,]
|
||||
----
|
||||
[mybase]$ curl -O https://repo1.maven.org/maven2/org/eclipse/jetty/jetty-webapp-logging/9.4.27/jetty-webapp-logging-9.4.27-config.jar
|
||||
% Total % Received % Xferd Average Speed Time Time Time Current
|
||||
Dload Upload Total Spent Left Speed
|
||||
|
@ -114,7 +113,7 @@ DOWNLD: https://repo1.maven.org/maven2/org/eclipse/jetty/jetty-webapp-logging/9.
|
|||
INFO : Base directory was modified
|
||||
|
||||
$
|
||||
....
|
||||
----
|
||||
|
||||
This replacement `centralized-webapp-logging.mod` performs a number of tasks.
|
||||
|
||||
|
|
|
@ -23,9 +23,9 @@ This page describes how to create log files at the server level and name them ba
|
|||
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
|
||||
....
|
||||
----
|
||||
|
||||
.GitHub Example Project
|
||||
[cols=",",options="header",]
|
||||
|
|
|
@ -23,8 +23,8 @@ This is accomplished by configuring Jetty for logging to `Logback`, which uses h
|
|||
|
||||
A convenient replacement `logging` module has been created to bootstrap the `${jetty.base}` directory for logging with logback.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
[mybase]$ mkdir modules
|
||||
[mybase]$ cd modules
|
||||
|
||||
|
@ -44,7 +44,7 @@ DOWNLOAD: https://raw.githubusercontent.com/jetty-project/logging-modules/master
|
|||
DOWNLOAD: https://raw.githubusercontent.com/jetty-project/logging-modules/master/logback/jetty-logging.properties to resources/jetty-logging.properties
|
||||
|
||||
[mybase]$ java -jar /opt/jetty-dist/start.jar
|
||||
....
|
||||
----
|
||||
|
||||
The replacement `logging.mod` performs a number of tasks.
|
||||
|
||||
|
|
|
@ -34,19 +34,17 @@ Logging APIs that Slf4j supports:
|
|||
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",]
|
||||
|=======================================================================
|
||||
|
@ -88,8 +86,8 @@ It also requires including the other Slf4j binding JARs in the classpath, along
|
|||
|
||||
A convenient replacement `logging` module has been created to bootstrap the `${jetty.base}` directory for capturing all Jetty server logging from multiple logging frameworks into a single logging output file managed by logback.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
[mybase]$ mkdir modules
|
||||
[mybase]$ cd modules
|
||||
|
||||
|
@ -115,7 +113,7 @@ INFO: resources initialised transitively
|
|||
INFO: resources enabled in ${jetty.base}/start.ini
|
||||
|
||||
[mybase]$ java -jar /opt/jetty-dist/start.jar
|
||||
....
|
||||
----
|
||||
|
||||
The replacement `logging.mod` performs a number of tasks.
|
||||
|
||||
|
|
|
@ -79,7 +79,7 @@ The Server MBean has a `dump()` method, which dumps everything, plus a `dumpStdE
|
|||
|
||||
This is a dump of the OneServletContext embedded example with extra threadpool information:
|
||||
|
||||
....
|
||||
----
|
||||
Server@59906517{STARTED}[9.4.32-SNAPSHOT] - STARTED
|
||||
+= QueuedThreadPool[qtp488044861]@1d16f93d{STARTED,8<=8<=200,i=2,r=4,q=0}[ReservedThreadExecutor@16267862{s=2/4,p=0}] - STARTED
|
||||
| += ReservedThreadExecutor@16267862{s=2/4,p=0} - STARTED
|
||||
|
@ -221,4 +221,4 @@ Server@59906517{STARTED}[9.4.32-SNAPSHOT] - STARTED
|
|||
+> jdk.internal.loader.ClassLoaders$AppClassLoader@2c13da15
|
||||
+> jdk.internal.loader.ClassLoaders$PlatformClassLoader@7364985f
|
||||
key: +- bean, += managed, +~ unmanaged, +? auto, +: iterable, +] array, +@ map, +> undefined
|
||||
....
|
||||
----
|
||||
|
|
|
@ -18,7 +18,7 @@
|
|||
|
||||
[[jetty-admin-guide]]
|
||||
|
||||
= Jetty Administration Guide
|
||||
== Jetty Administration Guide
|
||||
|
||||
include::startup/chapter.adoc[]
|
||||
include::sessions/chapter.adoc[]
|
||||
|
|
|
@ -34,33 +34,32 @@ 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 performing the following:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
> java -jar jetty-runner.jar simple.war
|
||||
....
|
||||
----
|
||||
|
||||
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, subs="{sub-order}"]
|
||||
....
|
||||
[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, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
> java -jar jetty-runner.jar simple-context.xml
|
||||
....
|
||||
----
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
When using a context xml file, the application being deployed is not even required to be a fully-fledged webapp.
|
||||
It can simply be a Jetty link:#what-is-a-context[context].
|
||||
____
|
||||
|
||||
====
|
||||
By default, `jetty-runner` implements all Configuration Classes so that users can set up and deploy new instances with as little configuration as possible.
|
||||
If you wish to only implement certain Configuration Classes, they will need to be defined in the context xml for the webapp/context.
|
||||
The default Configuration Classes are:
|
||||
|
@ -82,60 +81,58 @@ 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, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
> java -jar jetty-runner.jar --path /one my1.war --path /two my2.war
|
||||
....
|
||||
----
|
||||
|
||||
If you have context xml files that describe your webapps, you can fully configure your webapps in them and hence you won't need to use the command line switches.
|
||||
Just provide the list of context files like so:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
> java -jar jetty-runner.jar my-first-context.xml my-second-context.xml my-third-context.xml
|
||||
....
|
||||
----
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
Switched used on the command line override configuration file settings.
|
||||
So, for example, you could set the context path for the webapp inside the context xml file, and use the `--path` switch to override it on the command line.
|
||||
____
|
||||
|
||||
|
||||
====
|
||||
===== Changing the Default Port
|
||||
|
||||
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, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
> java -jar jetty-runner.jar --port 9090 simple.war
|
||||
....
|
||||
----
|
||||
|
||||
===== Using jetty.xml Files
|
||||
|
||||
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, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
> java -jar jetty-runner.jar --config jetty.xml --config jetty-https.xml simple.war
|
||||
....
|
||||
----
|
||||
|
||||
[[runner-configuration-reference]]
|
||||
==== Full Configuration Reference
|
||||
|
||||
You can see the fill set of configuration options using the `--help` switch:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
> java -jar jetty-runner.jar --help
|
||||
....
|
||||
----
|
||||
|
||||
Here's what the output will look like:
|
||||
|
||||
[source, plain, subs="{sub-order}"]
|
||||
[source, plain]
|
||||
----
|
||||
|
||||
Usage: java [-Djetty.home=dir] -jar jetty-runner.jar [--help|--version] [ server opts] [[ context opts] context ...]
|
||||
|
@ -159,66 +156,66 @@ Context opts:
|
|||
===== Printing the Version
|
||||
Print out the version of Jetty and then exit immediately.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
> java -jar jetty-runner.jar --version
|
||||
....
|
||||
----
|
||||
|
||||
===== Configuring a Request Log
|
||||
Cause Jetty to write a request log with the given name.
|
||||
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, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
> java -jar jetty-runner.jar --log yyyy_mm_dd-requests.log my.war
|
||||
....
|
||||
----
|
||||
|
||||
===== 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, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
> java -jar jetty-runner.jar --out yyyy_mm_dd-output.log my.war
|
||||
....
|
||||
----
|
||||
|
||||
===== 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, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
> java -jar jetty-runner.jar --host 192.168.22.19 my.war
|
||||
....
|
||||
----
|
||||
|
||||
===== 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, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
> java -jar jetty-runner.jar --port 9090 my.war
|
||||
....
|
||||
----
|
||||
|
||||
===== Configuring Stop
|
||||
You can configure a port number for Jetty to listen on for a stop command, so you are able to stop it from a different terminal.
|
||||
This requires the use of a "secret" key, to prevent malicious or accidental termination.
|
||||
Use the `--stop-port` and `--stop-key` (or `-DSTOP.PORT=` and `-DSTOP.KEY=`, respectively) parameters as arguments to the `jetty-runner`:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
> java -jar jetty-runner.jar --stop-port 8181 --stop-key abc123
|
||||
....
|
||||
----
|
||||
|
||||
Then, to stop Jetty from a different terminal, you need to supply the same port and key information.
|
||||
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 a custom class.
|
||||
Here's how to use a Jetty installation to perform a stop:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
> java -jar start.jar -DSTOP.PORT=8181 -DSTOP.KEY=abc123 --stop
|
||||
....
|
||||
----
|
||||
|
||||
===== Configuring the Container Classpath
|
||||
With a local installation of Jetty, you add jars and classes to the container's classpath by putting them in the `{$jetty.base}/lib` directory.
|
||||
|
@ -228,52 +225,50 @@ With the `jetty-runner`, you can use the `--lib`, `--jar` and `--classes` argume
|
|||
You can add 1 or more.
|
||||
Here's an example of configuring 2 directories:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
> java -jar jetty-runner.jar --lib /usr/local/external/lib --lib $HOME/external-other/lib my.war
|
||||
....
|
||||
----
|
||||
|
||||
`--jar` adds a single jar file to the container classpath.
|
||||
You can add 1 or more.
|
||||
Here's an example of configuring 3 extra jars:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[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
|
||||
....
|
||||
----
|
||||
|
||||
`--classes` add the location of a directory containing classes to add to the container classpath.
|
||||
You can add 1 or more.
|
||||
Here's an example of configuring a single extra classes dir:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
> java -jar jetty-runner.jar --classes /opt/stuff/classes my.war
|
||||
....
|
||||
----
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
When using the `--jar` and/or `--lib` arguments, by default these will *not* be inspected for `META-INF` information such as `META-INF/resources`, `META-INF/web-fragment.xml`, or `META-INF/taglib.tld`.
|
||||
If you require these jar files inspected you will need to define the link:https://www.eclipse.org/jetty/documentation/current/configuring-webapps.html#webapp-context-attributes[jar pattern in your context xml file].
|
||||
Jetty-Runner automatically provides and appends a suitable pattern for jtsl taglibs (this pattern is different than the one in the standard Jetty distribution).
|
||||
____
|
||||
|
||||
|
||||
====
|
||||
===== Gathering Statistics
|
||||
If statistics gathering is enabled, then they are viewable by surfing to the context `/stats`.
|
||||
You may optionally protect access to that context with a password.
|
||||
Here's an example of enabling statistics, with no password protection:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
> java -jar jetty-runner.jar --stats unsecure my.war
|
||||
....
|
||||
----
|
||||
|
||||
If we wished to protect access to the `/stats` context, we would provide the location of a Jetty realm configuration file containing authentication and authorization information.
|
||||
For example, we could use the following example realm file from the Jetty distribution:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
jetty: MD5:164c88b302622e17050af52c89945d44,user
|
||||
admin: CRYPT:adpexzg3FUZAk,server-administrator,content-administrator,admin
|
||||
other: OBF:1xmk1w261u9r1w1c1xmq,user
|
||||
|
@ -281,18 +276,18 @@ plain: plain,user
|
|||
user: password,user
|
||||
# This entry is for digest auth. The credential is a MD5 hash of username:realmname:password
|
||||
digest: MD5:6e120743ad67abfbc385bc2bb754e297,user
|
||||
....
|
||||
----
|
||||
|
||||
Assuming we've copied it into the local directory, we would apply it like so
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
....
|
||||
[source, screen]
|
||||
----
|
||||
> java -jar jetty-runner.jar --stats realm.properties my.war
|
||||
....
|
||||
----
|
||||
|
||||
After navigating to http://localhost:8080/ a few times, we can point to the stats servlet on http://localhost:8080/stats to see the output:
|
||||
|
||||
....
|
||||
----
|
||||
Statistics:
|
||||
Statistics gathering started 1490627ms ago
|
||||
|
||||
|
@ -346,4 +341,4 @@ Total messages out: 7
|
|||
Memory:
|
||||
Heap memory usage: 49194840 bytes
|
||||
Non-heap memory usage: 12611696 bytes
|
||||
....
|
||||
----
|
||||
|
|
|
@ -50,7 +50,7 @@ To do that, you can use `--skip-file-validation=glcoud-sessions` argument to sta
|
|||
The gcloud-sessions module will have installed file called `${jetty.home}/etc/jetty-gcloud-sessions.xml`.
|
||||
This file configures an instance of the `GCloudSessionIdManager` that will be shared across all webapps deployed on that server. It looks like this:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
include::{SRCDIR}/jetty-gcloud/jetty-gcloud-session-manager/src/main/config/etc/jetty-gcloud-sessions.xml[]
|
||||
----
|
||||
|
@ -105,7 +105,7 @@ The basic difference is how you get a reference to the Jetty `org.eclipse.jetty.
|
|||
|
||||
From a context xml file, you reference the Server instance as a Ref:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<!-- Get a reference to the GCloudSessionIdManager -->
|
||||
<Ref id="Server">
|
||||
|
@ -129,7 +129,7 @@ From a context xml file, you reference the Server instance as a Ref:
|
|||
|
||||
From a `WEB-INF/jetty-web.xml` file, you can reference the Server instance directly:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<!-- Reference the server directly -->
|
||||
<Get name="server">
|
||||
|
@ -202,7 +202,7 @@ The basic difference is how you get a reference to the Jetty `org.eclipse.jetty.
|
|||
|
||||
From a context xml file, you reference the Server instance as a Ref:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<!-- Get a reference to the GCloudSessionIdManager -->
|
||||
<Ref id="Server">
|
||||
|
@ -229,7 +229,7 @@ From a context xml file, you reference the Server instance as a Ref:
|
|||
|
||||
From a `WEB-INF/jetty-web.xml` file, you can reference the Server instance directly:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<!-- Reference the server directly -->
|
||||
<Get name="server">
|
||||
|
|
|
@ -47,10 +47,10 @@ To do that, you can use `--skip-file-validation=infinispan` argument to start.ja
|
|||
|
||||
You will also find the following properties, either in your base's `start.d/infinispan.ini` file or appended to your `start.ini`, depending on how you enabled the module:
|
||||
|
||||
....
|
||||
----
|
||||
## Unique identifier for this node in the cluster
|
||||
jetty.infinispanSession.workerName=node1
|
||||
....
|
||||
----
|
||||
|
||||
jetty.infinispanSession.workerName::
|
||||
The name that uniquely identifies this node in the cluster.
|
||||
|
@ -65,7 +65,7 @@ The Infinispan module will have installed file called `$\{jetty.home}/etc/jetty-
|
|||
This file configures an instance of the `InfinispanSessionIdManager` that will be shared across all webapps deployed on that server.
|
||||
It looks like this:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
include::{SRCDIR}/jetty-infinispan/src/main/config/etc/jetty-infinispan.xml[]
|
||||
----
|
||||
|
@ -91,7 +91,7 @@ The basic difference is how you get a reference to the Jetty `org.eclipse.jetty.
|
|||
|
||||
From a context xml file, you reference the Server instance as a Ref:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<!-- Expose the jetty infinispan classes for session serialization -->
|
||||
<Get name="serverClasspathPattern">
|
||||
|
@ -132,7 +132,7 @@ From a context xml file, you reference the Server instance as a Ref:
|
|||
|
||||
From a `WEB-INF/jetty-web.xml` file, you can reference the Server instance directly:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<!-- Expose the jetty infinispan classes for session serialization -->
|
||||
<Get name="serverClasspathPattern">
|
||||
|
@ -187,6 +187,6 @@ To do this, firstly ensure that you have included the lines containing the `getS
|
|||
Then, create the file `${jetty.base}/resources/hotrod-client.properties`.
|
||||
Add the following line to this file:
|
||||
|
||||
....
|
||||
----
|
||||
infinispan.client.hotrod.marshaller=org.eclipse.jetty.session.infinispan.WebAppMarshaller
|
||||
....
|
||||
----
|
||||
|
|
|
@ -46,7 +46,7 @@ When using the jetty distribution, to enable jdbc session persistence, you will
|
|||
|
||||
You will also find the following properties, either in your base's start.d/jdbc-session.ini file or appended to your start.ini, depending on how you enabled the module:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
## Unique identifier for this node in the cluster
|
||||
jetty.jdbcSession.workerName=node1
|
||||
|
@ -80,7 +80,7 @@ The jdbc-session module will have installed file called `$\{jetty.home}/etc/jett
|
|||
This file configures an instance of the `JDBCSessionIdManager` that will be shared across all webapps deployed on that server.
|
||||
It looks like this:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
include::{SRCDIR}/jetty-server/src/main/config/etc/jetty-jdbc-sessions.xml[]
|
||||
----
|
||||
|
@ -89,7 +89,7 @@ As well as uncommenting and setting up appropriate values for the properties dis
|
|||
|
||||
As Jetty configuration files are direct mappings of XML to Java, it is straight forward to do this in code:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
Server server = new Server();
|
||||
...
|
||||
|
@ -129,7 +129,7 @@ These classes have getter/setter methods for the table name and all columns.
|
|||
Here's an example of changing the name of `JettySessionsId` table and its single column.
|
||||
This example will use java code, but as explained above, you may also do this via a Jetty xml configuration file:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
JDBCSessionIdManager idManager = new JDBCSessionIdManager(server);
|
||||
|
||||
|
@ -142,7 +142,7 @@ idManager.setSessionIdTableSchema(idTableSchema);
|
|||
In a similar fashion, you can change the names of the table and columns for the `JettySessions` table.
|
||||
*Note* that both the `SessionIdTableSchema` and the `SessionTableSchema` instances are set on the `JDBCSessionIdManager` class.
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
JDBCSessionIdManager idManager = new JDBCSessionIdManager(server);
|
||||
|
||||
|
@ -172,7 +172,7 @@ The basic difference is how you get a reference to the Jetty `org.eclipse.jetty.
|
|||
|
||||
From a context xml file, you reference the Server instance as a Ref:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<Ref id="Server">
|
||||
<Call id="idMgr" name="getSessionIdManager"/>
|
||||
|
@ -192,7 +192,7 @@ From a context xml file, you reference the Server instance as a Ref:
|
|||
|
||||
From a `WEB-INF/jetty-web.xml` file, you can reference the Server instance directly:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
|
||||
<Get name="server">
|
||||
|
@ -213,7 +213,7 @@ From a `WEB-INF/jetty-web.xml` file, you can reference the Server instance direc
|
|||
|
||||
If you're embedding this in code:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
|
||||
//assuming you have already set up the JDBCSessionIdManager as shown earlier
|
||||
|
|
|
@ -53,7 +53,7 @@ To do that, you can use `--skip-file-validation=nosql` argument to start.jar on
|
|||
|
||||
You will also find the following properties, either in your base's `start.d/nosql.ini` file or appended to your `start.ini`, depending on how you enabled the module:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
## Unique identifier for this node in the cluster
|
||||
jetty.nosqlSession.workerName=node1
|
||||
|
@ -77,7 +77,7 @@ The nosql module will have installed file called `$\{jetty.home}/etc/jetty-nosql
|
|||
This file configures an instance of the `MongoSessionIdManager` that will be shared across all webapps deployed on that server.
|
||||
It looks like this:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
include::{SRCDIR}/jetty-nosql/src/main/config/etc/jetty-nosql.xml[]
|
||||
----
|
||||
|
@ -86,7 +86,7 @@ The `MongoSessionIdManager` needs access to a MongoDB cluster, and the `jetty-no
|
|||
If you need to configure something else, you will need to edit this file.
|
||||
Here's an example of a more complex setup to use a remote MongoDB instance:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<New id="mongodb" class="com.mongodb.Mongo">
|
||||
<Arg>
|
||||
|
@ -130,7 +130,7 @@ Here's an example of a more complex setup to use a remote MongoDB instance:
|
|||
|
||||
As Jetty configuration files are direct mappings of XML to Java, it is straight forward to do this in code:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
|
||||
Server server = new Server();
|
||||
|
@ -186,7 +186,7 @@ The basic difference is how you get a reference to the Jetty `org.eclipse.jetty.
|
|||
|
||||
From a context xml file, you reference the Server instance as a Ref:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<Ref name="Server" id="Server">
|
||||
<Call id="mongoIdMgr" name="getSessionIdManager"/>
|
||||
|
@ -207,7 +207,7 @@ From a context xml file, you reference the Server instance as a Ref:
|
|||
|
||||
From a `WEB-INF/jetty-web.xml` file, you can reference the Server instance directly:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<Get name="server">
|
||||
<Get id="mongoIdMgr" name="sessionIdManager"/>
|
||||
|
@ -227,7 +227,7 @@ From a `WEB-INF/jetty-web.xml` file, you can reference the Server instance direc
|
|||
|
||||
If you're embedding this in code:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
//assuming you have already set up the MongoSessionIdManager as shown earlier
|
||||
//and have a reference to the Server instance:
|
||||
|
|
|
@ -74,7 +74,7 @@ The following sections provide examples of how to apply the init parameters.
|
|||
|
||||
You can set these parameters as context parameters in a web application's `WEB-INF/web.xml` file:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
|
@ -103,7 +103,7 @@ You can set these parameters as context parameters in a web application's `WEB-I
|
|||
|
||||
You can configure init parameters on a web application, either in code, or in a Jetty context xml file equivalent:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
|
||||
<Configure class="org.eclipse.jetty.webapp.WebAppContext">
|
||||
|
@ -130,7 +130,7 @@ You can configure init parameters on a web application, either in code, or in a
|
|||
|
||||
You can configure init parameters directly on a `SessionManager` instance, either in code or the equivalent in xml:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
|
||||
<Configure class="org.eclipse.jetty.webapp.WebAppContext">
|
||||
|
@ -165,7 +165,7 @@ For full details, consult the http://docs.oracle.com/javaee/6/api/javax/servlet/
|
|||
|
||||
Below is an example of this implementation: a `ServletContextListener` retrieves the `SessionCookieConfig` and sets up some new values when the context is being initialized:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
import javax.servlet.SessionCookieConfig;
|
||||
import javax.servlet.ServletContextEvent;
|
||||
|
@ -205,7 +205,7 @@ public class TestListener implements ServletContextListener
|
|||
|
||||
You can also use `web.xml` to configure the session handling characteristics instead: here's an example doing exactly the same as above instead of using code:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<web-app
|
||||
|
@ -236,7 +236,7 @@ In addition to the configuration of link:#session-cookie-configuration[session c
|
|||
|
||||
To determine what are the _default_ session tracking characteristics used by the container, call:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
javax.servlet.SessionContext.getDefaultSessionTrackingModes();
|
||||
----
|
||||
|
@ -249,21 +249,21 @@ _default_ session tracking modes for Jetty are:
|
|||
|
||||
To see which session tracking modes are actually in effect for this Context, the following call returns a `java.util.Set` of `javax.servlet.SessionTrackingMode`:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
javax.servlet.SessionContext.getEffectiveSessionTrackingModes();
|
||||
----
|
||||
|
||||
To change the session tracking modes, call:
|
||||
|
||||
[source, java, subs="{sub-order}"]
|
||||
[source, java]
|
||||
----
|
||||
javax.servlet.SessionContext.setSessionTrackingModes(Set<SessionTrackingMode>);
|
||||
----
|
||||
|
||||
You may also set the tracking mode in `web.xml`, e.g.:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<web-app
|
||||
|
|
|
@ -31,7 +31,7 @@ A `SessionManager` does just what its name suggests – it manages the lifecycle
|
|||
Each webapp must have its own unique `SessionManager` instance.
|
||||
Enabling persistence is as simple as configuring the `HashSessionManager` as the `SessionManager` for a webapp and telling it where on disk to store the sessions:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
|
||||
<Configure class="org.eclipse.jetty.webapp.WebAppContext">
|
||||
|
@ -75,7 +75,7 @@ For example, the Wicket web framework requires the servlet environment to be ava
|
|||
Using `SessionManager.setLazyLoad(true)`, Jetty loads sessions lazily either when it receives the first request for a session, or the session scavenger runs for the first time, whichever happens first.
|
||||
Here's how the configuration looks in XML:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<Set name="sessionHandler">
|
||||
<New class="org.eclipse.jetty.server.session.SessionHandler">
|
||||
|
@ -93,7 +93,7 @@ Here's how the configuration looks in XML:
|
|||
|
||||
To enable session persistence for the Jetty Maven plugin, set up the `HashSessionManager` in the configuration section like so:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<plugin>
|
||||
<groupId>org.eclipse.jetty</groupId>
|
||||
|
|
|
@ -26,7 +26,7 @@ Note: Persisting sessions to the local file system should *not* be used in a clu
|
|||
|
||||
When using the Jetty distribution, you will first need to enable the `session-store-file` link:#startup-modules[module] for your link:#startup-base-and-home[Jetty base] using the `--add-to-start` argument on the command line.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
$ java -jar ../start.jar --create-startd
|
||||
INFO : Base directory was modified
|
||||
|
@ -48,17 +48,16 @@ By default Session files will be saved to this directory.
|
|||
|
||||
In addition to adding these modules to the classpath of the server, several ini configuration files were added to the `${jetty.base}/start.d` directory.
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
Session data is now only loaded when requested.
|
||||
Previous functionality such as `setLazyLoad` has been removed.
|
||||
____
|
||||
|
||||
====
|
||||
==== Configuring File System Session Properties
|
||||
|
||||
Opening `start.d/session-store-file.ini` will show a list of all the configurable options for the file system session module:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
# ---------------------------------------
|
||||
# Module: session-store-file
|
||||
|
@ -80,10 +79,10 @@ jetty.session.savePeriod.seconds=0::
|
|||
By default whenever the last concurrent request leaves a session, that session is always persisted via the `SessionDataStore`, even if the only thing that changed on the session is its updated last access time.
|
||||
A non-zero value means that the `SessionDataStore` will skip persisting the session if only the access time changed, and it has been less than `savePeriod` seconds since the last time the session was written.
|
||||
+
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
Configuring `savePeriod` is useful if your persistence technology is very slow/costly for writes.
|
||||
In a clustered environment, there is a risk of the last access time of the session being out-of-date in the shared store for up to `savePeriod` seconds.
|
||||
This allows the possibility that a node may prematurely expire the session, even though it is in use by another node.
|
||||
Thorough consideration of the `maxIdleTime` of the session when setting the `savePeriod` is imperative - there is no point in setting a `savePeriod` that is larger than the `maxIdleTime`.
|
||||
____
|
||||
====
|
||||
|
|
|
@ -66,7 +66,7 @@ To enable communication using the GCloud Emulator:
|
|||
When using the Jetty distribution, you will first need to enable the `session-store-gcloud` link:#startup-modules[module] for your link:#startup-base-and-home[Jetty base] using the `--add-to-start` argument on the command line.
|
||||
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
$ java -jar ../start.jar --create-startd
|
||||
INFO : Base directory was modified
|
||||
|
@ -191,7 +191,7 @@ It does *not*, however, configure a SLF4J implementation for the users.
|
|||
As such, you will also need to enable one of the SLF4J implementation modules listed.
|
||||
In this example, we will enable the `slf4j-simple-impl` module to provide a SLF4J implementation.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
$ java -jar ../start.jar --add-to-start=slf4j-simple-impl
|
||||
INFO : slf4j-simple-impl initialized in ${jetty.base}/start.d/slf4j-simple-impl.ini
|
||||
|
@ -206,16 +206,15 @@ When the `--add-to-start` argument was added to the command line the first time,
|
|||
|
||||
In addition to adding these modules to the classpath of the server it also added the respective configuration files to the `${jetty.base}start.d` directory.
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
If you have updated versions of the jar files automatically downloaded by Jetty, you can place them in the associated `${jetty.base}/lib/` directory and use the `--skip-file-validation=<module name>` command line option to prevent errors when starting your server.
|
||||
____
|
||||
|
||||
====
|
||||
==== Configuring GCloud Session Properties
|
||||
|
||||
Opening the `start.d/session-store-gcloud.ini` will display a list of all the configurable properties for the Google Cloud DataStore module:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
# ---------------------------------------
|
||||
# Module: session-store-gcloud
|
||||
|
@ -250,14 +249,13 @@ jetty.session.savePeriod.seconds=0::
|
|||
By default whenever the last concurrent request leaves a session, that session is always persisted via the `SessionDataStore`, even if the only thing that changed on the session is its updated last access time.
|
||||
A non-zero value means that the `SessionDataStore` will skip persisting the session if only the access time changed, and it has been less than `savePeriod` seconds since the last time the session was written.
|
||||
+
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
Configuring `savePeriod` is useful if your persistence technology is very slow/costly for writes.
|
||||
In a clustered environment, there is a risk of the last access time of the session being out-of-date in the shared store for up to `savePeriod` seconds.
|
||||
This allows the possibility that a node may prematurely expire the session, even though it is in use by another node.
|
||||
Thorough consideration of the `maxIdleTime` of the session when setting the `savePeriod` is imperative - there is no point in setting a `savePeriod` that is larger than the `maxIdleTime`.
|
||||
____
|
||||
|
||||
====
|
||||
jetty.session.gcloud.maxRetries::
|
||||
Maxmium number of tries to connect to GCloud DataStore to write sessions.
|
||||
jetty.session.gcloud.backoffMs::
|
||||
|
|
|
@ -24,7 +24,7 @@
|
|||
|
||||
When using the Jetty distribution, you will first need to enable the `session-store-hazelcast-remote` link:#startup-modules[module] for your link:#startup-base-and-home[Jetty base] using the `--add-to-start` argument on the command line.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
$ java -jar ../start.jar --create-startd
|
||||
MKDIR : ${jetty.base}/start.d
|
||||
|
@ -64,16 +64,15 @@ It also downloaded the needed Hazelcast-specific jar files and created a directo
|
|||
|
||||
In addition to adding these modules to the classpath of the server it also added several ini configuration files to the `${jetty.base}/start.d` directory.
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
If you have updated versions of the jar files automatically downloaded by Jetty, you can place them in the associated `${jetty.base}/lib/` directory and use the `--skip-file-validation=<module name>` command line option to prevent errors when starting your server.
|
||||
____
|
||||
|
||||
====
|
||||
==== Configuring Hazelcast Remote Properties
|
||||
|
||||
Opening the `start.d/session-store-hazelcast-remote.ini` will show a list of all the configurable options for the Hazelcast module:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
# ---------------------------------------
|
||||
# Module: session-store-hazelcast-remote
|
||||
|
@ -103,22 +102,21 @@ jetty.session.savePeriod.seconds=0::
|
|||
By default whenever the last concurrent request leaves a session, that session is always persisted via the `SessionDataStore`, even if the only thing that changed on the session is its updated last access time.
|
||||
A non-zero value means that the `SessionDataStore` will skip persisting the session if only the access time changed, and it has been less than `savePeriod` seconds since the last time the session was written.
|
||||
+
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
Configuring `savePeriod` is useful if your persistence technology is very slow/costly for writes.
|
||||
In a clustered environment, there is a risk of the last access time of the session being out-of-date in the shared store for up to `savePeriod` seconds.
|
||||
This allows the possibility that a node may prematurely expire the session, even though it is in use by another node.
|
||||
Thorough consideration of the `maxIdleTime` of the session when setting the `savePeriod` is imperative - there is no point in setting a `savePeriod` that is larger than the `maxIdleTime`.
|
||||
|
||||
Be aware using the `scavengeZombies` option that if your session attributes contain classes from inside your webapp (or jetty classes) then you will need to put these classes onto the classpath of all of your hazelcast instances.
|
||||
____
|
||||
|
||||
====
|
||||
==== Configuring Embedded Hazelcast Clustering
|
||||
|
||||
During testing, it can be helpful to run an in-process instance of Hazelcast.
|
||||
To enable this you will first need to enable the `session-store-hazelcast-embedded` link:#startup-modules[module] for your link:#startup-base-and-home[Jetty base] using the `--add-to-start` argument on the command line.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
$ java -jar ../start.jar --create-startd
|
||||
MKDIR : ${jetty.base}/start.d
|
||||
|
@ -160,7 +158,7 @@ In addition to adding these modules to the classpath of the server it also added
|
|||
|
||||
Opening the `start.d/start.d/session-store-hazelcast-embedded.ini` will show a list of all the configurable options for the Hazelcast module:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
# ---------------------------------------
|
||||
# Module: session-store-hazelcast-embedded
|
||||
|
@ -186,12 +184,12 @@ jetty.session.savePeriod.seconds=0::
|
|||
By default whenever the last concurrent request leaves a session, that session is always persisted via the `SessionDataStore`, even if the only thing that changed on the session is its updated last access time.
|
||||
A non-zero value means that the `SessionDataStore` will skip persisting the session if only the access time changed, and it has been less than `savePeriod` seconds since the last time the session was written.
|
||||
+
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
Configuring `savePeriod` is useful if your persistence technology is very slow/costly for writes.
|
||||
In a clustered environment, there is a risk of the last access time of the session being out-of-date in the shared store for up to `savePeriod` seconds.
|
||||
This allows the possibility that a node may prematurely expire the session, even though it is in use by another node.
|
||||
Thorough consideration of the `maxIdleTime` of the session when setting the `savePeriod` is imperative - there is no point in setting a `savePeriod` that is larger than the `maxIdleTime`.
|
||||
|
||||
Be aware using the `scavengeZombies` option that if your session attributes contain classes from inside your webapp (or jetty classes) then you will need to put these classes onto the classpath of all of your hazelcast instances. In the cast of embedded hazelcast, as it is started before your webapp, it will NOT have access to your webapp's classes - you will need to extract these classes and put them onto the jetty server's classpath.
|
||||
____
|
||||
====
|
||||
|
|
|
@ -25,7 +25,7 @@
|
|||
When using the Jetty distribution, you will first need to enable the `session-store-infinispan-remote` link:#startup-modules[module] for your link:#startup-base-and-home[Jetty base] using the `--add-to-start` argument on the command line.
|
||||
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
$ java -jar ../start.jar --create-startd
|
||||
INFO : Base directory was modified
|
||||
|
@ -63,16 +63,15 @@ It also downloaded the needed Infinispan-specific jar files and created a direct
|
|||
|
||||
In addition to adding these modules to the classpath of the server it also added several ini configuration files to the `${jetty.base}/start.d` directory.
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
If you have updated versions of the jar files automatically downloaded by Jetty, you can place them in the associated `${jetty.base}/lib/` directory and use the `--skip-file-validation=<module name>` command line option to prevent errors when starting your server.
|
||||
____
|
||||
|
||||
====
|
||||
==== Configuring Inifinspan Remote Properties
|
||||
|
||||
Opening the `start.d/session-store-infinispan-remote.ini` will show a list of all the configurable options for the JDBC module:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
# ---------------------------------------
|
||||
# Module: session-store-infinispan-remote
|
||||
|
@ -100,20 +99,19 @@ jetty.session.savePeriod.seconds=0::
|
|||
By default whenever the last concurrent request leaves a session, that session is always persisted via the `SessionDataStore`, even if the only thing that changed on the session is its updated last access time.
|
||||
A non-zero value means that the `SessionDataStore` will skip persisting the session if only the access time changed, and it has been less than `savePeriod` seconds since the last time the session was written.
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
Configuring `savePeriod` is useful if your persistence technology is very slow/costly for writes.
|
||||
In a clustered environment, there is a risk of the last access time of the session being out-of-date in the shared store for up to `savePeriod` seconds.
|
||||
This allows the possibility that a node may prematurely expire the session, even though it is in use by another node.
|
||||
Thorough consideration of the `maxIdleTime` of the session when setting the `savePeriod` is imperative - there is no point in setting a `savePeriod` that is larger than the `maxIdleTime`.
|
||||
____
|
||||
|
||||
====
|
||||
==== Configuring the Remote Infinispan Query Module
|
||||
|
||||
Enabling this module allows jetty to search infinispan for expired sessions that are no longer being referenced by any jetty node.
|
||||
Note that this is an *additional* module, to be used in conjuction with the `session-store-infinispan-remote` module.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
java -jar ../start.jar --add-to-start=infinispan-remote-query
|
||||
----
|
||||
|
@ -126,12 +124,11 @@ There are no configuration properties associated with this module.
|
|||
During testing, it can be helpful to run an in-process instance of Infinispan.
|
||||
To enable this you will first need to enable the `session-store-infinispan-embedded` link:#startup-modules[module] for your link:#startup-base-and-home[Jetty base] using the `--add-to-start` argument on the command line.
|
||||
|
||||
____
|
||||
[IMPORTANT]
|
||||
====
|
||||
If you are running Jetty with JDK 9 or greater, enable `session-store-infinispan-embedded-910.mod` instead.
|
||||
____
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
====
|
||||
[source, screen]
|
||||
----
|
||||
java -jar ../start.jar --add-to-start=session-store-infinispan-embedded
|
||||
|
||||
|
@ -167,7 +164,7 @@ In addition to adding these modules to the classpath of the server it also added
|
|||
|
||||
Opening the `start.d/session-store-infinispan-remote.ini` will show a list of all the configurable options for the JDBC module:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
# ---------------------------------------
|
||||
# Module: session-store-infinispan-embedded
|
||||
|
@ -185,20 +182,18 @@ jetty.session.savePeriod.seconds=0::
|
|||
By default whenever the last concurrent request leaves a session, that session is always persisted via the `SessionDataStore`, even if the only thing that changed on the session is its updated last access time.
|
||||
A non-zero value means that the `SessionDataStore` will skip persisting the session if only the access time changed, and it has been less than `savePeriod` seconds since the last time the session was written.
|
||||
+
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
Configuring `savePeriod` is useful if your persistence technology is very slow/costly for writes.
|
||||
In a clustered environment, there is a risk of the last access time of the session being out-of-date in the shared store for up to `savePeriod` seconds.
|
||||
This allows the possibility that a node may prematurely expire the session, even though it is in use by another node.
|
||||
Thorough consideration of the `maxIdleTime` of the session when setting the `savePeriod` is imperative - there is no point in setting a `savePeriod` that is larger than the `maxIdleTime`.
|
||||
____
|
||||
|
||||
|
||||
====
|
||||
==== Configuring Inifinspan Embedded Query
|
||||
|
||||
Similarly to the `session-store-infinispan-remote` module, the `session-store-infinispan-embedded` module has an adjunct module `infinispan-embedded-query`, which when enabled, will allow jetty to detect and properly scavenge defunct sessions stranded in infinispan.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
java -jar ../start.jar --add-to-start=infinispan-embedded-query
|
||||
----
|
||||
|
@ -213,14 +208,13 @@ Prior to release 9.4.13 we used the default Infinispan serialization, however th
|
|||
See issue https://github.com/eclipse/jetty.project/issues/2919 for more background.
|
||||
|
||||
We have provided a conversion program which will convert any sessions stored in Infinispan to the new format.
|
||||
____
|
||||
[IMPORTANT]
|
||||
====
|
||||
We recommend that you backup your stored sessions before running the conversion program.
|
||||
____
|
||||
|
||||
====
|
||||
How to use the converter:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
java -cp servlet-api-3.1.jar:jetty-util-9.4.13.jar:jetty-server-9.4.13.jar:infinispan-remote-9.1.0.Final.jar:jetty-infinispan-9.4.13.jar:[other classpath] org.eclipse.jetty.session.infinispan.InfinispanSessionLegacyConverter
|
||||
|
||||
|
@ -240,7 +234,7 @@ When used with no arguments the usage message is printed. When used with the `ca
|
|||
To perform the conversion, run the InfinispanSessionLegacyConverter with just the `cache-name`, and optionally the `host` system property.
|
||||
The following command will attempt to convert all sessions in the cached named `my-remote-cache` on the machine `myhost`, ensuring that application classes in the `/my/custom/classes` directory are on the classpath:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
java -cp servlet-api-3.1.jar:jetty-util-9.4.13.jar:jetty-server-9.4.13.jar:infinispan-remote-9.1.0.Final.jar:jetty-infinispan-9.4.13.jar:/my/custom/classes org.eclipse.jetty.session.infinispan.InfinispanSessionLegacyConverter -Dhost=myhost my-remote-cache
|
||||
----
|
||||
|
|
|
@ -24,7 +24,7 @@
|
|||
|
||||
When using the Jetty distribution, you will first need to enable the `session-store-jdbc` link:#startup-modules[module] for your link:#startup-base-and-home[Jetty base] using the `--add-to-start` argument on the command line.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
$ java -jar ../start.jar --create-startd
|
||||
INFO : Base directory was modified
|
||||
|
@ -48,7 +48,7 @@ In addition to adding these modules to the classpath of the server, several ini
|
|||
|
||||
Opening the `start.d/session-store-jdbc.ini` will show a list of all the configurable options for the JDBC module:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
# ---------------------------------------
|
||||
# Module: session-store-jdbc
|
||||
|
@ -103,14 +103,13 @@ jetty.session.savePeriod.seconds=0::
|
|||
By default whenever the last concurrent request leaves a session, that session is always persisted via the `SessionDataStore`, even if the only thing that changed on the session is its updated last access time.
|
||||
A non-zero value means that the `SessionDataStore` will skip persisting the session if only the access time changed, and it has been less than `savePeriod` seconds since the last time the session was written.
|
||||
+
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
Configuring `savePeriod` is useful if your persistence technology is very slow/costly for writes.
|
||||
In a clustered environment, there is a risk of the last access time of the session being out-of-date in the shared store for up to `savePeriod` seconds.
|
||||
This allows the possibility that a node may prematurely expire the session, even though it is in use by another node.
|
||||
Thorough consideration of the `maxIdleTime` of the session when setting the `savePeriod` is imperative - there is no point in setting a `savePeriod` that is larger than the `maxIdleTime`.
|
||||
____
|
||||
|
||||
====
|
||||
db-connection-type::
|
||||
Set to either `datasource` or `driver` depending on the type of connection being used.
|
||||
jetty.session.jdbc.datasourceName::
|
||||
|
|
|
@ -31,7 +31,7 @@ To enable it with the Jetty distribution, enable the `session-store-cache` link:
|
|||
|
||||
After enabling, the `$jetty.base/start.d/session-store-cache.ini` file will be generated:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
--module=session-store-cache
|
||||
|
||||
|
|
|
@ -24,7 +24,7 @@
|
|||
|
||||
When using the Jetty distribution, you will first need to enable the `session-store-mongo` link:#startup-modules[module] for your link:#startup-base-and-home[Jetty base] using the `--add-to-start` argument on the command line.
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
$ java -jar ../start.jar --create-startd
|
||||
INFO : Base directory was modified
|
||||
|
@ -61,16 +61,15 @@ It also downloaded the needed Mongo-specific jar file and created a directory na
|
|||
|
||||
In addition to adding these modules to the classpath of the server, several ini configuration files were added to the `${jetty.base}/start.d` directory.
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
If you have updated versions of the jar files automatically downloaded by Jetty, you can place them in the associated `${jetty.base}/lib/` directory and use the `--skip-file-validation=<module name>` command line option to prevent errors when starting your server.
|
||||
____
|
||||
|
||||
====
|
||||
==== Configuring MongoDB Session Properties
|
||||
|
||||
Opening the `start.d/session-store-mongo.ini` will show a list of all the configurable options for the MongoDB module:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
# ---------------------------------------
|
||||
# Module: session-store-mongo
|
||||
|
@ -97,14 +96,13 @@ jetty.session.savePeriod.seconds=0::
|
|||
By default whenever the last concurrent request leaves a session, that session is always persisted via the `SessionDataStore`, even if the only thing that changed on the session is its updated last access time.
|
||||
A non-zero value means that the `SessionDataStore` will skip persisting the session if only the access time changed, and it has been less than `savePeriod` seconds since the last time the session was written.
|
||||
+
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
Configuring `savePeriod` is useful if your persistence technology is very slow/costly for writes.
|
||||
In a clustered environment, there is a risk of the last access time of the session being out-of-date in the shared store for up to `savePeriod` seconds.
|
||||
This allows the possibility that a node may prematurely expire the session, even though it is in use by another node.
|
||||
Thorough consideration of the `maxIdleTime` of the session when setting the `savePeriod` is imperative - there is no point in setting a `savePeriod` that is larger than the `maxIdleTime`.
|
||||
____
|
||||
|
||||
====
|
||||
jetty.session.mongo.dbName::
|
||||
Name of the database in Mongo used to store the Session collection.
|
||||
jetty.session.mongo.collectionName::
|
||||
|
@ -123,9 +121,9 @@ jetty.session.mongo.connectionString;;
|
|||
The string defining the MongoURI value, such as `mongodb://[username:password@]host1[:port1][,host2[:port2],...[,hostN[:portN]]][/[database][?options]]`.
|
||||
More information on how to format the MongoURI string can be found in the https://docs.mongodb.com/manual/reference/connection-string/[official documentation for mongo.]
|
||||
+
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
You will only use *one* `connection-type` at a time, `address` or `uri`.
|
||||
If both are utilized in your `session-store-mongo.ini`, only the last `connection-type` configured in the file will be used.
|
||||
By default, the `connection-type` of `address` is used.
|
||||
____
|
||||
====
|
||||
|
|
|
@ -26,7 +26,7 @@ If you wish to change any of the default values, you need to enable the `session
|
|||
|
||||
Once the `session-cache-hash` module has been enabled, you can view a list of all the configurable values by opening `start.d/session-cache-hash.ini`:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
[source, screen]
|
||||
----
|
||||
--module=session-cache-hash
|
||||
|
||||
|
@ -47,11 +47,10 @@ Values are:
|
|||
* 0 : sessions are evicted from the cache as soon as the last active request for it finishes
|
||||
* >= 1 : any positive number is the time in seconds after which a session that is in the cache but has not experienced any activity will be evicted
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
If you are not using a `SessionDataStore` that persists sessions, be aware that evicted sessions will be lost.
|
||||
____
|
||||
|
||||
====
|
||||
jetty.session.saveOnInactiveEvict::
|
||||
Boolean, default `false`.
|
||||
Controls whether a session will be saved to the `SessionDataStore` just prior to its eviction.
|
||||
|
|
|
@ -47,7 +47,7 @@ There is only one (1) `SessionDataStore` per `SessionCache`.
|
|||
|
||||
Visually the session architecture can be represented like this:
|
||||
|
||||
image::images/SessionsHierarchy.png[]
|
||||
image::administration/sessions/images/SessionsHierarchy.png[]
|
||||
|
||||
==== Configuring Sessions in the Jetty Distribution
|
||||
|
||||
|
|
|
@ -68,7 +68,7 @@ That said, if a user wishes to configure sessions this way, it is possible using
|
|||
|
||||
Below is an example of how you could configure a the link:#configuring-sessions-file-system[`FileSessionDataStore`], but the same concept would apply to any of the *SessionDataStores discussed in this chapter:
|
||||
|
||||
[source, xml, subs="{sub-order}"]
|
||||
[source, xml]
|
||||
----
|
||||
<Configure class="org.eclipse.jetty.webapp.WebAppContext">
|
||||
<Call id="sh" name="getSessionHandler">
|
||||
|
@ -88,8 +88,8 @@ Below is an example of how you could configure a the link:#configuring-sessions-
|
|||
|
||||
The example above functions in either a `jetty-web.xml` file or a link:#using-basic-descriptor-files[context xml descriptor file.]
|
||||
|
||||
____
|
||||
[NOTE]
|
||||
====
|
||||
If you explicitly configure the `SessionCache` and `SessionDataStore` for a `SessionHandler` in a context xml file or `jetty-web.xml` file, any session modules you already have enabled are ignored.
|
||||
So, for example, if you had enabled the `session-store-gcloud module` for your sever, you could force a particular webapp to use the `FileSessionDataStore` by explicitly configuring it in either a context xml file or a `jetty-web.xml` file as shown above.
|
||||
____
|
||||
====
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue