The WEB-INF directory is mandatory in a web application
© Copyright Marcus Green 2007
2.1) Construct the file and directory structure of a Web Application that may contain
And how to protect resource files from HTTP access
The webapps directory is the location for the files for all web applications. Anything above this is specific to the application server and if for running Tomcat that means the tomcat executables, log files configuration and whatever else it needs. The webapps directory contains the directories representing whatever web applications the system runs. By default this includes the ROOT default application and in the case of Tomcat a sequence of sample applications such as jsp and servlet samples.
The J2EE standard prescribes a directory structure for web applications that controls both where files should reside and what visibility they will have from the perspective of the visiting web browser. It is likely that you have experienced this when attempting to load servlets as you cannot see the available servlets in the WEB-INF/classes directory. A visiting web browser is unable to directly view any resources above the web app directory. Thus with Apache Tomcat a web application called myapp might be stored under
\tomcat\webapps\myapp and must contain at least the WEB-INF.directory
Any files above the myapp directory or in the WEB-INF directory cannot be directly seen from a visiting web browser and
If you have ever set up the Apache http server the concept of a document root will be familiar. If not bear with me, and rememer that the document root could as easily be referred to as the application root. When you create a new web application you need a directory under the Tomcat webapps directory. This will act as the root for that application. Thus if I was to create a web application called chapter2 to show the sample code from this chapter I could create a directory called chapter2 under the webapps directory. If I then access Tomcat with the URL
http://localhost:8080/chapter2
By default I could access any files directly in the chapter2 directory. Note I said directly in the chapter2 directory because anything under the WEB-INF directory is hidden from direct HTTP access unless configured otherwise. The exam expects you to know where you can keep JSP and static files and you can if you want simply keep them in the document root directory. It is a useful convention that you store static files in sensibly named directories. Thus for example you might store your photos in a jpg format in a directory called images and your logos in gif format in a directory called logos. Thus you might end up with a directory structure as follows.
C:\appps\tomcat5.4\webapps\chapter2 \images \logos \htfiles \jsp \WEB-INF \classes \lib
There was some discussion at the excellent JavaRanch forums as to if the WEB-INF directory is mandatory for a web application. JSP pages will execute without a WEB-INF directory but a web application is more than just JSP pages. Thus for exam purposes you should consider WEB-INF mandatory.
|
|
The WEB-INF directory is mandatory in a web application |
Although WEB-INF is directly under the document root, it should be considered to be out of the accessible path and is invisible to a visiting web browser. The WEB-INF directory is where the deployment descriptor file (WEB.XML) is stored and the following three directories. Note that the name of the deployment descriptor is case sensitive even under windows. WEB.XML is not the same as web.xml.
|
|
Contents of the WEB-INF are not directly acceible from a web browser |
Any servlets or classes that have not been provided in a jar file get stored in this directory. If you want to be taken seriously you will not use the default package but will create a directory structure that represents your package structure according to your Internet domain. Because Internet domains are guaranteed to be globally unique this ensures there is no chance of a namesspace clash. Thus if I have a class called Util there will be no clash between com.sun.java.Util and my own com.examulator.Util class.
All jar files should be placed in this directory. This includes any jdbc database driver contained in a jar file. You can also include servlets in a jar in this directory as at runtime the container adds this directory to the classpath in the same way as the classes directory is added. The lib directory is also the location for any jarred taglibs you might use.
Note that during development and learning it is very easy to overlook the deployment of jar files. Because your application may run fine outside a jar it is tempting to simply execute your code and forget about how it can be wrapped in a jar. I strongly recommend that you spend some time wrapping up your own sample code into jar files and deploy within applications to understand the implications of the directory structure within jars such as the use of the META-INF directory for complete deployable web applications.
In a similar way that Servlets have an associated XML file for configuration in the deployment descriptor (WEB.XML), custom tag libraries ( taglibs) have a descriptor whose extension is *.tld . These can go in in WEB-INF or any directory underneath. There is a convention to put them in the WEB-INF/tld directory.
The META-INF directory is only relevant for use within a war file, where it is mandatory and performs a role very similar to the WEB-INF directory of a non jarred web application. If you create a META-INF directory within your application root the contents will not be directly visible from a visiting web browser.
|
|
The META-INF directory is mandatory in a war file |
However because the META-INF directory only has relevance for war files it should not be present in a production (non war) environment and it is common practice to only create it for the purpose of generating the directory structure for a war file. To quote directly from the specification “its contents are visible to servlet code via the getResource and getResourceAsStream calls on the ServletContext.”
Other sources
Deploying web applications to Tomcat by James Goodwill
http://www.onjava.com/pub/a/onjava/2001/04/19/tomcat.html?page=2
This objective according to Mikalai Zaikin
http://java.boot.by/wcd-guide/ch02.html