Q:	Q: If you can’t serve content from WEB-INF or META-INF, what’s the point of putting pages there??!!
A:	A: Think about that. You have Java classes and class members with package-level (default) access, right? These are classes and members not available to the “public”, but meant for internal use by other classes and members that are publicly exposed. It’s the same way for these non-accessible static content and JSPs. By putting them under WEB-INF (or, with a WAR file, META-INF), you’re protecting them from any direct access, while still allowing other parts of the web app to use them. You might, for example, want to forward to or include a file while making sure that no client can directly request it. Chances are, if you want to protect a resource from direct access, you’ll use WEB-INF and not META-INF, but for the exam, you have to know that the rules apply to both.
Q:	Q: What about a META-INF directory inside a JAR file inside WEB-INF/lib? Does that have the same protection as META-INF inside the WAR file?
A:	A: Well... yes. But the fact that the content is in META-INF is not the point. In this case, you’re talking about a JAR file inside the lib directory inside WEB-INF. And anything in WEB-INF is protected from direct access! So, it doesn’t matter where under WEB-INF the content is, it’s still protected. When we say that META-INF is protected, we’re really talking about META-INF inside a WAR file, because the META-INF inside WEB-INF/lib JAR files is always protected anyway by virtue of being under WEB-INF.
Q:	Q: On an earlier page you mentioned putting library dependencies in the META-INF/MANIFEST.MF file. Are you required to do that? Isn’t everything in the WEB-INF/lib jar files and the WEB-INF/classes directory automatically on the classpath for this application?
A:	A: Yes, classes you deploy in/with the web app, by using the WEB-INF/classes directory or a JAR in WEB-INF/ lib, are available and you don’t have to do or say anything. They just work. But... you might have a Container with optional packages on its classpath, and maybe you’re depending on some of those packages. Or maybe you’re depending on a particular version of a library! The MANIFEST.MF file gives you a place to tell the Container about the optional libraries you must have access to. If the Container can’t provide them, it won’t let you successfully deploy the application. Which is a lot better than if you deploy and then find out later, at request time, when you get some horrible (or worse—subtle) runtime error.
Q:	Q: How does the Container access the content inside JAR files in WEB-INF/lib?
A:	A: The Container automatically puts the JAR file into its classpath, so classes for servlets, listeners, beans, etc. are available exactly as they are if you put the classes (in their correct package directory structure, of course) within the WEB-INF/classes directory. In other words, it doesn’t matter whether the classes are in or out of a JAR as long as they’re in the right locations. Keep in mind, though, that the Container will always look for classes in the WEB-INF/classes directory before it looks inside JAR files in WEB-INF/lib.
Q:	Q: OK, that explains class files, but what about other kinds of files? What if I need to access a text file that’s deployed in a JAR in WEB-INF/lib?
A:	A: This is different. If your web app code needs direct access to a resource (text file, JPEG, etc.) that’s inside a JAR, you need to use the getResource() or getResourceAs Stream() methods of the classloader—this is just plain old J2SE, not specific to servlets. Now, you might recognize those two methods (getResource() and getResourceAsStream()), because they exist also in the ServletContext API. The difference is, the methods inside ServletContext work only for resources within the web app that are not deployed within a JAR file. (For the exam, you need to know that you can use the standard J2SE mechanism for getting resources from JAR files, but you do not need to know any details.)