You are confusing URLS with resource paths. They look a lot alike, but they're actually totally different.
A resource path is something like "/cakes/editCake.xhtml". That's the relative pathname of the editCake.xtml file, which is a Facelets View template.
Webservers don't serve up resources directly, however. They serve up responses to URLs.
A URL can be any syntactically valid URL
string. What you get back from it is entirely at the webapp's discretion. With a little help from the appserver.
When a user submits the URL "http://www.mycompany.com:8080/gourmetshop/cakes/editCake.jsf", the following things happen:
1. Their browser looks up the domain name "www.mycompany.com" to get the corresponding IP address.
2. The browser opens a tcp/ip request stream aimed at the IP address, and socket number 8080, which is where the webapp server is (hopefully!) listening for HTTP requests.
3. The webapp server receives the request and parses the URL. It sees that the URL context "/gourmetshop" is assigned to the Gourmet Shop web application. URL contexts can have 0-n levels in them, but 1 is usually most convenient. 0 (root) is also popular, but it makes it hard to host multiple webapps.
4. Now that the appserver knows which webapp to target, it looks up the digested web.xml for the gourmet shop webapp. It checks to see if the URL is secured, and handles login and access control, if necessary. It also checks to see what URL patterns are registered in the webapp. It sees that URLs ending in ".xhtml" are to be routed to the FacesServlet via the Facelets filter and passes the request onto the FacesServlet.
5. The FacesServlet parses the URL. Essentially, this means that it strips off the hostname/port/appcontext part, giving "/cakes/editCake.jsf". It also applies the Facelets URL-to-resourcepath translation, giving "/cakes/editCake.xhtml" as the resource pathname. This resource is then opened, read, and used to construct the
JSF ViewContext, which holds the abstract definition of the editCake view.
In addition to URL processing done explicitly by the webapp, there are a couple of default processors provided by the webapp server itself. There are 2 of them commonly encountered:
A) The JSP processor. It takes a URL ending in ".jsp" but not claimed by the webapp, opens up the resource whose pathname matches, compiles the JSP file into a
servlet class, then dispatches the URL to that servlet. The complied servlet is cached, so it doesn't have to be re-compiled every time.
B) The "Aww ^%$, just copy it!" processor. This is the one that fools so many people into thinking that web servers are file servers, when they actually aren't. When none of the above rules can handle a URL, the URL is translated to its corresponding resource pathname, the resource is opened and the resource is then copied to the HttpResponseOutput stream. Which is how images, css, javascript and other generic client-side resource get served up. Or, if the resource for that path cannot be found or read, a "404" error response is returned by the server.