In this quick step-by-step video walkthrough, you'll see how to write and deploy a Hello World application for Java using the JDK, a Tomcat server, and JavaServer Faces.

The first application that most developers learn in any new language is the traditional "Hello World" application. This is a very simple application that just displays the text "Hello, world!" in some form or another. It is one of the simplest sets of code that can still be seen as an application. In this quick step-by-step video walkthrough, you'll see how to write and deploy a Hello World application for Java using the JDK, a Tomcat server, and JavaServer Faces. These steps will hold true for more complicated Web applications as well. For your convenience, a written transcription of the video follows.

Hi, I’m Cameron McKenzie. I’m the author of “Hibernate Made Easy” and “JSF Made Easy” and a number of other Java certification guides. What I wanted to do right now is just talk you through the creation of a little JSF application and of course the deployment of that application to a Tomcat Server.

I’ve been setting up my JSF environment. I’ve got the JDK 16 installed, the JAVA_HOME configured. I’ve got Tomcat in there. I’ve also downloaded a JSF implementation. I’ve even tested out a little application as well by deploying the jsf-guessNumber.war file to the webapps directory of Tomcat. What I haven’t done is I haven’t created my own application and that’s what I’d like to do right now.

Starting off, right off the root of C I’m going to create a new folder. This is going to be my application root. I’m going to call it _easyjsf. In that _easyjsf folder I am going to create a couple of subfolders. If this is going to be a Web application it has to conform to the servlet and JSP API. As such, every application has to have under its application root, a folder called WEB-INF. That WEB-INF folder contains all sorts of other salacious folders, one of which is the lib directory. Another one is the classes directory, where all compiled java code goes when Web modules are deployed to a servlet engine. I’m not actually going to compile any java code in this particular example but it is actually worthwhile just creating those folders under the WEB-INF folder.

Now the lib directory is supposed to have any .jar files that we want to link to at runtime that are specific to our Web application. Seeing that we are going to have a JSF application here we need to have a few important JSF files and JSTL files that allow JSF 1.2 to run. Now, earlier I had taken the JSF API, JSTL and standard .jar files and thrown them into the root of this JSF 1.2 folder. I’m now going to copy those and just copy those inside that lib directory. Again, that lib directory is there for your JSL modules and should have those .jar files in it so when you deploy your application the JSF implementation and the JSTL files are all available.

With that done I have to create another couple of files. Every JSF application has to have in the WEB-INF folder a special deployment descriptor called “web.xml”. (That’s pretty nasty there.) What that xml files is, is going to be pretty simple here. I want to make things as simple as possible, however, when you open up a web.xml file there is all sorts of garbage in it. If you actually have your JSF download there is a whole bunch of samples in there. If you go to your WEB-INF folder of say, the guessNumber sample, you can open up the web.xml folder and you’ll find all of this mumbo jumbo. And you’ll find a whole bunch of information about the Web module all under this <web-app> tag.

The reason I am showing you this is any time you create a Web module you have to have this sort of xml name space garbage in here and this display name and some of the context grammars you can skip over, but you’ve got to have this </web- app>. Instead of actually typing something up by hand it’s a good idea to come into one of these folders, copy the xml version,copy the Web app name space version information there, maybe even the display name element, finish it off and copy that into a file.

I’ve actually created a web.xml file of my own. As you can see I have all of the <web-app> information and the xml version and everything all copied from another file. Then I have put in another couple custom attributes. This is really the bare minimum that a JSF application needs. I got the <display-name>, it’s JSF Made Easy. I’ve also got a reference to the Faces Servlet. All requests to a JSF application are supposed to go through this thing called the “Faces Servlet” and it gets named just “Faces Servlet” in the web.xml file. It’s the key servlet that makes JSF work. How does this faces servlet get fed requests?

Any request that comes into the server that ends with .faces is associated with the Faces Servlet. You see the <servlet-mapping> entry here. That mapping maps back to that servlet name and so any request that comes in, that might be index.faces will be handled by the servlet engine. It will be sent to the Faces Servlet and essentially the JSF framework handles it.

Inside the WEB-INF folder of all of your JSF applications you have to have a web.xml file. I’m going to save that right now, save as web.xml. I just want that as a regular text document, but save as .xml not .txt. Now I’ve got my web.xml file created inside my JSF application. Now also along with this web.xml file we also need a faces-config.xml file. Now the faces-config.xml file for us is going to be pretty nascent. There is not going to be much in there.

