Exactly, that's the point. ;-)
I must admit, I never tried it with JSP, but with *.xhtml it works fine. The
reason I do this for xhtml files is that they don't throw an exception when
acccessed directly, but just send the source code (with tags) back to the
client, giving potential hackers insight into the source code. So you have
to block xhtml requests.
If technically possible, doing the same for JSP also makes sense to me.
After all, nobody likes to see a stack trace in their browser.
2008/10/24 Ryan Lubke <Ryan.Lubke_at_sun.com>
> Jan-Kees van Andel wrote:
>
>> An easy way to fix this problem in the future is using *.jsp as extension
>> (or *.xhtml when you use Facelets). This way, the FacesServlet always
>> intercepts your request to the JSP/xhtml resource.
>>
> I think you should be careful with mapping *.jsp to the FacesServlet.
> Seems like that would override the container's mapping for JSP files.
>
>
>> You get some security for free since nobody can access a JSP directly
>> (like many developers did with Struts by placing their JSP's inside WEB-INF)
>> and nobody can see that you're using JSF when looking at the URL (security
>> by obscurity).
>>
>> Regards,
>>
>> Jan-Kees
>>
>>
>> 2008/10/24 Ralph Bunker <rbunker_at_lisco.com <mailto:rbunker_at_lisco.com>>
>>
>>
>> Hi Ryan,
>> That was it. Thank you very much!
>> --ralph
>>
>>
>> At 06:23 PM 10/23/2008, you wrote:
>>
>> Ralph Bunker wrote:
>>
>> If this is not the right place to post this, please let me
>> know a better place.
>>
>> I am preparing to teach JSF and want to be able to tell my
>> students that FacesServlet is "just" a Servlet. To
>> convince myself of that, I created a new Web Application
>> project in NetBeans 6.1 and did not add the JSF libraries
>> to it. I then downloaded the 1.2_09 Mojarra build from
>> https://javaserverfaces.dev.java.net/download.html and
>> copied all packages and config files to my NetBeans
>> project. I created a small page with just a <f:view/> tag
>> and ran that page.
>>
>> I got it to compile and ConfigListener.contextInitialized
>> and FacesServlet.init appear to run correctly on thread
>> Thread[httpWorkerThread-4848-0,10,Grizzly]. In particular,
>> FacesContext.setInstance() is called before any call
>> FacesContext.getInstance() so that getInstance never
>> returns null.
>>
>> The FacesContext ThreadLocal will be populated by the
>> FacesServlet when the request is processed by the FacesServlet.
>>
>> If the ViewTag is stating that no FacesContext can be found,
>> this indicats your request isn't going through the FacesServlet.
>>
>> Example:
>>
>> FacesServlet is mapped to /faces/*
>>
>> Request: http://localhost:8080/testapp/test.jsp -> Fails with
>> FacesContext not found
>> Request: http://localhost:8080/testapp/faces/test.jsp ->
>> works as the request includes the FacesServlet in the path
>>
>> FacesServlet is mapped to *.jsf
>>
>> Request: http://localhost:8080/testapp/test.jsp -> Fails with
>> FacesContext not found
>> Request: http://localhost:8080/testapp/test.jsf -> works as
>> the request invokes the extension mapping for the FacesServlet
>>
>>
>>
>> However, when
>> com.sun.faces.taglib.jsf_core.ViewTag.setJspId is called
>> (it is running on thread
>> Thread[httpSSLWorkerThread-8080-1,10,Grizzly]), it calls
>> getFacesContext which calls FacesServlet.getInstance()
>> *before any call to FacesServlet.setInstance() on that
>> thread *and an "java.lang.RuntimeException: Cannot find
>> FacesContext" exception is thrown because getInstance
>> returns null.
>>
>> My question is who is supposed to call
>> FacesServlet.setInstance() on the ViewTag thread?
>>
>> Any suggestions will be really appreciated.
>>
>> thanks,
>>
>> --ralph---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> dev-unsubscribe_at_javaserverfaces.dev.java.net
>> <mailto:dev-unsubscribe_at_javaserverfaces.dev.java.net> For
>> additional commands, e-mail:
>> dev-help_at_javaserverfaces.dev.java.net
>> <mailto:dev-help_at_javaserverfaces.dev.java.net>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> dev-unsubscribe_at_javaserverfaces.dev.java.net
>> <mailto:dev-unsubscribe_at_javaserverfaces.dev.java.net>
>> For additional commands, e-mail:
>> dev-help_at_javaserverfaces.dev.java.net
>> <mailto:dev-help_at_javaserverfaces.dev.java.net>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail:
>> dev-unsubscribe_at_javaserverfaces.dev.java.net
>> <mailto:dev-unsubscribe_at_javaserverfaces.dev.java.net>
>> For additional commands, e-mail:
>> dev-help_at_javaserverfaces.dev.java.net
>> <mailto:dev-help_at_javaserverfaces.dev.java.net>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>