A Web application configuration file that describes the servlet and other application component configuration and naming conventions.
Contains all of the site's class files, including the Servlet class and the non-servlet class, which they cannot include in the. jar file.
Store the various jar files required by your web app to place the jar files that are required only in this application, such as database-driven jar files.
Source directory, according to the package name structure to place each Java file.
Database configuration file
A custom label file is stored, which is not necessarily tags, you can name your own tag library according to your preferences and habits, and when you use a custom tag file library name, you must declare the correct label vault path when using a tag file. For example: When the custom label file library name is Simpletags, when you use a label file in the Simpletags directory, you must declare the JSP file header as: <%@ taglibprefix= "tags" tagdir= "/web-inf/ Simpletags "% >.
File storage locations for the following versions of JSP 1.2. There is no specific declaration on the directory, so you can name it according to your preferences and habits. This directory is primarily for JSP 1.2 versions of the file, in order to differentiate JSP 2.0 files, usually use JSP name, of course you can also name jspoldedition.
Compared with the JSP file directory, the directory is mainly under the JSP 2.0 version of the file, of course, it can be arbitrarily named, but also to distinguish between JSP 1.2 versions of the file directory, usually named JSP2.
Equivalent to a packet, the files and directories in the directory are recognized and interpreted by the Java 2 platform to configure applications, extenders, ClassLoader, and services
MANIFEST.MF files, which are generated automatically when packaged with jars.
Reproduced below to http://blog.csdn.net/saygoodbyetoyou/article/details/9944773
Why should the request page be placed in the Meta-inf directory
point one: (more agree)
Security is not the real reason, because the JSP is to be parsed to display to the browser, even if the user knows your JSP path, it is not possible to see the JSP source through the browser, and if it is through other means to invade the server, What's the difference between Web-inf and putting it in another place???
The real reason is, for the early direct embedding of Java code JSP, is directly give the JSP path to the user access, this situation just can't put in Web-inf, and now the MVC mode, JSP is not once that contains the full logic of the JSP, And just as a template of the view layer, you have to fill in the model data to render, in order to generate a readable page, so that the template is not directly accessible to users, direct access to the word is either a bunch of blanks, or a bunch of placeholders, or even a bunch of nullpointexception, So I need to put it in the Web-inf. To add, "security problem" means "do not allow you to visit, otherwise it will be bad for me", and here is actually "do not suggest you visit, otherwise will treat you bad", should belong to the category of robustness.
put the JSP file under Web-inf, if you go directly to access this JSP is not possible, you must pass the action of the jump, so you can understand why security is high, for the user is not visible, for some for the user, can be directly accessed, such as, login, registration page, can be placed directly under the Webroot, this is based on your system needs.
by setting a filter, files placed under Webroot can also be accessed without direct access. So it's a habit to say where you put it.
Generic items are required to be hidden, allowing customers to request access rather than directly accessing JSP pages. If placed under Webroot, you must add a filter to block all access to *.jsp. As long as the comparison:
placed under the Webroot: advantages, the program structure is clear, easy to encode and maintain, disadvantage, to add filters. The
is placed under the Web-inf: advantages, no filters, disadvantages, upset the program structure, coding and maintenance trouble.
to reduce risk, you can move these paging files to the Web-inf directory. Servlet-based declarations, Web-inf are not part of a common document tree for WEB applications. Therefore, the resources under the Web-inf directory are not directly serviced by the customer. We can still use the JSP page in the Web-inf directory to provide a view to the customer, but the client cannot request access to the JSP directly. JSP stored in the Web-inf directory is more secure
Java Web project Web-inf and Meta-inf