views:

90

answers:

1

Hi folks, I'm here facing a problem with a Java web project. The project I'm working on has been made with standard jsp mixed up with jsf pages. The main page of the application, called main.jsp is a standard jsp page that needs to access a managed bean with session scope created within a servlet filter used to check the authentication of the user. In my web.xml I have set up that faces engine must respond to .jsf and /faces/* request

  <filter-mapping>
    <filter-name>extensionsFilter</filter-name>
    <url-pattern>*.jsf</url-pattern>
  </filter-mapping>
  <filter-mapping>
    <filter-name>extensionsFilter</filter-name>
    <url-pattern>/faces/*</url-pattern>
  </filter-mapping>

If I open my application with http//myserver/myapp/faces/main.jsp everything works fine. If I open my application with http://myserver/myapp/main.jsp I'll get an error beacause the faces context hasn't been created yet. Neither setting the welcome page nor setting the apache redirect I'm able to let the application open the right page (main.jsp within the faces context) when the users simply type h**p://myserver/myapp on their browsers: that's beacause the page /faces/main.jsp phisically doesn't exist.

I guess there could be 2 solution: being able to let the faces context start even outside the /faces/* pattern, or find a way to let tomcat redirect to /faces/main.jsp even if the page doesn't exist... but I failed everything I tried.

Anyone can help? Thanks in advance

+1  A: 

Just do not open your application by http://myserver/myapp/main.jsp, but rather by http://myserver/myapp/faces/main.jsp or (more preferred) http://myserver/myapp/main.jsf.

If your whole concern is that the endusers shouldn't be able to access the JSP pages outside the url-pattern of the FacesServlet (else this question would not make much sense ;) ), then go for the *.jsf pattern and add a security-constraint with an empty auth-constraint on *.jsp pattern to the web.xml. This should take care that the endusers won't be able to request *.jsp URL's directly.

<security-constraint>
    <display-name>Restrict direct access to JSP files</display-name>
    <web-resource-collection>
        <web-resource-name>JSP files</web-resource-name>
        <url-pattern>*.jsp</url-pattern>
    </web-resource-collection>
    <auth-constraint />
</security-constraint> 

This is not directly possible when you're using /faces/* mapping. I'd get rid of it in web.xml as well.

Further, to cover endusers who are typing http://myserver/myapp, then just define main.jsf as welcome-file in web.xml and get rid of the other definied welcome files. In Tomcat (and possibly also other servletcontainers) you'll however need to create an empty file with exactly that name to fool the server that the file exists on disk.

BalusC
I'm trying to follow your hint but I miss something: just renaming main.jsp in main.jsf isn't enough to make it work; tomcat respond with the main.jsf content as plain-text, sending the code of the page.What am I supposed to do to make the page works the same way it works when I call /faces/main.jsp ?
themarcuz
You need to rename it in URL only, not the actual file. The actual file extension should still be `.jsp`. The `FacesServlet` will automatically locate the right JSP file. The extension should be kept because it will trigger the servletcontainer's builtin `JspServlet` to parse the JSP file.
BalusC
I can't get it to work :( If I understood what you said, without modify anything just calling http://myserver/myapp/main.jsf the application should create the faces context and respond with the main.jsp sandard jsp page... is that right? 'cause it doesn't work
themarcuz
If the `FacesServlet` is mapped on `*.jsf` and the *actual* page is named `main.jsp`, then it should indeed just work without any changes. To nail the cause better down, you should in future tell "doesn't work" in more detail. Try to elaborate in developer's perspective, not in "dumb enduser"'s perspective. What happens? What happens not? E.g. you are seeing an error/exception (if so, which?) or you are seeing unexpected result (if so, how is it different?). Symptoms and messages tells something about the cause of the problem. You know, once the cause is *understood*, the solution is obvious.
BalusC
You're right, sorry.Anyway, it's solved...The error message was> HTTP Status 404 - /NAQ3/main.jsf> The requested resource (/NAQ3/main.jsf) is not available.I missed the right servlet-mapping for *.jsf pagesThanks for your help!
themarcuz
You're welcome.
BalusC