Url pattern - Real directory vs Virtual directory

[Ali Gordon]

Consider the url-pattern:

<url-pattern> /Beer/* </url-pattern>

The web app structure is: -

webapps  
|
-->AdviceApp
   |
   -->WEB-INF
   --> {{Beer}} This can be real or virtual.

My book says that /Beer/* can be a real or a virtual directory. What is the difference between the two and how do I create a virtual directory
in tomcat ?

[Kesava Krishna]

The url-pattern element of a servlet-mapping associates a servlet with a set of URLs. When a request arrives, the container uses a simple procedure for matching the URL in the request with a url-pattern

The url-pattern specification:

A string beginning with a ‘/’ character and ending with a ‘/*’ suffix is used for path mapping.
A string beginning with a ‘*.’ prefix is used as an extension mapping.
A string containing only the ’/’ character indicates the "default" servlet of the application. In this case the servlet path is the request URI minus the context path and the path info is null.
All other strings are used for exact matches only.

All the wild cards mentioned in the url-pattern will be virtual, there is no need that they have to exist in the physical file system.

In your case if your servlet is placed in the location com.company.servlet with the name TestServlet then it's upto you how you want frame url's so that this servlet resource will be accessed.
<url-pattern> /Beer/* </url-pattern>
There is no need that directory with name Beer should exist, it's a virtual mapping to your servlet to protect from external world for direct access and map it through any virtual url's using <url-pattern>

[Tim Holloway]

A URI/URL can look a lot like a (Unix) filesystem path, but it is not. A URL is a Uniform Resource Locator. Unlike fileservers, which are obligated to use certain pre-defined standard rules for locating resources (files), a URL can be decoded and applied in any way that the web application that recieves it wants to. That can include returning a directory listing, dynamically generating a chart or PDF, or copying the contents of a server-local file to the HTTP Response output stream accompanied by suitable HTTP headers.

I can in fact, make a servlet that when passed a URL of "http://myserver/x/y/z" return file X in directory Y under directory Z, if I'm so perversely inclined.

The concept of a Virtual Directory is basically mapping some slice of a filesystem onto a URL. So, for example, "/x/y/z" might be a file z within "C:\My Computer\My Documents\randomfiles\y", just as an arbitrary example. In J2EE, this concept may further extend into files contained within a WAR, such as "/WEB-INF/data/x/y/z", even though a WAR file has no physical disk directory tree in it (since it's a single ZIP-format file).

J2EE has a default servlet whose actions are standardized. It takes over when no WEB-INF/web.xml servlet pattern matches an incoming URL and there's no JSP that matches either. In that case, the default servlet will attempt to use the WAR as a virtual directory, excepting the WEB-INF directory and its children, which are not visible for security reasons. If the URL matches a WAR "directory", then by default, the default servlet will format the list of "files" under that directory as an HTML directory listing page (Apache http server does something like that, using the Index option). If it's a file, then the file's contents will be copied to the Response output stream. If no match is found, then a "404" page is displayed. Or, if the web.xml file specifies an alternative "404" handler, it will be used.

I don't like to refer to the "files" in a WAR as "files", since in physical fact, they may not be. If they are not, then the get filesystem path HttpServletRequest method will return NULL, even though there may be a "file" of that name in the WAR. For that reason, I prefer to refer to them as resources, since even if there is no filesystem path, the HttpServletRequest getResource methods can still access them.