Directory structure of Java web applications

I have read the NEWS that SUN and the others involved in the Servlet and JSP specifications, companies have laid great stress on the fact that at the end of a real container-platform standard is created. Thanks to the thorough work of the group specification, it is now really possible to migrate web applications easily from one container to another. But now I am here to get more information about the directory structure of Java web applications. Hope that there would be someone who would be knowing about this topic. I am expecting some quick responses form your side.

The so-called "Document Root" is the root of a Web application. Below this root are the HTML and JSP files, images, CSS files etc. It can also be created any subdirectories. In addition, there are two directories, "WEB-INF" and "META-INF", which are of particular importance and must follow certain rules. The directory "WEB-INF" is mandatory for any Web application, "META-INF" is however available only in rather exceptional cases. A typical list might look like this example:

http://img5.imageshack.us/img5/5663/img11t.png

Here, for example, there are the folders "css","js" and "pics" for CSS, JavaScript and image files. HTML and JSP files are already here, for example, directly into the root of the directory "example" and are in "WEB-INF" we find the structure described below. For Tomcat, the depicted directory below the "$ TOMCAT_HOME / webapps'd lie."

The directory "WEB-INF" under the "Document Root" is a special directory. It contains configuration files and the required libraries and Java classes to use. As this are all critical files, the servlet specification requires mandatory before for security reasons, files and directories under "WEB-INF" can never be requested directly by a client. One can but there certainly use HTML and JSP pages when they are called by a servlet from using Request Forwarding. This is common practice even in applications that use this model to prevent accidental calls to the JSPs without the much needed request attributes.

Libraries that are available as jar files come directly into the "WEB-INF/lib" subdirectory. Libraries or classes of applications that exist only in an unpacked directory structure must lie below the directory "WEB-INF/classes". It applies here as usual with Java, a package that classes must be below a corresponding directory name. So for example the class "WebUtil" the package "org.jsptutorial.util" in the "WEB-INF/classes/org/jsptutorial/util /". In the "WEB-INF/classes" directory in addition are also all files that need to be in the classpath, ie in particular properties files or xml configuration files. Since the JSP 2.0 specification, there is a further subdirectory WEB-INF/tags ", the tag-file contains. Tag files are new elements of the JSP specification, create tag libraries simplify (to see the chapter on tag libraries ). Tag files are either directly in the "WEB-INF/tags" directory or in subdirectories below this one.

You should also know about the META-INF which is an important part of directory structure of Java web applications. This list really only exists in the unpacked WAR file. But whether directly or created or prepared under an unpacked WAR file, there is always that all files and directories under this directory are as nonexistent. Each call to one of these files causes a "Page Not Found" error (status code 404). This directory is in creating WAR files automatically from the jar tool within the WAR files created yourself. It contains only information necessary for dealing with WAR files from the Java tools are even needed.

WAR files are nothing really special. You are in essence merely ordinary JAR files that must however have a different Extrension. And they include not just a class hierarchy, a library, as usual in JAR files, but a fully packed Web Directory. This means that all files in the "Document Root" will be packaged in a WAR file. Suppose we wanted to pack our "example" Web Application. Then we would first go to the appropriate directory and type the following command:

"jar cfv example.war ." or "jar cfv example.war -C pathToDir."

The condition that the jar-tool of the JDK in the path of the executable files are located. Otherwise, the tool over its full path will be called. The jar tool writes the relative directory name of the packed files in the file. Therefore, one must either go to the root directory of the Web application to gripping, or communicated with "C pathToDir" the tool, in which directory it should go to the packing.

The advantage of war-files is that they simplify the deployment of extreme and keep the directory structure of the server clean. The server is responsible for ensuring that no bodies of previous deployments remain. In addition, it shall first be easily deployed in a test environment before the WAR file is deployed after the successful completion of the tests into the production system. In clustered environments, the cluster itself may assume the propagation deployed WAR files to all other nodes involved.

A WAR file is completely independent of the container. Container-specific additions or extensions to an application (for example, the definition of security handling) must be undertaken outside the web application directory. This would allow a developer to work locally with a different container than on the production system is used. Only the versions of supported JSP and Servlet specifications must match. But be careful: You should always keep at least the test environment and the productive environment to largely the same; we want to do not go on live later unpleasant surprises. If we have no specific test environment, so you absolutely have a clean versioning was the make files to possibly switch back quickly to an old stable version can.