The laws that govern the life of Java code on a web server are laid out in the Servlet Specification (can be downloaded from http://java.sun.com/products/servlet/download.html). A Servlet is basically a standardized way of writing Java code so that it can be used with any servlet container, and benefit from the services provided by it.
A servlet container is a piece of software that collaborates with a web server. Requests from the Internet come to the web server first, and if it decides that those requests are for functionality provided by a Java application, it passes them to the servlet container.
Servlet containers manage low-level issues like networking, maintaining special kinds of memory to be used by the applications or making sure that proper initialization was made as required. This way it frees servlet developers to write code specific only to their application.
However, writing Java code at the level of servlets is still rather low-level work, and many Java web frameworks appeared to provide ready-to-use solutions for common, repeating tasks. Frameworks are ultimately based on the Servlet API, but building web applications with them is much easier, and more efficient, than working on the level of servlets.
Tapestry 5 is perhaps the most advanced and the most developer-friendly of the Java web frameworks, and so it shields us very efficiently from the nitty-gritty of servlet specification. However, there are a few pieces of servlet-related information that will be useful for us, such as:
1. The standard structure of a Java web application.
2. The basics of a deployment descriptor.
3. The basics of a WAR file.
It might also be useful to mention different kinds of Java-enabled servers so that you can decide which one of them to use.
A Servlet container requires every Java web application to have a certain structure so that it can manage the application properly. Here is the outline of such a structure:
Perhaps the most important part of it is the WEB-INF directory. It is the brain and heart of a Java web application. The contents of this directory are protected by the servlet container—it prevents anyone from navigating to, say, http://www.someserver.com/myapp/WEB-INF/ and seeing what this directory contains.
The WEB-INF/classes subdirectory is where the compiled Java classes go—those classes that we create for our application, such as page classes.
The WEB-INF/lib subdirectory is for the libraries used by the application, such as the Tapestry framework libraries. Any class or resource stored here should normally be packaged in a JAR file.
The web.xml file which must be present inside the WEB-INF directory is a deployment descriptor—it is described in the next section. Also, the WEB-INF directory can contain other files as needed by the application.
There can be another hidden directory in a Java web application, META-INF. It can contain other useful information about the application.
All the other files and directories, those outside WEB-INF and META-INF , are accessible from the Web. This means that if we have have a JSP page named somePage.jsp, it can be seen by anyone by navigating to something like http://www.someserver.com/myapp/somePage.jsp. Typically you will find here HTML and JSP pages as well as images and stylesheets. Naturally, they all can be put into as many different directories as is convenient.
Returning to the web.xml file, we never had any need to look into it in the course of the book, so it is actually not necessary to know its contents. But sometimes such knowledge can be useful, so let's have a look into deployment descriptor.