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.
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.
Customer surveys are for companies who didn't pay proper attention to begin with.