Examining a Web Application

HTML and JSP pages belong to the public resources that a client may request directly. Servlets, JavaBeans, and other resources within a Web application’s WEB-INF directory are private resources. You may allow the client to access these resources indirectly by mapping a URL to a servlet or including the page in a JSP page. However, private resources can’t be served to the client without some type of intervention.

The following is a typical makeup of a Web application required by the Servlet 2.4 specification:

 webapps/          pics/               index.html               gallery/                       index.html                       images/                              pic01.jpg                              pic02.jpg               images/                      code.gif                      execute.gif                      read.gif                      return.gif               WEB-INF/(*)                       web.xml(*)                       classses/(*)                                com/                                    Controller.class                                actions/                                        ViewGalleryAction.class                       jsp/                           catalog.jsp                       lib/(*)                           jstl.jar                           standard.jar                       tags/(*)                            simpleTag.tag                       tlds/                            simple.tld               META-INF/(*) 

Not all these files and directories are required. Those marked with (*) are part of the Servlet specification and can’t be renamed or moved, though some of them may be omitted. The WEB-INF folder, its subdirectories, and the META-INF folder are private areas that can be accessed only indirectly through application code or special configuration. A Web application deployed on Tomcat 5.5 as a WAR file may have a META-INF folder with a default context.xml file that provides context configuration information. Expanded Web applications may also use this mechanism, though providing a separate context XML file is the preferred method in this case.

This Web application is deployed in a folder named after the Web application (in this case it’s called pics), and this folder is required. You’d access this Web application using the following URL: http://servername:8080/pics/. The pics/ section is called the context path, and Tomcat uses this to resolve any paths contained within the Web application.

When a user requests a resource on the server (that is, an HTML document, a servlet, a JSP page, and so on), they type the path to it on the file system, relative to the context path. For example, if the user wants to request the C:\jakarta-tomcat\webapps\tomcatBook\ ch05\login.html file, they’d type http://servername:8080/tomcatBook/ch05/login.html. In other words, the server directory structure overlays the file system structure from the contents of the webapps directory down.

Note 

This generality applies to the default setup but doesn’t strictly apply to JSP pages. While the path to the resource is the same in the server and on the file system, the JSP page is processed into a servlet and compiled before it’s returned as a response. Therefore, there isn’t a one-to-one mapping between the requested resource and the resource that returns content. This distinction isn’t relevant to your users, as they won’t notice the difference, but it’s a fact worth knowing.

This default behavior is a problem if a Web application is running servlets, because they reside in the private WEB-INF area and can’t be accessed directly by users. In times past, the solution was to use the invoker servlet, but this isn’t recommended. The answer is servlet mappings.

Mapping URLs to Resources

If a Web application uses servlets, users need some way to access them. The answer lies in web.xml, the Web application deployment descriptor. You can set a series of URL mappings to make servlets available to users.

So, for the previous example Web application, you need to define a servlet and give it a name.

 <servlet>    <servlet-name>      Controller    </servlet-name>    <servlet-class>      com.Controller    </servlet-class>  </servlet> 

The name of the servlet must be unique within the Web application and can’t clash with those in the default web.xml file described in Chapter 4. The <servlet-class> element must contain the fully qualified class name. The previous servlet has a fully qualified class name with the package name (com) followed by the class name (Controller). The package name may be longer (for example, com.apress.servlets).

You have to perform one more step to make this named servlet available to your users. You must map it to a URL.

 <servlet-mapping>    <servlet-name>Controller</servlet-name>    <url-pattern>/Controller</url-pattern>  </servlet-mapping> 

This says that the http://servername:8080/pics/Controller URL should be passed to a servlet named Controller.

The mapping can use wildcards (*) to specify that you want to match any file, and you can use this with directories as well. This means you can cover whole directories with a mapping. For example, *.do is a common mapping used by the Apache Struts framework. This means that all requests ending in .do are routed to the specified servlet.

You can also map requests to JSP (or HTML) pages in the same manner. For example, say you want to show an index page for any requests that don’t correspond to a resource. This means users never see a directory listing of the server and won’t see a 404 error. Here’s the resource definition in web.xml:

 <servlet>    <servlet-name>      index    </servlet-name>    <jsp-file>      /index.html    </jsp-file>  </servlet> 

This specifies that the index.html file in the root of the Web application is called index for the purpose of this configuration file. Just as you did for the servlet, you must now map URLs to this resource.

 <servlet-mapping>    <servlet-name>      index    </servlet-name>    <url-pattern>      /*    </url-pattern>  </servlet-mapping> 

So, you’ve mapped the resource called index to the wildcard URL /*. This pattern matches every resource, so all requests, no matter if they point to a file that exists or not, will return the index.html page. However, the servlet engine will get to this entry only if there are no more-specific entries. This allows you to have fine-grained control over your resources.

If you have both of the previous settings in your web.xml file, then http://servername:8080/pics/Controller will display the results of the Controller servlet, and http://servername:8080/pics/Controller2, http://servername:8080/pics/blah, or any other URL that points to the pics context will display the index page. This is because the Controller mapping is more specific than the index mapping.

Examining the WEB-INF Folder

The WEB-INF folder contains at least four subfolders and the web.xml file.

Examining the classes Folder

The classes directory is in the Web application’s classpath, as are all of its subdirectories. This is why it contains servlets and the utility classes for the application, and it may also contain a number of resource files needed by these classes. It’s also a subdirectory of WEB-INF, making it a private resource. Users may not access any of the resources here. You saw an example of this earlier in the “Examining a Web Application” section.

Java classes in the classes directory follow the same package structure as any other classes. That is, they’re stored in a directory hierarchy within classes just as they would be in a regular setup. So, com.apress.PackageServlet is stored in the classes/com/apress directory.

Ideally, you don’t need to be concerned with the contents of the classes directory.

Examining the lib Folder

The lib folder is also in the Web application’s classpath. This is where you place JAR files that are required by the Web application.

Examining the tags Folder

As of JSP 2.0, developers can write tag extensions in JSP syntax without the need to know Java. Traditionally a tag extension was a Java class that defined the functionality of a custom markup tag. For example, a developer may write a tag that displayed the date, like so:

 <date:today/> 

These tag extensions are grouped together in tag libraries, which are a convenient way to group code that has similar functionality, much like a Java package does.

It’s in the tags folder, and its subdirectories, that the developers place these JSP-syntax tag extensions so that the container can find them. Again, you shouldn’t have many dealings with this folder.

Examining the tlds Folder

The tlds folder contains the configuration files for traditional Java-coded tag libraries. Each configuration file maps tag names to their implementation class so that the container can recognize which class to invoke when it comes across the tag. These configuration files are TLDs and have a .tld extension. The configuration of a tag library is the territory of developers and designers so you won’t have many dealings with them.