There is just going to be the xml version tag. This sort of preamble that says we do have a Faces application and then the end tag. Again, all of this stuff here you can type it out by hand but you’re going to make a mistake. Just go into one of the examples you have and find faces-config.xml, just find that faces, make sure it’s version 1.2 there and just copy that out. Copy the end tag, throw it into a file like I’ve done right here and save this as “faces-config.xml” just as a text document, click save. Even go in [the WEB-INF folder] and make sure there is no .txt or extra .xml extension that notepad or word pad or text editor may have placed on it.

Every Web application that we have—oh there it is - there's faces-config.txt – it has to be xml. See there you go; it didn’t even work for me. There is my web.xml, my facecs-config.xml, that all looks good. The next thing that I need is a nice little JSP page to do some display. I’ve created a sample JSP page. I’ll allow you to take a look at it right here. There is nothing too exciting about this particular JSP, JavaServer Page. It’s got a little taglib directive on top here saying that we’re going to reference some tags in the JSF core library. The core library standard has the f prefix associated with it.

The only thing I’m really going to use here is just this <f:view> tag. Everything in a JSF page should be embedded within an f:view tag. So we start the f:view at the beginning of the page, end it at the end of the page and all of our HTML and any other JSF tags, it’s all going to go in the middle there. I do that, I have the tag lib; I have the actual tag there and then I have a little title. The body says “Hello World,” Nothing too exciting there and then I save this. I’m going to save that as index.jsp not "jsf", "jsp". I’m going to save it as a text document. It’s putting that little txt extension on it. We don’t want that. We want to change that. And now I actually have my index.jsp file right there in the root of the application.

To develop your own JSF applications you have to follow the folder structure of any servlet and JSP application. That means having an application root, having a WEB-INF folder, having a web.xml file and of course having a lib directory with any .jar files you need to link to at run time. And also for a Faces application we need the faces-config.xml file along with the web.xml file in the WEB-INF folder.

That’s the basics of creating a simple JSF application but of course creating it is only one part of the process. The next thing we want to do is actually package this up and deploy it. So to package up a JSF application what we do is we compress the contents of that _easyJSF folder into a war file. I’m going to create a war file called “easyjsf” and I’ve actually created to the command down here to create a .war file. A .war file is just a .zip file with all of the various files contained inside of it. I’ve actually written here a command to create a .war file. I’m going to open up my DOS prompt. I’m going to navigate to my easyjsf folder and then I’m going to paste this code in. Notice that I’m calling on the .jar utility that comes with my JDK. I’m going to click “enter” and after just a moment a .war file will be created. These are all of the files that have been placed in that .war file, which is just essentially the content of my _easyjsf directory.

Now if I actually go in and take a look at that _easyjsf directory now alongside that index.jsp file is this easyjsf.war file, I don’t really want that .war file there. That particular file I am going to cut out of there and I’m going to move into the webapps folder of the Tomcat server. Any file placed inside this WEB-INF Web apps folder of the Tomcat server gets deployed when Tomcat starts up. Now my Tomcat server isn’t running right now so I’m just going to navigate to the bin directory of the Tomcat server and issue a startup command.

There is a startup command there just executed from the bin directory of Tomcat. A little Tomcat command window comes up here, console window. It’ll end up going in and deploying any applications that it finds. You can see that jsf-guessNumber was deployed, also easyjsf was deployed. Again because both of those war files were in this Web app folder. You also notice that when it expands it, it actually recreated the folder structure. There is easyjsf right there.

Theoretically, we should be able to access this application by going to this URL [http://localhost:8080/easyjsf/helloworld.faces]. Our Tomcat server's working on port 8080. Of course it’s the local server. Notice the context root as it is called; easyjsf matches the actual name of the .war file minus the .war extension. And of course the resource that we’re looking for, oh look at that, it’s “helloworld.faces.” It’s a little off there because ours was actually "index.faces". Our page was called "index.jsp".

We’re going to copy that URL, [ending in] index.faces, paste it and see what comes up. All of a sudden there we go, we have a little “hello world.” The name is, “Simple JSF Page” Who knows, maybe there is some output in the console window, no nothing of that. But the point is, we have successfully created and deployed, and tested a JSF Hello World application. And we’ve done it all using nothing but Tomcat, the JDK and really just Notepad as our text editor. And of course there are great development environments like NetBeans and Rational application developer out there that you can use to help facilitate development and deployment of your applications.

The bottom line is you can actually use the JDK, use a command prompt, war up some files and deploy them to a Tomcat server, if you can use a basic environment to develop and deploy an application you should have no problem figuring out how to do the same thing in Eclipse or NetBeans. That’s a great start and in further tutorials we will dig further into the JSF API. Happy JavaServer Faces.

Start the conversation

0 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.