In Tomcat, URLs that do not have a mapping in web.xml are routed to a "default servlet" that is built into the Tomcat server itself. Other J(2)EE containers might do it differently, though.
The default servlet analyzes the incoming URL and attempts to resolve it to a resource path in the webapp's WAR. If if finds a simple file resource, it opens that resource and copies it out to the response stream. If it finds a directory resource, it constructs an HTML page that contains a directory listing. If it cannot find the resource at all, it generates a "404 - Resource not found" error page - or, if web.xml defines a custom 404 page, it will use that definition.
And if the resource URL ends with JSP, a check is made to see if a class with the corresponding name exists, and if not, it attempts to locate the corresponding JSP resource, which it will then route to the Jasper JSP-to-Java translator, and then to the javac compiler (or some equivalent) to create the class. The exact locations of the interim
Java and class files is known, but shouldn't be exploited, since they're not defined to the
J2EE standard and may change location, format, and use in other versions of Tomcat or non-Tomcat J(2)EE servers.
Note also that the login and loginfail pages as well as several other resources defined in web.xml but presented by Tomcat may be JSPs. A similar mechanism applies there, even though there are no explicit URLs associated with those resources (for example, attempting to make an explicit request to a login JSP will not function properly, because only Tomcat internal security requests can set up the required context).
But whether you agree with Bear's Rule that JSPs should NEVER be explicitly requested or not, it's still not a good idea to meddle with the standard behavior, so leave the "*.jsp" route out of your web.xml.