• 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Bear Bibeault
  • Knute Snortum
  • Liutauras Vilda
  • Tim Cooke
  • Devaka Cooray
  • Paul Clapham
Saloon Keepers:
  • Tim Moores
  • Frits Walraven
  • Ron McLeod
  • Ganesh Patekar
  • salvin francis
  • Tim Holloway
  • Carey Brown
  • Stephan van Hulst

what url to use?  RSS feed

Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a JSF Simple Login Applicationfrom roseindia...


here is the web.xml for mapping...

<servlet-name>Faces Servlet</servlet-name>
<load-on-startup> 1 </load-on-startup>

<!-- Faces Servlet Mapping -->
<servlet-name>Faces Servlet</servlet-name>

one would think ....the usual stuff..

after making a war file, I deploy it to the tomcat7 server...

I tried accessing with url: http://localhost:8080/hello/login.jsp (here, the app name is called "hello" ..it doesn't matter what I called)

I am getting:
root cause
java.lang.RuntimeException: Cannot find FacesContext

and the message:

org.apache.jasper.JasperException: An exception occurred processing JSP page /login.jsp at line 5

2: <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
3: <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
5: <f:view>
6: <html>
7: <head><title>JSF Simple Login Example</title></head>

can anybody help me which url to use for invoking the web app and the suggest any setting for the web.xml mapping??

Ranch Hand
Posts: 200
Eclipse IDE Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Look in your web.xml. I took a look at the one on the site you linked to, so I assume you're using their web.xml.

You're mapping the Faces Servlet:

So your url should match that pattern in order to tell the Faces Servlet to handle the request.


Note the use of "jsf" instead of "jsp"
tun lynn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
first of all, thanks for taking time to look at it and replying to me...

yes, I did try that as well, in fact, I tried like
1) /*
2) *.jsp
3) *.jsf
4) /faces/*....etc in my web.xml

and my url would look something like

http://localhost:8080:/hello/faces/login.jsp (or) jsf...
but sor some reason it still doesn't work...

something wrong in the url-pattern (in web.xml) & the way I am invoking the application??...
Posts: 20125
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, some would say that your first mistake was in employing RoseIndia, but that's just mean. RoseIndia used to be an excellent resource. It just happens to have gone dramatically downhill is all.

Myself, I'd normally go on a rant about why coding your own logins instead of using the J2EE security system is a bad idea, but you have deeper issues to resolve, first.

You don't want "/*" as a URL pattern for any servlet, whether it's the FacesServlet or a completely non-JSF app. The URL pattern is going to match ALL incoming URLs, and that includes the image URLs, the JavaScript URLs, and so forth. You don't want them running through the FacesServlet, because it cannot handle them. You only want JSF view requests and postbacks to go through the FacesServlet.

Thus, a lot of people like to use the URL pattern "/faces/*", but I prefer "*.jsf", myself.

Your biggest problem - aside from the fact that you're using the old outdated JSP tag form of JSF View Definition is that you're making the common mistake of confusing resource paths and URLs.

Resource paths are relative file paths within a WAR. URLS have the same basic syntax, but they're simply locator strings that are decoded and applied by the logic in the web application.

Clients cannot directly request resources. They can only make URL requests. The logic in the webapp receives the URL request, decodes it, and often (not always) uses that information to copy out one or more resources to the HTTP response output stream. There's a default servlet that's part of the webapp server which can take things like image file URLs such as "http://myhost:8080/myapp/images/pic1.jpg", convert it to the resource path "/images/pic1.jpg" and serve up the resource located at that place in the WAR. Likewise, the default processor will take URLs that end with ".jsp", look for a corresponding JSP resource and compile and execute the JSP file.

For more complex matters like JSF, the FacesServlet intercepts matching URLs. In the case where the FacesServlet URL pattern is "*.jsf", the URL is converted from something like "http://myhost:8080/myapp/facesview.jsf" into a resource path of "/facesview.jsp". The FacesServlet then reads /facesview.jsp, digests it to produce a JSF component tree it, runs through the JSF lifecycle, and uses the updated component tree to generate the HTML that gets sent back to the client. In JSF2 and enhanced JSF1 webapps, an additional subsystem may be employed that looks to see if there's a resource named "/facesview.xhtml" and if there is, it gets digested and processed by the FacesServlet which then employs the additional enhancements that the Facelets subsystem adds.

The FacesContext is not a "permanent" object. It will not exist unless the FacesServlet is actively processing a request and each request gets a FacesContext created just for its own use. Once the request has been processed, that FacesContext is destroyed. If you make a non-JSF URL request, for example "http://myhost:8080/myapp/facesview.jsp", that URL won't match the "*.jsf" URL filter and won't be routed to the FacesServlet, so a FacesContext won't be created.
Listen. That's my theme music. That's how I know I'm a super hero. That, and this tiny ad told me:
Programmatically Create PDF Using Free Spire.PDF with Java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!