Servlets are the Java platform technology of choice for extending and enhancing Web servers.Servlets are the Java platform technology of choice for extending and enhancing Web servers.
Servlets are the Java platform technology of choice for extending and enhancing Web servers. Servlets provide a component-based, platform-independent method for building Web-based applications, without the performance limitations of CGI programs. And unlike proprietary server extension mechanisms (such as the Netscape Server API or Apache modules), servlets are server- and platform-independent. This leaves you free to select a "best of breed" strategy for your servers, platforms, and tools.
Servlets have access to the entire family of Java APIs, including the JDBC API to access enterprise databases. Servlets can also access a library of HTTP-specific calls and receive all the benefits of the mature Java language, including portability, performance, reusability, and crash protection.Today servlets are a popular choice for building interactive Web applications. Third-party servlet containers are available for Apache Web Server, Microsoft IIS, and others. Servlet containers are usually a component of Web and application servers, such as BEA WebLogic Application Server, IBM WebSphere, Sun Java System Web Server, Sun Java System Application Server, and others.
This document explains the concepts of Java Servlets and provides a step-by-step tutorial for writing HTTP Servlets with complete source code for the example Servlets. The tutorial and the other chapters cover all facets of Servlet programming from a simple "Hello World" Servlet to advanced Servlet features like session tracking and Cookies. There are also appendices on compiling and running Servlets. The reader is assumed to have some basic knowledge of HTML and Java programming.
Servlets are modules of Java code that run in a server application (hence the name "Servlets", similar to "Applets" on the client side) to answer client requests. Servlets are not tied to a specific client-server protocol but they are most commonly used with HTTP and the word "Servlet" is often used in the meaning of "HTTP Servlet".
Typical uses for HTTP Servlets include:
Processing and/or storing data submitted by an HTML form.
Providing dynamic content, e.g. returning the results of a database query to the client.
Managing state information on top of the stateless HTTP, e.g. for an online shopping cart system which manages shopping carts for many concurrent customers and maps every request to the right customer.
Servlets are not alone in a Web Server. They have access to other Servlets in the same Servlet Context (usually a Servlet directory), represented by an instance of javax.servlet.ServletContext. The ServletContext is available through the ServletConfig object's getServletContext method.A Servlet can get a list of all other Servlets in the Servlet Context by calling getServletNames on the ServletContext object. A Servlet for a known name (probably obtained through getServletNames) is returned by getServlet. Note that this method can throw a ServletException because it may need to load and initialize the requested Servlet if this was not already done.After obtaining the reference to another Servlet that Servlet's methods can be called. Methods which are not declared in javax.servlet.Servlet but in a subclass thereof can be called by casting the returned object to the required class type.Note that in Java the identity of a class is not only defined by the class name but also by the ClassLoader by which it was loaded. Web servers usually load each Servlet with a different class loader. This is necessary to reload Servlets on the fly because single classes cannot be replaced in the running JVM. Only a ClassLoader object with all loaded classes can be replaced.
Servlet mailing lists are one of the best sources for up-to-the-minute information about servlets and related technologies. This page lists the mailing lists you may want to join, with links for more information and to archives.
Servlets.com offers three different mailing lists you can join to be notified when important content is added to the site.
The first is servlets-announce, an announcement list. It's very low traffic. We post to the list only for major changes.
The other two are weblog lists, for those interested in Jason Hunter's weblog so they can be notified when new entries are added.
The first list, jhunter-blog, sends messages immediately when a new entry is added (about one per day). The second, jhunter-blogweekly, sends one message per week for all entries during that week. For simplicity the mailing lists is not broken out by category, but posts are formatted for easy mail filtering per category.
These days it seems there are servlet engines for nearly every web server, and now we're seeing servlets commonly offered as core value-add for Internet Service Providers (ISPs) and Web Hosting companies. The megacorp ISPs and Hosting companies still don't offer servlets, though, probably because it's not something Joe Consumer cares about. Also because to host servlets effectively and efficiently requires a bit of expertise. That makes finding a good servlet provider somewhat challenging. On this page we try to help you on that endeavor by keeping track of all the ISPs that are known to host servlets. For each ISP we provide location and contact information, a short summary, and user reviews. The reviews should help you find out how the ISP you're looking at compares to others in terms of features, reliability, support, and overall score. Feel free to add one of your own.
Over the past few years, Java servlets have taken the server-side programming community by storm. Now, with the introduction of Version 2.3 of the Servlet API, servlets are taking Java to a new level of software development for the Web. Servlets offer a fast, powerful, portable environment for creating dynamic web content. They can execute within the web server's process space and they persist between invocations, which gives them tremendous performance benefits over other solutions. Servlets have full access to the various Java APIs as well as third-party component classes, and are an integral part of the Java 2 Enterprise Edition (J2EE). Best of all, servlets are portable among operating systems and among servers-with servlets you can "write once, serve anywhere."
The com.oreilly.servlet package is the "must have" class library for servlet developers. There are classes to help servlets parse parameters, handle file uploads, generate multipart responses (server push), negotiate locales for internationalization, return files, manage socket connections, and act as RMI servers, as well as a class to help applets communicate with servlets. Since the first edition, there are also new classes to help servlets send email messages, cache responses, and auto-detect servlet API support. The latest version is available online (with javadoc documentation) for download from http://www.servlets.com.
Why did I write these classes? They started out as chapter examples in my book Java Servlet Programming being published by O'Reilly & Associates. Then one happy day I recognized they could, with a little modification, live on their own as reusable utility classes. That day, or maybe a few procrastinating days later, com.oreilly.servlet was born.
Jetty is a 100% Java HTTP Server and Servlet Container. This means that you do not need to configure and run a separate web server (like Apache) in order to use java, servlets and JSPs to generate dynamic content. Jetty is a fully featured web server for static and dynamic content. Unlike separate server/container solutions, this means that your web server and web application run in the same process, without interconnection overheads and complications. Furthermore, as a pure java component, Jetty can be simply included in your application for demonstration, distribution or deployment. Jetty is available on all Java supported platforms.
Servlet 2.4 lacks some of the fireworks of past releases. Servlet 2.2 introduced the notion of self-contained Web applications. Servlet 2.3 added the power of filters and filter chains. Servlet 2.4, while adding several interesting features, has no superstars and spends more time polishing and clarifying the features that came before?a tying up of loose ends. This work's effect is that servers faithfully implementing 2.4 will be more interoperable than any past servers. But don't let me imply there's nothing new in Servlet 2.4! Here's a list of what's new:
Servlets now require HTTP/1.1 and J2SE (Java 2 Platform, Standard Edition) 1.3, and can work with J2EE 1.4
ServletRequest has new methods to observe the client connection
New support for internationalization and charset choice
RequestDispatcher has new features and clarifications
New ServletRequest listener classes and methods
A deprecated SingleThreadModel
HttpSession details and interaction with logins has been clarified
Classloading and welcome-file behavior has been clarified
The web.xml file now uses XML Schema and has added a slew of new elements
A few years ago, the hype surrounding applets put Java on the map as a programming language for the Web. Today, Java servlets stand poised to take Java to the next level as a Web development language. The main reason is that servlets offer a fast, powerful, portable replacement for CGI scripts. The Java Servlet API, introduced as the first standard extension to Java, provides a generic mechanism to extend the functionality of any kind of server. Servlets are most commonly used, however, to extend Web servers, performing tasks traditionally handled by CGI programs. Web servers that can support servlets include: Apache, Netscape's FastTrack and Enterprise Servers,
Microsoft's IIS, O'Reilly's WebSite, and JavaSoft's Java Web Server. The beauty of servlets is that they execute within the Web server's process space and they persist between invocations. This gives servlets tremendous performance benefits over CGI programs. Yet because they're written in Java, servlets are far less likely to crash a Web server than a C-based NSAPI or ISAPI extension. Servlets have full access to the various Java APIs and to third-party component classes, making them ideal for use in communicating with applets, databases, and RMI servers. Plus, servlets are portable between operating systems and between servers -- with servlets you can "write once, serve everywhere."
The GenericServlet class implements the Servlet interface and, for convenience, the ServletConfig interface. Servlet developers typically subclass GenericServlet, or its descendent HttpServlet, unless the servlet needs another class as a parent. (If a servlet does need to subclass another class, the servlet must implement the Servlet interface directly. This would be necessary when, for example, RMI or CORBA objects act as servlets.) The GenericServlet class was created to make writing servlets easier. It provides simple versions of the life-cycle methods init and destroy, and of the methods in the ServletConfig interface. It also provides a log method, from the ServletContext interface. The servlet writer must override only the service method, which is abstract. Though not required, the servlet implementer should also override the getServletInfo method, and will want to specialize the init and destroy methods if expensive servlet-wide resources are to be managed.
introduced the changes coming in the Servlet API 2.3 and gave a short tutorial on the new servlet filter model. In this follow-on article, I'll dig deeper into servlet filters and look at several filters you can download for free on the Web. For each filter, I'll examine what it does, how it works, and where you can get it. You can use this article in two ways: to learn about some filters that are useful out of the box, or as an aid in writing your own filters. I'll start off with some simple examples and then move on to more advanced ones. At the end, I'll show you a file upload filter I wrote to support multipart requests.
a filter is an object that can transform a request or modify a response. Filters are not servlets; they don't actually create a response. They are preprocessors of the request before it reaches a servlet, and/or postprocessors of the response leaving a servlet. As you'll see later in the examples, a filter can:
Intercept a servlet's invocation before the servlet is called
Examine a request before a servlet is called
Modify the request headers and request data by providing a customized version of the request object that wraps the real request
Modify the response headers and response data by providing a customized version of the response object that wraps the real response
Intercept a servlet's invocation after the servlet is called
Servlet Container Work:
This article explains how a simple servlet container works. There are two servlet container applications presented; the first one is made as simple as possible and the second is a refinement of the first. The sole reason I do not try to make the first container perfect is to keep it simple. More sophisticated servlet containers, including Tomcat 4 and 5, are discussed in other chapters of How Tomcat Works.Both servlet containers can process simple servlets, as well as static resources. You can use PrimitiveServlet, located in the webroot/ directory, to test this container. More complex servlets are beyond the capability of these containers, but you can learn how to build more sophisticated servlet containers in the How Tomcat Works book.
In the first of three excerpts on Servlet best practices from Java Enterprise Best Practices, learn how to effectively work with Servlets. Since their introduction in 1996, servlets have dominated the server-side Java landscape and have become the standard way to interface Java to the Web. They are the foundation technology on which Java developers build web applications and, increasingly, web services. This chapter discusses best practices for servlet-based development and deployment.
A Servlet is an application program you write that runs on a web server. The servlet accepts and processes web requests through CGI (Common Gateway Interface) get or post requests.
How it Works:
A Servlet is actually a Java class you write that extends the javax.servlet.HttpServlet class. Here's how your servlet works:
A Web server receives an HTTP GET or POST request from a browser (or other TCP client).
The web server directs the HTTP request to the servlet engine (in the same way that direct CGI requests).
If your servlet is not already in memory, the servlet engine loads it and initializes it.
The servlet engine then encapsulates the HTTP request into a class called HttpServletRequest and delivers it to your servlet's doPost or doGet method.
Your servlet responds by writing HTML into HttpServletResponse which is sent back to the web server and delivered back to the TCP client.
It is a Java servlet implements calendar. You can use it as a standard calendar system, for booking some resources etc. Calendar supports WAP/WML so you can use it even from your mobile phone. Calendar's users may by notified by e-mail about schedule changes. Calendar supports file based persistence - your data will be saved in the flat file (files) or database based persistence.
1.How to Uses it:
a) copy calendarPackage.jar into your WEB-INF/lib directory.
b) define servlet in your web.xml file.
c) define a mapping for Calendar servlet in your web.xml file
The Java Servlet API allows a software developer to add dynamic content to a Web server using the Java platform. The generated content is commonly HTML, but may be other data such as XML. Servlets are the Java counterpart to dynamic web content technologies such as CGI, PHP or ASP. Servlets can maintain state across many server transactions by using HTTP cookies, session variables or URL rewriting. The Servlet API, contained in the javax.servlet package hierarchy, defines the expected interactions of a web container and a servlet. A web container is essentially the component of a web server that interacts with the servlets. The web container is responsible for managing the lifecycle of servlets, mapping a URL to a particular servlet and ensuring that the URL requester has the correct access rights.