Jetty provides configuration options to control the three webapp class loading issues identified above.

You can configure webapp classloading by several methods on the WebAppContext. You can call these methods directly if you are working with the Jetty API, or you can inject methods from a context XML file if you are using the Context Provider (???). You CANNOT set these methods from a jetty-web.xml file, as it executes after the classloader configuration is set.

<Configure id="mywebapp" class="org.eclipse.jetty.webapp.WebAppContext">

...

  <Set name="classLoader">
    <New class="org.eclipse.jetty.webapp.CachingWebAppClassLoader">
      <Arg><Ref refid="mywebapp"/></Arg>
    </New>
  </Set>

...
</Configure>

You can add extra classpaths to Jetty in several ways.

<Configure class="org.eclipse.jetty.webapp.WebAppContext">
 ...
 <Set name="extraClasspath>../my/classes,../my/jars/special.jar,../my/jars/other.jar</Set>
 ...

If none of the alternatives already described meet your needs, you can always provide a custom classloader for your webapp. We recommend, but do not require, that your custom loader subclasses WebAppClassLoader. You configure the classloader for the webapp like so:

MyCleverClassLoader myCleverClassLoader = new MyCleverClassLoader();
 ...
   WebAppContext webapp = new WebAppContext();
 ...
   webapp.setClassLoader(myCleverClassLoader);

You can also accomplish this in a context xml file.

If you start a Jetty server using a custom class loader–consider the Jetty classes not being available to the system class loader, only your custom class loader–you may run into class loading issues when the WebAppClassLoader kicks in. By default the WebAppClassLoader uses the system class loader as its parent, hence the problem. This is easy to fix, like so:

context.setClassLoader(new WebAppClassLoader(this.getClass().getClassLoader(), context));

or

context.setClassLoader(new WebAppClassLoader(new MyCustomClassLoader(), context));

[[1xx-responses]] === Managing 1xx Responses

The HTTP RFC allows for 1xx informational responses to be sent before a real content response. Unfortunately the servlet specification does not provide a way for these to be sent, so Jetty has had to provide non-standard handling of these headers.

[[100-continue]] ==== 100 Continue

The 100 Continue response should be sent by the server when a client sends a request with a Expect: 100-continue header, as the client will not send the body of the request until the 100 continue response has been sent.

The intent of this feature is to allow a server to inspect the headers and to tell the client to not send a request body that might be too large or insufficiently private or otherwise unable to be handled.

Jetty achieves this by waiting until the input stream or reader is obtained by the filter/servlet, before sending the 100 continues response. Thus a filter/servlet may inspect the headers of a request before getting the input stream and send an error response (or redirect etc.) rather than the 100 continues.

[[102-processing]] ==== 102 Processing

RFC 2518 defines the 102 processing response that can be sent "when the server has a reasonable expectation that the request will take significant time to complete. As guidance, if a method is taking longer than 20 seconds (a reasonable, but arbitrary value) to process the server SHOULD return a 102 (Processing) response".

So if a request is received with the Expect: 102-processing header, then a filter/servlet may send a 102 response (without terminating further processing) by calling servletResponse.sendError(102);.