...
| Code Block |
|---|
java -Doption1=value -Doption2=value -jar start.jar etc/jetty.xml |
More information about starting and stopping Jetty can be found in Running Jetty-6.1.x.
Customizing your Jetty configuration
...
| Code Block | ||
|---|---|---|
| ||
<?xml version="1.0"?> <!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd"> <Configure id="Server" class="org.mortbay.jetty.Server"> <!-- required configuration --> <!-- connectors --> <!-- handlers --> <!-- webapps/contexts --> <!-- optional configuration --> <!-- threadpool --> <!-- session id manager --> <!-- authentication realms --> <!-- request logs --> <!-- extra server options --> </Configure> |
...
Configuration file breakdown
Doctype (required)
All tags and elements declared inside jetty.xml will be pointing to this resource, configure.dtd. This means that only tags and elements based from this data type file will be valid .
...
| Code Block | ||
|---|---|---|
| ||
<Set name="ThreadPool">
<New class="org.mortbay.thread.QueuedThreadPool">
<Set name="minThreads">10</Set>
<Set name="maxThreads">200</Set>
<Set name="lowThreads">20</Set>
<Set name="SpawnOrShrinkAt">2</Set>
</New>
</Set>
|
Security Realm (optional)
If you want to use authentication and authorisation, then you need to define a Security realm. There is no limit to the number or types of realms that you can define for a Server. The following example sets up a security realm that is populated by the etc/realm.properties file:
| Code Block | ||
|---|---|---|
| ||
<Set name="UserRealms">
<Array type="org.mortbay.jetty.security.UserRealm">
<Item>
<New class="org.mortbay.jetty.security.HashUserRealm">
<Set name="name">Test Realm</Set>
<Set name="config">etc/realm.properties</Set>
</New>
</Item>
</Array>
</Set>
|
More
For a more detailed explanation of the default settings, see the jetty.xml walkthrough. The Syntax Reference explains the syntax for individual elements.
...
For more details about configuring static deployment, see WebAppDeployer.
Hot Deployment of Customized Contexts
In addition to deploying webapps at start-up, you can also do hot deployment: configure a context deployer which scans a specific directory for XML configuration files, and deploys/redeploys/undeploys a webapp if its configuration file has been modified, added, or removed. These configuration files also allow you to configure certain Jetty-specific per-context settings; configuration file and its format is specific to Jetty. To keep things short, I am not going to reproduce the entire configuration. Add this block to either of the previous examples:
...
Similar to the one handler example, but defines multiple handlers. A handler can be configured either as soon as it is declared, or further down using the Ref tag. There is no difference in effect between the two. That example serves up static files in the logs directory under your current directory, and logs all requests since the server was last started to request.log.
To see the demo this in action, go to http://localhost:8080/request.log and refresh a few times (you may need to hard refresh, to make sure you are not seeing a cached copy of the data).
For simplicity's sake, the log files do logfile's name does not contain a date; see jetty.xml for an extended configuration which does.
...