• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JSF url pattern

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,


This may be simple, but i am always confused with why the jsp pages when launched have a url pattern that ends with *.faces or has a /faces/* ??

Example:
http://localhost:9080/MUW/first.faces
(or)
http://localhost:9080/MUW/faces/first.jsp

The context root of the web project is MUW and the first.jsp file is placed in directly under webcontent folder. What causes the url to mask the jsp to faces?


 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
I child proofed my house but they still get in. Distract them with this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic