You can add an applet to the WAR file, but it requires some extra work. For the applet to work in the WebApp, the classes must be accessible. This means the HTML file and the classes for the applet must be located under the WebApp’s root directory or one of its subdirectories. They cannot be under the WEB-INF directory or its subdirectories.
The Applet wizard doesn’t support putting the applet files within a WebApp, so you will have to move the applet’s HTML file and compiled class files to the WebApp’s root directory (or one of its subdirectories). Depending on where you move the class files, you may need to edit the <applet> tag’s codebase attribute so that it can still find them.
T h e W A R f i l e
If you include loose (unarchived) applet class files in a WebApp, make sure to select Java Class File as one of the included file types on the WebApp page of the WebApp Properties dialog box. Otherwise, the class files won’t be included in the WAR.
You can also put an applet’s JAR file in the WAR file. The same rules apply. The JAR file needs to be accessible. This means it needs to go under the WebApp’s root directory, or one of its subdirectories, but not under the WEB-INF directory.
W o r k i n g w i t h s e r v l e t s 4-1
C h a p t e r
4
Chapter4
Working with servlets
Web Development is a feature of JBuilder Enterprise
Java servlets provide a protocol and platform-independent method for building web-based applications without the performance limitations of CGI programs. A servlet runs inside a web server and, unlike an applet, does not need a graphical user interface. A servlet interacts with the servlet engine running on the web server through requests and responses. A client program, which can be written in any programming language, accesses the web server and makes a request. The request is then processed by the web server’s servlet engine, which passes it on to the servlet. The servlet then sends a response through the web server back to the client.
Today, servlets are a popular choice for building interactive web applications. A variety of third-party web servers with servlet engine extensions are available: Tomcat (the Servlet/JSP API reference implementation), Sun iPlanet and others. Web servers with servlet engines, also known as servlet containers, can also be integrated with web-enabled application servers. JBuilder Enterprise includes the Borland Enterprise Server and also provides support for WebLogic, WebSphere and Sun iPlanet.
Note JBuilder Enterprise includes Tomcat as the default web server. One critical advantage to the servlet technology is speed. Unlike CGI programs, servlets are loaded into memory once and run from memory after the initial load. Servlets are spawned as a thread, and are, by nature, multi-threaded. And, since they are based on the Java language, they are platform independent.
S e r v l e t s a n d J S P s
JavaServer Page (JSP) technology is an extension of the servlet technology created to specifically support authoring of HTML and XML pages. JSP technology makes it easier to combine fixed or static template data with dynamic content. Even if you’re comfortable writing servlets, there are several compelling reasons to investigate JSP technology as a complement to your existing work. For more information on writing JSPs, see
Chapter 6, “Developing JavaServer Pages.”
For more information on servlets, see the following web sites. These web addresses and links are valid as of this printing. Borland does not maintain these web sites and can not be responsible for their content or longevity.
• Java Servlet Technology at http://java.sun.com/products/servlet/ index.html
• Java Servlet Technology: White Paper at http://java.sun.com/products/ servlet/whitepaper.html
• Java Servlet Technical Resources page at http://java.sun.com/products/ servlet/technical.html
• Java Servlet Third-Party Resources page at http://java.sun.com/ products/servlet/resources.html
• The Servlet Trail of The Java tutorial at http://java.sun.com/docs/books/ tutorial/servlets/index.html
You can also look at the following tutorials for information on creating servlets in JBuilder:
• Chapter 16, “Tutorial: Creating a simple servlet”
• Chapter 17, “Tutorial: Creating a servlet that updates a guestbook”
• Chapter 19, “Tutorial: Creating a servlet with InternetBeans Express”
Servlets and JSPs
Both JSP and servlet technology have merits. How do you decide which to use in a given situation?
• Servlets are a programmatic tool and are best suited for low-level application functions that don’t require much presentation logic. • JSPs are a presentation-centric, declarative means of binding dynamic
content and logic. JSPs should be used to handle the HTML
representation that is generated by a page. They are coded in HTML- like pages with structure and content familiar to web content providers. However, JSPs provide far more power than ordinary HTML pages. JSPs can handle application logic through the use of JavaBeans
W o r k i n g w i t h s e r v l e t s 4-3
S e r v l e t s a n d w e b s e r v e r s JSPs themselves can also be used as modular, reusable presentation components that can be bound together using a templating mechanism. JSPs are compiled into servlets, so theoretically you could write servlets to support your web-based applications. However, JSP technology was designed to simplify the process of creating pages by separating web presentation from web content. In many applications, the response sent to the client is a combination of template data and dynamically-generated data. In this situation, it is much easier to work with JSP pages than to do everything with servlets.