Figure A−32: Resource factory information is provided through this dialog...

679
Appendix A: Installing the J2EE Reference Implementation Figure A−33: If you need environment entries for the resource factories, use this dialog.
At last we come to something new! The dialog shown in Figure A−34 is where you provide Web client−specific configuration information. At the top of the window, you provide define any HTML files that are used by the Web server. Welcome files are those which are used by default if you do not provide a file. If you are familiar with standard Web page design, this is the equivalent of the index.html file. So, if a user requested the URL
Figure A−34: Configure all of the startup and HTML files used by JSPs and servlets in this dialog.
http://www.mycompany.com/DemoServlet/
You would get the welcome file you have defined in the top of this window.
In the middle section of the window, you provide the definitions of any tag libraries that your JSPs use. Once again, a name is provided, and a mapping to the real library is provided. Create a new entry by clicking the Add button to the right and then enter the values in the new row of the table.
On the bottom of the window you have the ability to control any error handling that the servlet engine may 680
Appendix A: Installing the J2EE Reference Implementation provide. As you can see, there are two values to be defined — the exception name and then the resource to be called. The name of the exception is the fully qualified class name. For example, you might have a default static HTML page for when the database connection fails; listing the exception here will cause the page to be shown. You can do the same thing for an HTTP error code. For example, if the HTML file is not shown, instead of generating a generic 404 error the servlet engine will automatically throw up an "Oops, we didn't find it"–type page that matches the rest of your site.
Security for most sites is a concern. The next dialog, shown in Figure A−35, allows you to control security on access to the WAR file. Note that this is a different action to defining the roles that you saw back with Figure A−28. Here you are controlling who is allowed to access the Web server and pages on the Web server. A public Web site may always be available, and hence not require security setups, but there may well be times where you want to restrict access to a certain site or part of a site (remember that each part of the site can be a separate JSP or servlet and hence reside in a different WAR file).
Figure A−35: Controlling who can access the Web site and how to authorize them are the functions of this dialog.
Authentication comes in many flavors. At the top of the dialog is the list of authentication methods, ranging from none to an SSL connection with a given certificate. For the purpose of this example, you need nothing more than basic security or no security. However, for a real Web site you may need to provide more complex information. There are two many options to go into detail with here, so please follow the suggestions provided by the tool.
And that's the end of the process. Your final dialog in the creation of a WAR file is shown in Figure A−36.
Like the final dialog of the EJB and application deployment processes, this is a last−chance check over the content of the deployment descriptor information.
681
Appendix A: Installing the J2EE Reference Implementation Figure A−36: One last check of the deployment descriptor information before committing it to the project Clicking Finish here will return you to the main window. As Figure A−37 shows, your tree on the right now includes the new Web component (in addition to a bunch of the beans deployed from the examples developed in Chapter 16!).
Figure A−37: The main window showing the completed deployment process for beans, applications and servlets
Deploying the Web client