SECTION: 200-General
TITLE: SpecCompliant
QUESTION: Is Jetty Compliant?

<p>
Jetty is guided by RFC and the JCP specifications and aims for total compliance.
The actual versions supported by various versions  of Jetty are indicated on the 
<a href="/jetty/download.html">download page</a>.
</p>
<p>
There is no formal tests available for RFC compliance, but Jetty contains a reasonable
test suite against RFC2616.
</p>
<p>
With Jetty's integration into the apache geronio application server, it has undergone 
J2EE 1.4 compliance testing against the official TCK.  A certifified compliant version
will be available via that project.  Jetty on it's own cannot be called compliant, 
as it lacks some of the full J2EE integration features and the project is not a
J2EE licensee.
</p>
<p>
Some parts of the J2EE compliance are considered not in the best interest of
performance and/or good design and we have this made them optional and turned
off by default: <ul>
<li>Java 2 compliant class loading - The servlet spec recommends an inversion of
java 2 class loading where classes in a web application may replace classes provided
by the container.  In Jetty, this is not supported by default (as it results in many
class loading issues).  Support for servlet spec compliant classloading can be obtained
by calling <code>HttpContext.setClassLoaderJava2Compliant(false)</code> and an example
of this is in jetty.xml
</li>

<li>Request Attribute listeners - as there is no real use-cases for these, support for
them is in the optional JSR154Filter, which is commented out by default in webdefault.xml.
</li>

<li>
SRV.6.2.2 Dispatachers - where the container cannot wrap the request or
response. See <a href="http://jetty.mortbay.org/jetty/doc/servlet24.html#d0e711">this
review</a> to find out why this is stupid. Support for compliant dispatching is
included in the JSR154Filter, which is commented out of webdefault.xml.
</li>

<li>JSR77 statistic can
be configured with <code>WebApplicationConfigurationClassNames</code> in jetty.xml.
</li>
</ul>