Jetty Vs Tomcat

  • 54,915 views
Uploaded on

Comparison of Jetty vs Tomcat

Comparison of Jetty vs Tomcat

More in: Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
54,915
On Slideshare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
734
Comments
0
Likes
19

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. (1)Jetty vs Tomcat: A Comparative Analysis (2)Newbie Guide to Jetty (3)Jetty Documentation
  • 2. (1) Jetty vs Tomcat: A Comparative Analysis prepared by Greg Wilkins - May, 2008 1. Introduction Jetty and Tomcat are often cast as direct competitors. This paper is short comparison of the technical and non-technical aspects of these two open source servlet containers. 2. Technical Comparisons 2.0. Architecture The view from 20,000 feet is that Tomcat and Jetty are rather similar, they are both java applications servers offering implementations of the 2.5 servlet specification with optional extras giving many JEE features. However, on closer inspection, the architectures of the two servers differ greatly, mostly because each project as historically had a different focus: Tomcat is first and foremost an application server. Its default incarnation is as software installed onto a system, into which one can install applications. Tomcat can be stripped down to be embedded or built up the be an full JEE server, but both are difficult exercises. Jetty is first and foremost a set of software components that offer HTTP and servlet services. Jetty can be invoked and installed as a stand alone application server or it can be easily embedded in an application or framework as a HTTP component, as a simple servlet engine, as a feature rich servlet engine or as part of a full JEE environment. It is the flexible component based architecture of Jetty that allows it to be flexibly deployed and integrated in a diverse range of instances: • From mobile phones to large clusters of big iron servers • In software frameworks and tools: OSGi Equinox, OSGi Felix, Spring, Plexus, Cocoon, Tapestry, Maven, Continuum, Fisheye, Grails, JRuby, Xbean, etc. • In JEE application servers: Geronimo, Jboss, Sybase EAServer, JOnAS and Glassfish
  • 3. • Embedded in applications, products and services from IBM, HP, Cisco, BEA, Yahoo, Eclipse (see http://docs.codehaus.org/display/JETTY/Jetty+Powered) • As the basis for enhanced services such a SIP (www.cipango.org), Ajax JMS (www.activemq.org), Asynchronous SOA services (Apache Camel) As the servlet specification continues to grow and add additional features (annotations, automatic web services, etc.) the cost of a standard servlet server is increasing. While Jetty will always continue to support the standard incarnation, its modular approach allows deployments to be targeted at precisely the set of services required without the additional complexities, inefficiencies and security concerns of unused features. 2.1. Performance Both Jetty and Tomcat offer good request per second performance and for any non-trivial web application it is highly unlikely that either will be the main bottleneck. General benchmarks are difficult to provide and web load profiles are greatly influenced by the actual application and there is no substitute for specific application benchmarking. However, some generalized observations can be made: • Tomcat tends to have slightly better performance when there are few very busy connections. It has a slight advantage in request latency, which is most apparent when many requests/responses are sent over a few connections without any significant idle time. • Jetty tends to have better scalability when there are many connections with significant idle time, as is the situation for most web sites. Jetty's small memory footprint and advance NIO usage allows a larger number of users per unit of available memory. Also the smaller footprint means that less memory and CPU cache is consumed by the servlet container and more cache is available to speed the execution of non-trivial applications. • Jetty also has better performance with regards to serving static content, as Jetty is able to use advance memory mapped file buffers combined with NIO gather writes to instruct the operating system to send file content at maximum DMA speed without entering user memory space or the JVM. 2.2. Features Both Jetty and Tomcat implement the core standard servlet 2.5 specification. Both servers offer a range of EE inspired features such as JNDI, JTA, JMS, Mail servers, etc. Tomcat has an easy migration path for full EE towards Jboss and Geronimo. Jetty has an easy migration path for full EE towards Geronimo, JBoss, JOnAS, Sybase EAServer and, to some extent, Glassfish.
  • 4. In the last 18 months, there has been an increased focus on web-2.0 features, specifically Ajax Push and Comet. Jetty has been a leader in supporting the web-2.0 use-case from within the servlet model and Webtide has formalized the Jetty approach in a proposal to JSR315 for the Servlet 3.0 that is likely to be accepted as the standard way to provide the asynchronous servlets that are needed by web-2.0. In comparison, the Tomcat project was slow to accept the Web-2.0 use-case, but are now offering an async IO API that does fulfill the requirement. However that approach is not from within the servlet model, so standard frameworks (JSP, Struts, etc) and techniques cannot be used. 3. Non-Technical Comparisons 3.0. Market Share Selecting the market leader is often used as an important selection criteria. While market share is often a good indication of technical strength, there are often many non-technical and/or historical reasons that may contribute to and devalue market share as a selection criteria -specially in a market heavy influenced by standards. More over, the dominant market share once held by Tomcat is in decline, while Jetty's market share has been steadily increasing over the last 18 months to the point where it now has 80% of Tomcat's market share as reported in the Netcraft server surveys: The Netcraft (http://www.netcraft.com) report surveys only measure a fraction of installations as many servers have had their identifies disabled or are hidden behind load balancers or other web servers such as Apache. If installed base is to be considered, then Jetty's use in many frameworks and tools (e.g. in the Eclipse IDE from 3.3 onwards) would give Jetty a regular usage basis in the millions.
  • 5. 3.1. Reference Implementation Tomcat was the reference implementation for servlets 2.4 and thus was often selected on that basis. From version 2.5 onwards, Tomcat is no longer the reference implementation. Sun Microsystems forked the Tomcat server to create Glassfish as the reference implementation for servlet 2.5 and servlet 3.0 as well as for JSP 2.1 onwards. Jetty pays close attention to the specification and faithfully implements it. The Jetty developers were also very active on JSR-154 for servlets 2.5 and now on JSR-315 for servlets 3.0. Thus Jetty not only follows the servlet specification, but is able to influence the ongoing enhancement of the specification and to anticipate upcoming changes. 3.2. Development Community Jetty enjoys a stable development team and process, and has the same for more than a decade. Jetty has been developed by the same core team since 1995 (using java 0.9) and has been supported by Mort Bay Consulting and now by the partnership between Webtide LLC and Mort Bay. The project lives at the independently minded codehaus.org project repository. The active group of people developing Jetty is of moderate size and of a healthy, friendly and collaborative nature. The extended community in which Jetty has developed includes close collaborations with many other open source projects including Maven, ActiveMQ, Spring, Eclipse, JBoss, Geronimo, etc. Tomcat has unfortunate history of a fragmented development community that is characterized more by revolution than by collaboration or evolution. The transitions from Tomcat 3 to 4, 4 to 5, 5 to 5.5 and 5.5 to 6 have often resulted in the community splitting or of core developers leaving the project. The governance and development issues of Tomcat have culminated in: • The loss of the status as Reference Implementations • The forking of the project to Sun's Glassfish • The project has switched from Commit and Review development to Review and Commit. The upcoming move to Servlet 3.0 is going to require non-trivial enhancements to all servlet servers. Having a unified harmonious, experienced and proven development team and process will be key to the smooth transition to the new specification and the services and features that it will support. 4. Summary The Tomcat project is a reasonable quality Java application server that has an established brand and large user base. When used for it's prime role, Tomcat well fulfills the requirements. However it does lack the
  • 6. flexibility as a software component and the capability as a project and community to adapt to changing requirements and new innovative usage. The Jetty project/team has an attitude and a history of being responsive to innovations and changing requirements. This has resulted in a well architected software platform that has been integrated and deployed in almost every environment and that is supported by a sizable, healthy and growing community. For more information about Jetty, please check out the official Jetty website at http://jetty.mortbay.org/jetty/.
  • 7. Jetty - Eclipse Project Creation Review www.eclipse.org/proposals/jetty/Jetty_Creation_Review.pdf Initial Contributions The initial code will be the current jetty trunk as located in svn at The Codehaus. A bundle has already been delivered to begin the IP verification process. Description Jetty is an open-source, standards-based, full-featured web server implemented entirely in Java. It is released under the Apache 2.0 license and is therefore free for commercial use and distribution. Once established as an Eclipse project, it will be dual-licensed, maintaining its Apache 2.0 license, and adding the Eclipse Public License. Beyond the license addition, which would not require any changes from the current large number of users or consuming open source projects or commercial products with use of Jetty, the move is seen as having numerous benefits for the projects and community... • The transition would be a great time to clean up the project's packaging as it moves to an org.eclipse name. • The project will be focused on providing components and less on providing a bundled application server stack. This will allow great focus of development energies and further bring out Jetty's embedding strengths. • The Eclipse IP policies will supplement Jetty's existing processes. • Jetty could discuss handling the maintenance and updating the OSGI HTTP service for Equinox as a module. The project is also interested in being involved in an effort to modernize the standard for OSGI HTTP service. At this time, the project does not envision revising its internal structure to use OSGi, but to stay with POJO that can be configured with IOC/DI frameworks, which will work well for OSGi. • The being a part of Eclipse's release trains would simplify spreading current versions of Jetty for use in relevant projects within the Foundation that may be interested. As history, Jetty was first created in 1995, and has benefited from input from a vast user community and consistent and focused development by a stable core of lead developers. There are many examples of Jetty in action on the Jetty Powered Page however, as Jetty aims to be as unobtrusive as possible, countless websites and products are based around Jetty, but Jetty is invisible! Jetty can be used as: • a stand-alone traditional web server for static and dynamic content • a dynamic content server behind a dedicated HTTP server such as Apache using mod_proxy or mod_jk • an embedded component within a java application • as a component to build an application server or Java EE server This flexibility means that Jetty can be encountered in a number of different contexts:
  • 8. • shipped with products to provide out-of-the-box usability eg Tapestry, Grails, JRuby • distributed on CDs with books to make examples and exercises ready-to-run • incorporated into applications as a HTTP transport eg JXTA, Cisco SESM • integrated as a web container in JavaEE app servers eg Jonas, Geronimo, JBoss, Sybase • included as a component of an application eg Eclipse IDE, Hadoop Some of the defining features of Jetty are: • Simplicity ◦ Jetty is built by an assembly of simple components. ◦ Where possible features are added by aggregation of components rather than creation of complex deep/optional APIs ◦ Assembly and configuration can be done by the java API, the jetty XML configuration file, which is an IOC style mapping of XML to POJO APIs, other IOC/component frameworks such as Spring and Plexus, OSGi activators, and other XML to POJO mappings such as XBeans • Embeddability Jetty is designed to be a good component. This means that it can easily be embedded in an application without forcing the application to adapt to it's ▪ Configuration files or formats ▪ File system layout ▪ Classloading hierarchy ▪ Usage of dependency injection and inversion of control patterns • Pluggability ◦ Jetty is architected for pluggability. The API allows different implementations of all of the principal Jetty components to be selected. At least one, but sometimes more, implementations of a component are always provided. However if these do not meet your needs, you are free to code your own using the interfaces and abstract classes as a basis. This means that Jetty can be easily customized to a particular application environment. This is particularly useful when Jetty is acting as the web container in a JavaEE server, as Jetty's pluggability ensures a tight integration with a host container.
  • 9. (2)N ewbie Guide to Jetty • http://docs.codehaus.org/display/JETTY/Newbie+Guide+to+Jetty • Starting up Jetty • Starting with Jetty using start.jar and jetty.xml • Customizing your Jetty configuration • Overview • Configuration file • Configuration file breakdown • Doctype (required) • Server (required) • Connectors (required) • Handlers (required) • ThreadPool (optional) • Security Realm (optional) • More • Examples • Barebones Static Webapp Deployment • Static Webapp Deployment, version 2 • Hot Deployment of Customized Contexts • File Server, One Handler • File Server, Multiple Handlers Starting up Jetty • jetty-runner.jar - fast and easy way to run your webapp, without needing to install and administer a jetty distro. Run it using java -jar jetty-runner.jar webappcontext. Further instructions can be found in the blog entry linked to above. • start.jar - start from within your Jetty installation. Run it using java -jar start.jar configuration files • embed Jetty into your application • as a distribution package (RPM, .deb) • Maven Jetty Plugin Starting with Jetty using start.jar and jetty.xml These instructions assume that you have installed Jetty, although the configuration examples provided are applicable to anywhere you pass in a jetty.xml file.
  • 10. etc/jetty.xml is the default configuration file for Jetty. It demonstrates several basic functions, and can be used as the basis for your own configuration. To immediately start up Jetty and begin looking around, go to $JETTY_HOME and run this command: java -jar start.jar That starts up Jetty and applies the configuration specified in etc/jetty.xml. You can then view the page by visiting http://localhost:8080/. There are several additional options that can be set on the command line when using the supplied jetty.xml: Option Value name jetty.home directory which contains the etc, webapps, contexts folders. No trailing slash. Default value is the directory from which you are running start.jar. jetty.host host for the default connector. No default value. jetty.port port for the default connector. Default value is 8080. jetty.logs directory which contains the request logs. No trailing slash. Default value is ${jetty.home}/logs To use these, do 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 etc/jetty.xml sets reasonable defaults, but you will want to customize Jetty to fit your needs. This section takes you through configuring Jetty using an XML file. Most examples will be based from the jetty.xml file, but there are also additional examples for several common use cases. Overview Configuration file A server configuration file will look something like this: Configuration file breakdown
  • 11. 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 . <!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd"> Server (required) org.mortbay.jetty.Server is the main class for the Jetty HTTP server. It is the first instance called when you run the server. It aggregates Connectors (HTTP request receivers) and request Handlers. The server is itself a handler and a ThreadPool. Connectors use the ThreadPool methods to run jobs that will eventually call the handle method. <Configure id="Server" class="org.mortbay.jetty.Server"> ... </Configure> Connectors (required) Implementations of the org.mortbay.jetty.Connector interface provide connectors for the HTTP protocol. It is here that you set the ports that Jetty will listen on for incoming connections. <Set name="connectors"> <Array type="org.mortbay.jetty.Connector"> <Item> <New class="org.mortbay.jetty.nio.SelectChannelConnector"> <Set name="host"><SystemProperty name="jetty.host" /></Set> <Set name="port"><SystemProperty name="jetty.port" default="8080"/></Set> ... </New> </Item> </Array> </Set> Handlers (required) Handlers process inbound requests. There is a handler which services web applications called org.mortbay.jetty.webapp.WebAppContext. If you don't wish to use a full-blown application but just want to serve static content and maybe some servlets, then you can use a ContextHandler and only configure those services you require.
  • 12. The list of handlers that are defined for a Server is set by the following call: <Set name="handlers"> <Array type="org.mortbay.jetty.Handler"> ... </Set> ThreadPool (optional) The ThreadPool class avoids the expense of thread creation by pooling threads for reuse after their run methods exit. If the maximum pool size is reached, jobs wait for a free thread. By default there is no maximum pool size. Idle threads timeout and terminate until the minimum number of threads are running. Configuring the ThreadPool is optional, because the server falls back upon defaults. However, you may wish to customize the thread pool to better fit your application. Example: <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: <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>
  • 13. More For a more detailed explanation of the default settings, see the jetty.xml walkthrough. The Syntax Reference explains the syntax for individual elements. Examples All examples assume that you are in $JETTY_HOME, and that the configuration file below is saved under $JETTY_HOME/etc/myjetty.xml. Barebones Static Webapp Deployment Below is the bare minimum required to start up the Jetty server and start serving up standard web applications. This will listen for connections on port 8080, and serve up any webapps placed under the $JETTY_HOME/webapps folder: <?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"> <Call name="addConnector"> <Arg> <New class="org.mortbay.jetty.nio.SelectChannelConnector"> <Set name="port">8080</Set> </New> </Arg> </Call> <Set name="handler"> <New id="Handlers" class="org.mortbay.jetty.handler.HandlerCollection"> <Set name="handlers"> <Array type="org.mortbay.jetty.Handler"> <Item> <New id="Contexts" class="org.mortbay.jetty.handler.ContextHandlerCollection"/> </Item> </Array> </Set> </New> </Set> <Call name="addLifeCycle">
  • 14. <Arg> <New class="org.mortbay.jetty.deployer.WebAppDeployer"> <Set name="contexts"><Ref id="Contexts"/></Set> <Set name="webAppDir"><SystemProperty name="jetty.home" default="."/>/webapps</Set> </New> </Arg> </Call> </Configure> Start up Jetty with this command: java -jar start.jar etc/myjetty.xml View your webapplications at http://localhost:8080/webappfolder/. If you have no webapp defined for the root context ("/"), visiting http://localhost:8080/ will give you a normal 404 page. Static Webapp Deployment, version 2 Here is a slightly more advanced version of the above: <?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"> <Call name="addConnector"> <Arg> <New class="org.mortbay.jetty.nio.SelectChannelConnector"> <Set name="host"><SystemProperty name="jetty.host" /></Set> <Set name="port"><SystemProperty name="jetty.port" default="8080"/></Set> </New> </Arg> </Call> <Set name="handler"> <New id="Handlers" class="org.mortbay.jetty.handler.HandlerCollection"> <Set name="handlers"> <Array type="org.mortbay.jetty.Handler"> <Item> <New id="Contexts" class="org.mortbay.jetty.handler.ContextHandlerCollection"/> </Item>
  • 15. <Item> <New id="DefaultHandler" class="org.mortbay.jetty.handler.DefaultHandler"/> </Item> </Array> </Set> </New> </Set> <Call name="addLifeCycle"> <Arg> <New class="org.mortbay.jetty.deployer.WebAppDeployer"> <Set name="contexts"><Ref id="Contexts"/></Set> <Set name="webAppDir"><SystemProperty name="jetty.home" default="."/>/webapps</Set> <Set name="parentLoaderPriority">false</Set> <Set name="extract">true</Set> <Set name="allowDuplicates">false</Set> <Set name="defaultsDescriptor"><SystemProperty name="jetty.home" default="."/>/etc/webdefault.xml</Set> </New> </Arg> </Call> </Configure> As before, start up Jetty with this command: java -jar start.jar etc/myjetty.xml View your webapplications at http://localhost:8080/webappfolder/. Other than the extra configuration settings, the biggest change is the addition of the org.mortbay.jetty.handler.DefaultHandler, which deals with unhandled requests in the server. If you have no webapps defined in the root context ("/"), visiting http://localhost:8080/ will 404, but will present a list of contexts that have been deployed on the server. DefaultHandler also serves up a Jetty favicon. 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
  • 16. 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: <Call name="addLifeCycle"> <Arg> <New class="org.mortbay.jetty.deployer.ContextDeployer"> <Set name="contexts"><Ref id="Contexts"/></Set> <Set name="configurationDir"><SystemProperty name="jetty.home" default="."/>/contexts</Set> <Set name="scanInterval">5</Set> </New> </Arg> </Call> That sets up a ContextDeployer, which will scan the $JETTY_HOME/contexts folder every 5 seconds for changes to the XML descriptors, and hot deploy as necessary. For more details, see ContextDeployer. File Server, One Handler Simple HTTP file server with one handler, similar to the embedded FileServer example and embedded OneHandler example. This example serves up purely static files from your current directory: <?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"> <Call name="addConnector"> <Arg> <New class="org.mortbay.jetty.nio.SelectChannelConnector"> <Set name="port"><SystemProperty name="jetty.port" default="8080"/></Set> </New> </Arg> </Call> <Set name="handler"> <New id="ResourceHandler" class="org.mortbay.jetty.handler.ResourceHandler"> <Set name="resourceBase">.</Set> </New> </Set> </Configure> Note that ResourceHandler does not allow directory listing; if you visit a directory with no welcome files, you will get a
  • 17. 403 Forbidden error message. Try the exact path to the file. If you just want a specific context to serve static content, while still serving dynamic web applications from other contexts, configure your server to allow hot deployment (see previous example), then set up a context to serve up Static Content. File Server, Multiple Handlers Simple HTTP file server with request logging. Similar to the embedded FileServer example and embedded ManyHandlers example <?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"> <Call name="addConnector"> <Arg> <New class="org.mortbay.jetty.nio.SelectChannelConnector"> <Set name="port"><SystemProperty name="jetty.port" default="8080"/></Set> </New> </Arg> </Call> <Set name="handler"> <New id="Handlers" class="org.mortbay.jetty.handler.HandlerCollection"> <Set name="handlers"> <Array type="org.mortbay.jetty.Handler"> <Item> <New id="ResourceHandler" class="org.mortbay.jetty.handler.ResourceHandler"> <Set name="resourceBase">./logs</Set> </New> </Item> <Item> <New id="RequestLog" class="org.mortbay.jetty.handler.RequestLogHandler"/> </Item> </Array> </Set> </New> </Set> <Ref id="RequestLog">
  • 18. <Set name="requestLog"> <New id="RequestLogImpl" class="org.mortbay.jetty.NCSARequestLog"> <Set name="filename"><SystemProperty name="jetty.logs" default="./logs"/>/request.log</Set> <Set name="append">false</Set> </New> </Set> </Ref> </Configure> 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 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 logfile's name does not contain a date; see jetty.xml for an extended configuration which does. Either a HandlerCollection or a HandlerList can be used when setting multiple handlers. org.mortbay.jetty.handler.HandlerCollection calls all handlers in turn. org.mortbay.jetty.handler.HandlerList calls each contained handler until either an exception is thrown, the response is committed,or a positive response status is sent. In this case, HandlerCollection was chosen so that the RequestLogHandler could log the requests.
  • 19. (3)J etty Documentation http://docs.codehaus.org/display/JETTY/Jetty+Documentation Jetty Documentation • Wiki top level • Jetty <= 6 @ codehaus • Jetty >= 7 @ eclipse • Jetty >= 7 wiki @ eclipse • Jetty Powered • About Jetty Getting Started • Downloading Jetty • Installing Jetty-6.1.x, Jetty-7.0.x • Running Jetty-6.1.x, Jetty-7.0.x • Windows Service Wrapper • Debian Packages • RPMs • Supported JVMs References • Jetty Architecture • Jetty Xml Configuration Syntax Reference • Javadoc • xref • Walkthrough: jetty.xml • Jetty Security Tutorials • Newbie Guide to Jetty • Writing a Jetty Handler • Embedding Jetty • Porting to jetty6 • Upgrade from jetty6 to jetty7(eclipse)
  • 20. • Getting Started with Jetty on www.itjungle.com Development • Contributing • Jetty Coding Standards • SVN: • jetty-7 (developers svn+ssh) • jetty-7 accessories (developers https) • jetty-6 (developers https) • jetty-6 contrib (developers https) • hightide (developers https) • Codehaus CI • Building from Source • JIRA • Jetty-6.1.x Release Procedure • Jetty-7.0.x Release Procedure • Website Release Procedure • Building Jetty RPMs Feature Guides Asynchronous Servlets • Suspendable Requests • Continuations • Quality of Service Filter • Asynchronous REST & Jetty HTTP Client • [Asynchronous Web Services] • Asynchronous Proxy Servlet AJAX / Comet • Continuations for Ajax Comet • Cometd (aka Bayeux) • Acknowledged Messages • [Clustering with Oort] coming soon • ActiveMQ Maven Support
  • 21. • Maven Jetty Plugin • Which files are scanned by the Jetty Maven Plugin • Maven Jetty Jspc Plugin • Maven web app project archetypes courtesy of Webtide Ant Support • Ant Jetty Plugin IDEA • Debugging Jetty with IntelliJ IDEA Eclipse Workbench • Importing Jetty Source into Eclipse • Debugging Jetty with Eclipse • Debugging with the Maven Jetty Plugin inside Eclipse • Jetty Eclipse Plugin - Web Tooling Support • JettyLauncher Soon to be upgraded to jetty6 • run-jetty-run Cargo • Cargo container-agnostic testing tools Useful Servlets and Filters • Servlets Bundled with Jetty Mobile Computing • Google Android: i-jetty • JME CDC JEE Server Integrations • Apache Geronimo JEE • RedHat JBoss • Grizzly Connector from Glassfish
  • 22. • Sybase EAServer • Remote Glassfish EJBs from Jetty Web Frameworks • DWR • MyFaces • JSF Reference Implementation • Jakarta Slide • Google Web Toolkit (GWT) • Jetspeed2 • ICEfaces EJB • Jetty and Spring EJB3 (Pitchfork) • JBoss EJB3 • ObjectWeb EasyBeans (aka JOnAS EJB3 container) • Remote Glassfish EJBs from Jetty Clustering Technologies • [Gigaspaces ] coming soon • Terracotta (generic Terracotta version) • Terracotta (Jetty version) • WADI • see also Session Clustering using a Database Infrastructure • Atomikos Transaction Manager • JOTM • Bitronix Transaction Manager • ActiveMQ • Binding JAX-WS 2.x Endpoints to Jetty contexts • Java-monitor OSGi • Jetty OSGi Powered Products
  • 23. • OSGi Tips • Jetty as the HTTP Service in Equinox • Jetty as the HTTP Service in Felix • Jetty as the HTTP Service in PAX • ProSyst mBedded Server Equinox Edition • Jetty in Spring Dynamic Modules • Jetty in JOnAS 5 Amazon EC2 • Jetty on Amazon EC2 Other • JIRA How Tos General • Running Jetty with jconsole • Debug Logging • Useful web developer tools • How to test Servlets • File Upload in jetty6 General Configuration • Configuring Jetty • The jetty.xml file • The jetty-web.xml file • The jetty-env.xml file • The webdefault.xml file • The override web.xml file • Temporary Directories • System Properties • How to capture stderr/stdout • Suppressing HTTP Server Header • Classloading • JSP Configuration
  • 24. • Serving aliased/symbolically linked files • Customizing startup • Using XBean to configure Jetty • How to Create Custom Error Pages • GZIP Compression Contexts and Web Applications • Web Application Deployer (static deploy) • Context Deployer (hot deploy!) • Static Content • Relocating / Redirecting Contexts • Rewrite Handler • see also Embedding Jetty and Maven Jetty Plugin • Multiple WebApp Source Directory Connectors • Configuring Connectors • Configuring SSL • Ssl Connector Guide • Configure SSL Cipher Suites • Apache mod_proxy (Reverse Proxy) • Apache mod_proxy_ajp and mod_jk for AJP • Running on port 80 as non-root user Associating webapps with ports and virtual hosts • Serving different webapps from different ports • Virtual hosts Thread Pools • Bounded ThreadPool • Queued ThreadPool TODO Security • Jetty Security reports. • Securing Jetty
  • 25. • Securing Passwords • Realms • JAAS Realms • How to Configure Security with Embedded Jetty Management • Server Log (coming soon) • Request Logging • Collecting statistics • Graceful shutdown • JMX Annotations • Annotations, Resource Injection and Lifecycle Callbacks JNDI Services • Using JNDI • DataSource Examples JSP • JSP 2.0 and JSP 2.1 • JSP Configuration Sessions • Session Configuration • Persisting Sessions • Single Sign On - Jetty HashSSORealm Clustering • Session Clustering using a Database • [Session Clustering using Gigaspaces] coming soon • Session Clustering with Terracotta(Generic) • Session Clustering with Terracotta(Jetty) • Session Clustering with WADI
  • 26. Optimizing • Optimizing with Last-Modified and Cache-Control • Optimizing Browser Caching • Optimizing on High Load Servers Other • International Characters and Character Encodings • Intercepting Connections and Requests • Using Jetty to Put a Website on a CD (Jetty 5 - but same principle applies ) Trouble shooting • No warning starting Jetty on port already in use (on Windows) • Files locked on Windows • Slow File Serving on Windows 2003 • Save could not be completed • Temporary directory files not deleted • Welcome files not working • Invalid Content Length Log Message • JSP expression do not evaluate • Keep Generated • Post requests using nio https hang • Security Constraints and Welcome Files • SSL does not work with DSA key • Problems with JAAS 6.0.x • NullpointerException in jasper Localizer class • Zip exception reading jar or war files • Connectors slow to startup • Frequent disconnects when downloading large files • OutofMemory Errors • J2SE 6 Problems • Webapp suddenly stopped working FAQ - Frequently Asked Questions General
  • 27. • Why is it called Jetty? • How do I submit a support question? • Porting to jetty6