I have read a few chapters from the first edition but have not bought the new edition yet as I not have time to read it yet. But I have been waiting for it as it describes the new and current JSF syntax. And I also hope that the code examples are easier to get up and running if they are written for the new libraries available on the net.
Anyway, here is a little question I feel not understand fully yet ... Why do I have to have a page that forwards so the first page (index page, main page) for the JSF application? What architectural thing prevents me from have the index page for the JSF application configured as the welcome page for the web application? Provided that the Faces servlet is configured to handle that page of course.
Truly agile Java application developer with Extreme Programming and high quality craftsmanship
Not sure, But I guess this was common as there was an old bug in Tomcat that didn't accept a servlet in the welcome files list, however starting from tomcat 5 this issue is fixed. See this old thread Servlet-welcome-file-list
Hum, it actually worked! I am sure I have tried something like that before without getting it to work but I must have made something wrong. And I like it better this way without more pages than necessary.
Thanks! And I'll promise I will buy your book about JSF 2.0 soon! I learnt a lot from the first edition and have been waiting for this new edition. I particularly appreciated that you explained that much about the framework behind the scenes.
depends upon our requirement, we can use or avoid index.jsp.
but the question is "Why do I need a forward page to the JSF index page?"
if you are using index.jsp for sure in your application, then definitely you need forward page as to stop our application entering into the JSF life cycle before displaying the initial page of the application.
For the most part, any page request made directly by the container doesn't work well with a servlet-dispatched framework such as JSF or Struts. This is especially true of the login JSPs, but error JSPs and other pages of the same sort also have problems. The reason appears to be that the container is invoking the page directly instead of via the normal network channel and not all the necessary context is available. Login pages also have the problem that they're injected as a shunt to a normal page request, so not only does the login page have to be invoked, but the original page request has to be preserved, since once login succeeds, control is re-routed back to where the need for login was detected.
Customer surveys are for companies who didn't pay proper attention to begin with.
Marco Ehrentreich wrote:This sounds much like a bug or maybe a missing piece in the specification to me. Is this specific to a Servlet container or Servlet API or is it a known problem for all well-known containers?
As far as I'm aware, it's not so much a bug as an acknowledgement that pages presented on behalf of the appserver itself don't get the full resource set that pages requested via http(s) to the application would. In the case of login pages, that's as much for security reasons as anything else, but I can think of several other reasons why this would be desirable behaviour.
I've been digging around in the Sun official docs, and most of the formal specs seem mute on the whole area, but that's given me an excuse to get an updated set of docs.