This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
I have been using JSF 1.2 and want to start with JSF 2.0, which I believe is much better. There are a number of differences, one of which is that the web files are .xhtml rather than .jsp. In fact I want .html as I plan to be HTML 5 compliant.
Anyway, I got the book Core JavaServer Faces 3rd Ed., which deals with JSF 2.0, and I'm going through the examples. In converting the files for the first example in the book to a war file and putting it into the autodeploy folder of Glassfish it works correctly. That is all fine and good, but I want to be able to create applications using Eclipse, and have been unable to get it to work with Eclipse.
This is what I have done:
1) create a dynamic web project called ch01-login for JSF 2.0.
2) Copied the web file welcome.xhtml to the web folder. For those who do not have the book the code is:
3) Copied the second web file index.xhtml to the same folder:
4) Copied the Java file to the scr/com/corejsf folder:
Note that Eclipse recommended that I put in a final long in that class.
Eclipse had generated the two xml files in the web folder, namely for web.xml we have:
and for faces.config.xml we have:
I have not edited these xml files which were generated by Eclipse.
5) The final step is to publish this to the Glassfish server and get it started. The server starts up OK and the admin console indicated that ch01-login is deployed, and in the log file are the messages:
INFO: WEB0671: Loading application [ch01-login] at [/ch01-login]
INFO: ch01-login was successfully deployed in 11,833 milliseconds.
So everything seems to be OK. However, in pointing a browser to http://localhost:8080/ch01-login/ I just get the 404 message that the application is not available. I've tried various combinations of ch01-login.faces, faces/ch01.login etc. but can't get the application displayed. I presume this has something to do with <url-pattern>/faces/*</url-pattern> in the web.xml file, but I'm unable to figure out what is happening, so would most appreciate some help with this.
Once I get past this step I hope to be able to move forward with JSF 2.0, but I really need to know what is happening here, so would be most grateful of some kind help.
Also your web.xml doesn't appear to have a <welcome-file-list>
I've also found that having an index.html with immediately forwards to index.xhtml seems to work better
(esp. with mojarra). I don't have my other development box available not, but as a caveat,
I am using JBoss 4.3 EAP and JBoss 6 EAP from within Eclipse.
Joined: Dec 12, 2007
Yes, many thanks, that indeed works! Thanks very much for your really quick response!
However, on filling in the boxes and clicking the "login" button I get a 500 error with the following messages:
I don't care how many JSF books include "login pages" as sample code, user-written login/security systems are a bad idea.J2EE has a standard security framework that should be handling logins for most applications. I've never seen a user-designed security system that was even half secure. And I've seen a lot of them, including more than my share of financial systems and even a military app or 2.
One thing to be aware of is that the "xhtml" View Definition Language (a/k/a View Template Language) is not the same thing as "xhtml" in the w3c sense. JSF Facelets VDL conforms to the same XML rules as xhtml, but it's comprised of JSF constructs, not HTML constructs (well, actually people tend to mix them together, but I don't recommend that).
JSF will compile the xhtml files to product a View Component Tree, which is a 2-dimensional data tree used to process incoming forms and hold data for the response renderer. The standard JSF renderer will then use this tree to generate and send HTML (usually. You can also plug in alternate output format renderers).
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Dec 12, 2007
Many thanks for your tip about security, and before I get a full JSF 2.0 application running online, then indeed that is something I will need to consider. In the mean time I'm just practicing getting up to speed with JSF 2.0, and in particular have never used annotations before, which I have to get familiar with.
I made three changes as folows:
1) As previously advised by William, I added to the web.xml file a <welcome-file-list> for index.xhtml.
For some reason Eclipse sets up the default web.xml for (1) and (2) in a manner that is not very convenient.
3) In the Java class I commented out @Named("user") and uncommented @ManagedBean(name="user"), as well as uncommenting the alternative imports.
Previously when clicking "Login" it could not find welcome.xhtml, but now it works correctly. I don't really know why that is the case, but it does. As I'm completely new to JSF 2.0 and annotations, this is something I'm in the process of finding out.
When I was last in France in 2008 I wrote the original application using JSF 1.2 by "hand" without Eclipse or another IDE such as Netbeans. It's still online at:
Eclipse is my assistant, not my master. I do most of my project configuration work by hand. Usually I either generate the base project from a Maven archetype or cloning an existing project. I have found the Eclipse "web project" to be more trouble than it's worth, and what I could say about WTP and its treatment of Tomcat would peel the pixels off your monitor.
Annotations are useful, but not essential. In cases where the goal is simply to move a project to JSF2 as fast as possible, you can dispense with them and continue using the definitions in faces-config.xml. In fact, faces-config.xml is the final authority and will override conflicting annotations so that you can recycle classes without making source code changes.
Incidentally, the default name for a JSF backing bean is synthesized by taking the first letter of its classname and folding to lowercase. So for example "PersonBean" gets the default name of "personBean". You only have to explicitly supply a name if you want to use some other name. Or if you just want to.