Curs Tehnologii Web

1 - INTRODUCTION
1 - INTRODUCTION
1.1 communication protocols
A communication protocol is a set of rules that the end points in a telecom link use when they
communicate.
A protocol is specified in an industry or international standard. All internet related protocols are
defined within the frame of IETF (Internet Engineering Task Force) via a mechanism called
RFC (Request For Comments).
Each (potential) protocol is defined by such a document. For a comprehensive list of all the
RFCs, check the official site www.ietf.org (which present the RFCs in .txt format) or www.cis.ohio-
state.edu/cgi-bin/rfc (which presents the RFCs in .html format, with up to date links embedded in
the documents).
1.2 the OSI model
OSI stands for Open System Interconnection, an ISO (International Standard Organization)
standard for worldwide communications that defines a structured framework for implementing
protocols in seven layers. Control is passed from one layer to the next, starting at the application
layer at the source node, proceeding to the lower layers, over the links to the next node and back
up the hierarchy until the destination node is reached. The structure of the message which is the
object of this exchange gets modified along the way, each step down into the layer hierarchy
adding a new wrapper around the existing message (usually, consisting of a protocol specific
header), while each step up removes the wrapper specific to the layer below.
The seven layers in the OSI model are:
Nr. Layer Description Protocol examples

1 Application Supports application and end user DHCP, DNS, FTP, Gopher,
processes. Provides application HTTP, IMAP4, POP3, SMTP,
services for file transfers, e-mail and SNMP, TELNET, TSL (SSL),
other network software services. SOAP
2 Presentation Translates data from application to APF, ICA, LPP, NCP, NDR,
network format and vice-versa. May XDR, X.25 PAD
also provide compression and
encryption services.
3 Session Sets up, manages and terminates ASP, NetBIOS, PAP, PPTP,
connections between communication RPC, SMPP, SSH, SDP
partners. It handles session and
connection coordination.
4 Transport Provides data transfer between the end DCCP, SCTP, TCP, UDP,
points of the communication partners WTLS, WTP, XTP
and is responsible for error recovery
and flow control.
1
1 - INTRODUCTION
5 Network Responsible for source to destination DDP, ICMP, IPSec, IPv4,

delivery of packages, including routing IPv6, IPX, RIP
through intermediate nodes. Provides
quality of service and error control.
6 Data Link Transfers data between adjacent ARCnet, ATM, CDP,
network nodes and handles errors Ethernet, Frame Relay,
occurred at the physical level HDLC, Token Ring
7 Physical Translates communication requests 10BASE-T, DSL, Firewire,
from the data link layer into GSM, ISDN, SONET/SDH,
transmissions and receptions of V.92
electronic signals at hardware level.
For a detailed description of these layers, check the site:

http://www.geocities.com/SiliconValley/Monitor/3131/ne/osimodel.html .
1.3 sockets - basics
A socket is a logical entity which describes the end point(s) of a communication link between
two IP entities (entities which implement the Internet Protocol). Sockets are identified by the IP
address and the port number. Port numbers range from 0 to 65535 (2^16 – 1) and are split into 3
categories:
1. well known ports - ranging from 0 to 1023 – these ports are under the control of IANA
(Internet Assigned Number Authority), a selective list is shown in the table below:
Port number UDP protocol TCP protocol Other

1 TCPMUX
5 Remote Job Entry (RJE)
7 Echo
15 NETSTAT
20 FTP - data
21 FTP – control
22 Secure Shell
23 Telnet
25 Simple Mail Transfer Protocol (SMTP)
41 Graphics
42 ARPA Host Name Server Protocol WINS
43 WHOIS
53 Domain Name System (DNS)
57 Mail Transfer Protocol (MTP)
67 BOOTP
68 BOOTP
2
1 - INTRODUCTION
69 TFTP
79 Finger
80 HTTP
107 Remote Telnet
109 Post Office Protocol 2 (POP2)
110 POP3
115 Simple FTP (SFTP)
118 SQL services
123 Network Time Protocol (NTP)
137 NetBIOS Name Service
138 NetBIOS Datagram Service
139 NetBIOS Session Service
143 Internet Message Access Protocol (IMAP)
156 SQL service
161 Simple Network Management Protocol (SNMP)
162 SNMP Trap
179 Border Gateway Protocol (BGP)
194 Internet Relay Chat (IRC)
213 IPX
2. registered ports - ranging from 1024 to 49151 – registered by ICANN, as a convenience

to the community, should be accessible to ordinary users. A selective list of some of these
ports is listed below:
Port number UDP protocol TCP protocol Other

1080 SOCKS proxy
1085 WebObjects
1098 RMI activation
1099 RMI registry
1414 IBM WebSphere MQ
1521 Oracle DB default listener
2030 Oracle services for Microsoft Transaction Server
2049 Network File System
2082 CPanel default
3306 MySQL DB system
3690 Subversion version control system
3724 World of Warcraft online gaming
4664 Google Desktop Search
3
1 - INTRODUCTION
5050 Yahoo Messenger

5190 ICQ and AOL IM
5432 PostgreSQL DB system
5500 VNC remote desktop protocol
5800 VNC over HTTP
6000/6001 X11
6881-6887 BitTorrent
6891-6900 Windows Live Messenger – File transfer
6901 Windows Live Messenger – Voice
8080 Apache Tomcat
8086/8087 Kaspersky AV Control Center
8501 Duke Nukem 3D
9043 WebSphere Application Server
14567 Battlefield 1942
24444 NetBeans IDE
27010/27015 Half-Life, Counter-Strike
28910 Nintendo Wi-Fi Connection
33434 traceroute
3. dynamic (private) ports, ranging from 49152 to 65535
1.4 posix sockets
To create a client socket, two calls are necessary. The first one creates a file descriptor (fd)
which is basically a number which identifies an I/O channel (not different from the file descriptor
resulted from a fopen() call which opens a file).
The prototype of this call is the following:
int socket(int family, int type, int protocol);
The family parameter specifies the address family of the socket and may take one of the
following values, the list itself depending on the implementation platform:
• AF_APPLETALK
• AF_INET – most used, indicates an IP version 4 address
• AF_INET6 - indicates an IP version 6 address
• AF_IPX
• AF_KEY
• AF_LOCAL
• AF_NETBIOS
• AF_ROUTE
4
1 - INTRODUCTION
• AF_TELEPHONY
• AF_UNSPEC
The type parameter specifies the socket stream type and may take the following values:
• SOCK_STREAM
• SOCK_RAW
• SOCK_DGRM
The value of the protocol parameter is set to 0, except for raw sockets.
The second call connects the client to the server. Here is the signature of the connect() call.
int connect(int sock_fd, struct sockaddr * server_addr, int addr_len);
To create a server socket, four calls are necessary. Here are the prototypes of these calls:
int socket(int family, int type, int protocol);
int bind(int sock_fd, struct sockaddr * my_addr, int addr_len);
int listen(int sock_fd, int backlog);
int accept(int sock_fd, struct sockaddr * client_addr, int * addr_len);
A few remarks. Why not binding the client socket to a particular port, as well? Well, nobody stops
us from invoking the bind() function on a client socket, but this is not exactly relevant. While the
server port has to be known, because the client must know both the IP address (or the URL, if that
is the case) and the port of the server, it is not important to know the port of the client. The
assignment of a port to a client socket is done by the operating system, and this solution is quite
satisfactory.
5
2 - HTTP
2 - HTTP
2.1 what is http
HTTP stands for HyperText Transfer Protocol while hypertext means text contatining links to
another text. HTTP was created by by Tim Berners-Lee in 1990 at CERN as a mean to store
scientific data. It quickly evolved into the preferred communication protocol over the internet.
The first oficial version – HTTP 1.0 – dates from 05/95 and is the object of RFC 1945
(www.cis.ohio-state.edu/cgi-bin/rfc/rfc1945.html). It is authored by Tim Berners-Lee, Roy Fielding
and Henrik Nielsen.
The second (and last, so far) version, namely HTTP 1.1, was the object of several RFCs, of
which we mention RFC 2068 (01/97), RFC 2616 (06/99), RFC 2617 (06/99) and RFC 2774
(02/00).
For a complete specification of the different HTTP versions, check the official HTTP site –
www.w3.org/Protocols . As a site for understanding how HTTP works, we recommend
www.jmarshall.com/easy/http.
2.2 the structure of http transactions
HTTP follows the client – server model. The client sends a request message to the server. The
server answers with a response message. These messages may have different contents, but they
also have some common structural elements, as follows:
1. an initial line
2. zero or more header lines
3. a blank line (CR/LF)
4. an optional message body
<initial line>
Header1: value1
...
Headern: valuen
<optional data block>
2.3 the initial request line
Contains 3 elements, separated by spaces:

• a command (method) name (like GET, POST, HEAD, ...)
• a file specification (path) (the part of the URL after the host name)
• the HTTP version (usually, HTTP/1.0).
6
2 - HTTP
Here is an example of an initial request line:

GET /path/to/the/file/index.html HTTP/1.0
2.4 http commands (methods)
As of HTTP 1.1, there are 8 HTTP commands (methods) that are widely supported. Here is
their list:
1. GET
2. HEAD
3. POST
4. CONNECT
5. DELETE
6. OPTIONS
7. PUT
8. TRACE
Three other commands are listed, as well, in the HTTP 1.1 specification, but lack of support
makes them obsolete. These commands are:
• LINK
• UNLINK
• PATCH
The HEAD command is identical to the GET command in all respects but one. The only
difference is that the response must not have a body. All the information requested is returned in
the header section of the response.
2.5 the GET and POST methods
The GET method means retrieve whatever information (in the form of an entity) is identified by
the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data
which shall be returned as the entity in the response and not the source text of the process, unless
that text happens to be the output of the process.
The POST method is used to request that the origin server accept the entity enclosed in the
request as a new subordinate of the resource identified by the Request-URI in the Request-Line.
POST is designed to allow a uniform method to cover the following functions:
- Annotation of existing resources;

- Posting a message to a bulletin board, newsgroup, mailing list,
or similar group of articles;
7
2 - HTTP
- Providing a block of data, such as the result of submitting a

form, to a data-handling process;
- Extending a database through an append operation.
The actual function performed by the POST method is determined by the server and is usually
dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that
a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to
which it is posted, or a record is subordinate to a database.
The action performed by the POST method might not result in a resource that can be identified
by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status,
depending on whether or not the response includes an entity that describes the result.
2.6 differences between GET and POST
1. The method GET is intended for getting (retrieving) data, while POST may involve anything,
like storing or updating data, or ordering a product, or sending E-mail
2. When used for form data submission, GET attaches this data to the URL of the request, after
the “?” character, as a sequence of “name=value” pairs, separated by the character “&” or “;”
On the other side, form data submitted by POST may be encoded either as above (using
application/x-www-form-urlencoded content type), or in the message
body, (encoded as multipart/form-data).
3. A POST request requires an extra transmission to retrieve the message body, while a GET
request allows data sent via the URL to be processed immediately.
2.7 the initial response (status) line
Contains 3 elements, separated by spaces (although the reason phrase may contain spaces, as
well):
• the HTTP version of the response
• a response status code (a number)
• a response status reason phrase (a human readable response status)
Here is an example of an initial response line:
HTTP/1.0 404 Not Found
2.8 the status code
A three-digit integer, where the first digit identifies the general category of response:
• 1xx indicates an informational message only
• 2xx indicates success of some kind
8
2 - HTTP
• 3xx redirects the client to another URL

• 4xx indicates an error on the client's part
• 5xx indicates an error on the server's part
The most common status codes are:
• 200 OK - the request succeeded, and the resulting resource (e.g. file or script output) is
returned in the message body.
• 404 Not Found - the requested resource doesn't exist.
• 301 Moved Permanently
• 302 Moved Temporarily
• 303 See Other (HTTP 1.1 only) - the resource has moved to another URL (given by the
Location: response header), and should be automatically retrieved by the client. This is
often used by a CGI script to redirect the browser to an existing file.
• 500 Server Error - an unexpected server error. The most common cause is a server-side
script that has bad syntax, fails, or otherwise can't run correctly.
A complete list of status codes is in the HTTP specification (the URL was mentioned in the firs
section of this chapter) (section 9 for HTTP 1.0, and section 10 for HTTP 1.1).
2.9 header lines
A header line consists of two parts, header name and header value, separated a semicolon.
The HTTP 1.0 version specifies 16 headers, none of them mandatory, while the HTTP 1.1 version
specifies 46 of them, out of which, one (Host) is mandatory. Although the header names are not
case sensitive, header values are.
A couple of examples of header lines:
User-agent: Mozilla/3.0Gold
Last-Modified: Fri, 31 Dec 1999 23:59:59 GMT
Header lines which begin with spaces or tabs are parts of the previous header line.
2.10 the message body
An HTTP message may have a body of data sent after the header lines. The most common use
of the message body is in a response, that is, where the requested resource is returned to the
client, or perhaps explanatory text if there's an error. In a request, this is where user-entered data
or uploaded files are sent to the server.
If an HTTP message includes a body, the header lines of the message are used to describe the
body. In particular,
• the Content-Type: header gives the MIME-type of the data in the body, such as text/html
or image/jpg.
• the Content-Length: header gives the number of bytes in the body.
9
2 - HTTP
2.11 mime types/subtypes
MIME stands for Multipurpose Internet Mail Extensions. Each extension consists of a type and
a subtype. RFC 1521 (www.cis.ohio-state.edu/cgi-bin/rfc/rfc1521.html) defines 7 types and
several subtypes, although the list of admissible subtypes is much longer.
Here is the list of the seven types, together with the subtypes defined in this particular RFC.
1. text, with subtype plain
2. multipart, with subtypes mixed, alternative, digest, parallel
3. message, with subtypes rfc822, partial, external-body
4. application, with subtypes octet-stream, postscript
5. image, with subtypes jpeg, gif
6. audio, with subtype basic
7. video, with subtype mpeg
2.12 an example of an http transaction
To retrieve the file at the URL

http://web.info.uvt.ro/path/file.html
first open a socket to the host web.info.uvt.ro, port 80 (use the default port of 80 because none
is specified in the URL). Then, send something like the following through the socket:
GET /path/file.html HTTP/1.0
From: someuser@yahoo.com
User-Agent: HTTPTool/1.0
[blank line here]
The server should respond with something like the following, sent back through the same
socket:
HTTP/1.0 200 OK
Date: Fri, 31 Dec 1999 23:59:59 GMT
Content-Type: text/html
Content-Length: 1354
<html>
<body>
<h1>Happy birthday!</h1>
(more file contents)
.
.
.
</body>
</html>
After sending the response, the server closes the socket.
10
3 - HTML
3 - HTML
3.1 what is html?
HTML stands for HyperText Markup Language. HTML describes how text, images and other
components are to be displayed in a browser, using a variety of tags and their related attributes.
The first version of HTML, namely HTML 1.0, appeared in summer 1991 and was supported by
the first popular web browser, Mosaic. The first official version – HTML 2.0 - was approved as a
standard in September 1995 (as RFC 1866 (www.cis.ohio-state.edu/cgi-bin/rfc/rfc1866.html) and
was widely supported. A newer standard, HTML 3.2 (3.0 was not widely accepted) appeared a
W3C recommendation in January 1997.
Version 4.0 introduces the Cascading Style Sheets.
The newest version of HTML is 4.01. It is a revision of 4.0 and was accepted in December
1997. However, a working draft for a new version, namely HTML 5 was published in June 2008.
From 1999 on, HTML is part of a new specification – XHTML. The XHTML 1.0 draft was
released in 01.99. The latest version (XHTML 2.0) dates from 08.02 and is not intended to be
backwards compatible.
For a complete specification of the different HTML versions, check the official HTML site –
www.w3c.org/Markup . As a practical reference site use – www.blooberry.com/indexdot/html .
Other helpful sites - www.htmlgoodies.com/tutors, www.jmarshall.com/easy/html .
3.2 language definition
HTML is a system for describing documents. It is a special version of SGML (Standard

Generalized Markup Language – an ISO standard (ISO 8879)). All markup languages defined in
SGML are called SGML applications and are characterized by:
1. An SGML declaration – what characters and delimiters may appear. The SGML
declaration of the latest version of HTML (4.01) can be found at this address:
http://www.w3.org/TR/1999/PR-html40-19990824/sgml/sgmldecl.html. Since it fits in a
couple of pages, we can afford to have a look at this declaration.
<!SGML "ISO 8879:1986"

--
SGML Declaration for HyperText Markup Language version HTML 4.01
With support for the first 17 planes of ISO 10646 and increased
limits for tag and literal lengths etc.
--
CHARSET
BASESET "ISO Registration Number 177//CHARSET
ISO/IEC 10646-1:1993 UCS-4 with
implementation level 3//ESC 2/5 2/15 4/6"
DESCSET 0 9 UNUSED
9 2 9
11 2 UNUSED
11
3 - HTML
13 1 13
14 18 UNUSED
32 95 32
127 1 UNUSED
128 32 UNUSED
160 55136 160
55296 2048 UNUSED -- SURROGATES --
57344 1056768 57344
CAPACITY SGMLREF
TOTALCAP 150000
GRPCAP 150000
ENTCAP 150000
SCOPE DOCUMENT
SYNTAX
SHUNCHAR CONTROLS 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 127
BASESET "ISO 646IRV:1991//CHARSET
International Reference Version
(IRV)//ESC 2/8 4/2"
DESCSET 0 128 0
FUNCTION
RE 13
RS 10
SPACE 32
TAB SEPCHAR 9
NAMING LCNMSTRT
""
UCNMSTRT
""
LCNMCHAR
".-_:"
UCNMCHAR
".-_:"
NAMECASE
GENERAL YES
ENTITY NO
DELIM GENERAL SGMLREF
SHORTREF SGMLREF
NAMES SGMLREF
QUANTITY SGMLREF
ATTCNT 60 -- increased --
ATTSPLEN 65536 -- These are the largest values --
LITLEN 65536 -- permitted in the declaration --
NAMELEN 65536 -- Avoid fixed limits in actual --
PILEN 65536 -- implementations of HTML UA's --
TAGLVL 100
TAGLEN 65536
GRPGTCNT 150
GRPCNT 64
FEATURES
MINIMIZE
DATATAG NO
OMITTAG YES
RANK NO
SHORTTAG YES
LINK
SIMPLE NO
IMPLICIT NO
EXPLICIT NO
12
3 - HTML
OTHER
CONCUR NO
SUBDOC NO
FORMAL YES
APPINFO NONE
>
2. A Document Type Definition (DTD) – defines the syntax of markup constructs. Check the
address http://www.w3.org/TR/REC-html40/sgml/dtd.html for the latest version of the
HTML DTD.
3. A specification that describes the semantics to be ascribed to the markup and character
entity references. This specification adds new syntactic restrictions which cannot be
defined within the frame of the DTD.
4. Document instances containing data (content) and markup. Each instance contains a
reference to the DTD to be used to interpret it.
Overall, the specification of HTML 4.0 contains an SGML declaration, three DTDs (HTML 4.0
Strict DTD, HTML 4.0 Transitional DTD, HTML 4.0 Frameset DTD) and a list of character
references. If you wonder what a character reference is, look at these examples: “&lt”, “&quot”,
"水" (in hexadecimal) - the chinese character for water. You get the point.
3.3 html elements
An HTML element consists of:

• a start tag
• a content
• an end tag
One exception, though; the element <BR> has no content and no end tag.
There are 91 elements defined in the HTML 4.01 specification. This section deals with some of
the most common elements.
The start tag of the element contains the values of the (required or optional) attributes of the
element. An example:
<IMG SRC=”/images/logo.gif” ALT=”logo” HEIGHT=40 WIDTH=120>
declares an image element, with the required (mandatory) attributes SRC and ALT and the
optional attributes HEIGHT and WIDTH. Other optional attributes of the <IMG> element,
like ALIGN, BORDER, CONTROLS, DYNSRC, …, VSAPCE are omitted.
A comment section in an HTML document starts with .
An example:

13
3 - HTML
3.3.1 The <A> element

Must contain one of the 2 attributes – HREF, NAME. Main attributes:
• HREF – specifies the absolute or relative URL of the hyperlink
• NAME – assigns a symbolic name to the enclosed object (text, image, etc.) in order to
use it as a destination in a hyperlink or another URL call.
Example:
<A HREF=”http://web.info.uvt.ro/webmail/src/login.php”>Login to
web mail</A>
3.3.2 The <IMG> element

Main attributes:
• ALT – required; specifies the text to be displayed in case source is not found
• SRC – required; indicates the URL to reference the graphic
• HEIGHT
• WIDTH
3.4 the minimal structure of an html document
All HTML documents start with the <HTML> tag and end with the corresponding end tag
</HTML>. An HTML document consists of the parts:
• the <HEAD> part
• the <BODY> part
A minimal HTML document example:

<HTML>
<HEAD>My Page
</HEAD>
<BODY>Empty Body
</BODY>
</HTML>
3.5 tables
A table is a visual rectangular object consisting of several rows and columns. The intersection
of any row and any column is called a cell. Usually, the cells in the first row contain are called
14
3 - HTML
headers and consist of a brief description of the content of the corresponding column. Here is a
an example of a table:
3.6 table related elements
The specific elements defining a table, its rows, columns, headers and cells are <TABLE>,
<THEAD>, <TR>, <TH> and <TD>. Here is their description and attributes.
the <TABLE> element
attributes:
• BORDER
• CELLSPACING
• CELLPADDING
• WIDTH
• ALIGN
• VALIGN
• TBODY
• BORDERCOLOR
• FRAME
• RULES
• COLORGROUP
• BACKGROUND
the <THEAD> element

attributes:
• ALIGN
• BGCOLOR
• CHAR
• CHAROFF
• VALIGN
the <TH> element

attributes:
• ABBR
• AXIS
• CHAR
• CHAROFF
• HEADERS
15
3 - HTML
• SCOPE
the <TR> element

attributes:
• ALIGN
• BGCOLOR
• CHAR
• CHAROFF
• VALIGN
the <TD> element

attributes:
• ABBR
• ALIGN
• CHAR
• CHAROFF
• COLSPAN
• ROWSPAN
• SCOPE
• VALIGN
• WIDTH
3.7 forms
A form is a basic component container, allowing user input and paarmeter submittal.
The <FORM> element has the following attributes:
• ACTION - required, specifies the URL of the server side process that will receive the data
• METHOD - required, may have the values GET or POST, specifies how data will be sent to
the server. Possible values for this attribute:
• "POST"- sends the form values in 2 steps: contacts first the server then the form values are
sent in a separate transmission.
• "GET" - sends the form values in a single transmission, the browser appends the values to
the URL, after a quotation mark - ?. The pairs name=value are separated by ampersand - &
or (sometimes) by semicolon - :.
Example:
http://web.info.uvt.ro/servlet/MyServlet?a=12&b=25
• ENCTYPE - specifies the encoding type of the of the form content. Default value:
16
3 - HTML
• "application/x-www-form-urlencoded" - the default value; however, since it converts spaces

to '+' and non-alphanumerical to '%HH', where 'HH' is the hexadecimal ASCII code of the
character.
Other possible values for this attribute:
• "multipart/form-data" - used with forms that contain a file-selection field, data is sent as a
single document with multiple sections.
• "text/plain"
3.8 form related elements
3.8.1 the <INPUT> element

Defines input fields for the form. Main attributes:
• TYPE - required, specifies the type of the input which can have one of the following
values: "text", "password", "checkbox", "radio", "submit", "image", "reset", "button",
"hidden", "file".
• NAME - required, specifies the parameter name.
3.8.2 the <SELECT> element

Used to create a list of choices, either as a drop-down menu or as a list box. Each of the listed
choices is an OPTION element.
Main attributes:
• NAME
• MULTIPLE - if specified, allows multiple selections from the choice list.
• SIZE - maximum number of options visible to the user.
3.8.3 the <OPTION> element

Used inside a <SELECT> element to list the selection choices. Main attributes:
• SELECTED
Example of a <SELECT> element:
<SELECT NAME="action" STYLE="font-family: '@Arial Unicode

MS' font-size: 11pt">
<OPTION SELECTED>Select Action
<OPTION>Make Payment
<OPTION>Transfer a balance
<OPTION>Change Mailing Address
<OPTION>Change e-mail Address
<OPTION>Change User Name/Password
17
3 - HTML
<OPTION>View Account Activity

</SELECT>
18
4 - JAVA PRIMER
4 - JAVA PRIMER
4.1 history
The initial name of this language was OAK and was developed as part of the GREEN project at
Sun, project started in 12.90. Early versions of Java were released in 12.94 and was officially
announced at Sun World in 05.95. The first commercial version was delivered to the first
customer (Netscape, Inc.) in 08.95. The current version (as of 10.2004) of Java 2 Platform
Standard Edition is J2SE 5.0, following the 1.4.2 version. The current version of Java 2 Platform
Enterprise Edition is J2EE 1.4 Update 1.
4.2 java the interpreter, jit
From source to execution, A java program goes thru the following phases:
1. Java source – a file with extension .java
2. Java bytecode – a file with extension .class
3. The Java interpreter (which is part of the Java Virtual Machine) parses and executes the
Java bytecode.
Example:
Edit the file prog1.java. The java compiler (javac) translates it to bytecode – prog1.class. The
java interpreter (as part of the JVM) parses and executes the prog1.class file.
In terms of execution time, a Java interpreted program is about 10 times slower than a
compiled and linked one. To overcome this significant shortage, a tool named Just In Time
compiler, allows the compilation of the Java source into machine-dependent binary executable.
The first time a class is loaded, the compilation process occurs, which accounts for a pretty slow
execution, but next time execution is much faster, pretty much comparable to that of a binary
executable.
The java compiler is (in general) a command line tool, with the following main options:
• -classpath <path>
• -sourcepath <path>
• -d <directory> : specifies where to put the .class file.
• -g : generate all debugging info.
One example of command line compilation:
javac -classpath .;C:\TW\mySource;C:\TW\myPackages -g login.java
4.3 java applications
TThere exist 2 types of programs that can be written in Java. The first type are embedded in
19
4 - JAVA PRIMER
web pages – applets, the others are the standalone programs – Java applications.
A java applet is java class that extends the standard Applet class.
In general, an applet is inserted in a HTML page by an <APPLET> tag or by an <OBJECT> tag.
The <APPLET> element has 3 mandatory attributes, namely:
• CODE – identifies the (compiled) class file of the applet
• WIDTH
• HEIGHT
A java application is a collection of java classes. Generally, each class is implemented in a
source file having the same name as the class itself and whose extension is .java. Exactly one of
these classes must implement a method called main(). This method is the entry point in the
application and must have the following signature:
public static void main(String[] args)
A compiled java application (class) may be executed from the command line using an executable
called java (the java interpreter), as follows:
java [-options] class [args]
Where main options are:

• -cp <directories and jar files separated by “;”> : cp = classpath
• -D <name>=<value> : set a system property
To execute a .jar file, use the command:
java –jar [-options] jarfile [args]
4.4 object oriented concepts
4.4.1 encapsulation
This is a fancy word for the tendency of hiding the implementation of the methods of some class
and exposing only the interface of its public (and to some degree – its protected) methods.
4.4.2 inheritance
Inheritance is a partial order relation in the set of all Java classes. A Java class B inherits
another class A (or is a subclass of A, or is derived from A, or that it extends A). This binary
relation is specified in the declaration of the derived class B using the keyword extends. An
example:
20
4 - JAVA PRIMER
public class CaineComunitar extends Caine

{
…
}
In this case, all variables and methods of the base class A are automatically variables and
methods of the derived class B.
The derived class B can use (for free) all the methods of the base class, but it also can override
the implementation of any method in the base class, providing its own implementation.
While C++ allows multiple inheritance, a Java class can extend a single base class. That means
that the graph of the direct inheritance relation is a forest (its connected components are trees). In
fact, all classes in Java are (by default) subclasses of a universal base class, called Object.
Therefore, the forest we mentioned is actually a tree, with the root the class Object.
4.4.3 Polymorphism
Polymorphism means the ability of a variable of a given (base) type (class) to be used to
reference objects of different (derived) types (classes), and automatically call the method specific
to the type (derived class) of the object that the variable references.
4.4.4 Method overloading

A method (which has to be declared in some class (or interface)) is identified by its name and the
type sequence of its parameters. The return type of a method is not part of this signature.
Therefore, a class can have more than one method with the same name, provided that the types
(and order) of its parameters are different. In OO jargon, this is called method overloading.
4.5 java as programming language
integer data types:

• byte
• short
• int
• long
floating point data types:
• float
• double
other types:
• boolean - 1 bit
• char - Unicode (16 bits)
All basic types have associated classes which extend their functionality, namely: Byte, Short,
Integer, Long, Float, Double, Boolean, Character.
21
4 - JAVA PRIMER
Other peculiarities: no pointers (only references), automatic garbage collection, no templates.
4.6 access specifiers and modifiers in java
The access attributes of a member variable or method of a class are specified by the access
specifiers. Except for the "package" concept, they have the same basic meaning as in C++.
• no specifier - the default value allows access from any class in the same package
• public - access from any class anywhere
• private - no access from outside the class itself
• protected - accessible from any class in the same package an any subclass anywhere
While the above specifiers apply to the variables and the methods of a class, the specifiers for
the class itself can be taken from the following list:
• no specifier - the default value makes the class visible only to the classes in the same
package
• public - the class is visible from any class, anywhere
• abstract - the class is abstract (some of its methods (inherited or specified by some
interface) are to be implemented by some of its subclasses)
An example. The declaration:
abstract class myFirstClass extends javax.servlet.http.HttpServlet
implements Serializable
{
...
}
declares an abstract class, which is visible only to the classes in the same package, which
extends the class javax.servlet.http.HttpServlet and which implements the
Serializable interface.
The modifiers of the variables and methods of a class specify their range and stability. A static
variable or method is one which is implemented at class level, rather than at class instance. A
final variable (method, class) is one which cannot be modified (overridden, inherited). More
precisely:
A static (or class):
• variable - one which is defined at class level, has the same value for all class instances.
• method - all variables referenced in the function body are static variables.
Static variables and methods can be referenced (invoked) using either the name of the class or
the name of a class instance.
A final:
• variable - one which is constant
• method - the method implementation cannot be overriden by some subclass.
• class - does not have any subclasses.
22
4 - JAVA PRIMER
4.7 exceptions in java
An exception signals an abnormal situation or an error in an application, due to a variety of

execution factors or due to programming errors.
In Java, an exception is an object which is created when the abnormal situation occurs.
Exception categories:
1. code or data errors - like invalid cast, array index out of bounds, division by 0.
2. standard method exceptions
3. programmer defined exceptions
4. java errors - JVM execution errors (mostly caused by programming errors).
All exceptions (even programmer defined) must inherit from the standard class Throwable.
All the standard exceptions are derived from 2 direct subclasses of Throwable, namely class
Error and the class Exception.
4.7.1 The Error class

Represent conditions which are not expected to be caught in our code. Therte are 3 direct
subclasses of the class Error - ThreadDeath, Linkage Error and VirtualMachineError.
4.7.2 The Exception class

Except for the RuntimeException exceptions, all then exceptions in this category must be
caught in our code.
4.7.3 RuntimeException Exceptions

Usually, these exceptions take place because of serious code errors and they are supposed to
be fixed in the coding phase, not at execution time.
The subclasses of the RuntimeException class, as defined in the java.lang package are:
• ArithmeticException
• IndexOutOfBoundException
• NegativeArraySizeException
• NullPointerException
• ArrayStoreException
• ClassCastException
• IllegalArgumentException
• SecurityException
• IllegalMonitorStateException
• IllegalStateException
• UnsupportedOperationException
4.7.4 Handling Exceptions

There are 2 ways to deal with exceptions:
• supply then code to deal with the exception inside the method - this can be done by
providing a try, catch, finally construct.
• ignore it (pass it to the code that called the method) - by adding the key word throws,
followed by a comma separated list of exceptions after the parameter list of the method.
23
4 - JAVA PRIMER
4.8 java packages
A Java package is a named collection of classes. Each class belongs to a package (even if a
package name is not specified, the default package is used). The names in a package are
qualified by the package name, therefore, they have to be unique inside a package.
4.8.1 Package names

The default package has no name. The package containing the standard classes is java.lang
(automatically available). All other packages must be explicitly imported. As a general rule, the
package statement is the first one in a java source file, followed by the import statements. An
example:
package com.bank11.ccards.servlets;
import javax.sql.*;
import.java.util.Properties;
...
The name of the package is directly linked to the directory structure in which it is stored. In the
example above, the class (the .class file, rather) defined in the java source must be stored in a
directory called servlets, which is a subdirectory of ccards (which itself, is a subdirectory of a
directory called bank11).
4.9 standard Java packages
• java.lang - default, don't have to import

• java.io
• java.awt - support for user interface
• java.awt.event - support for event handling
• java.awt.geom - support for operations with 2D geometric figures
• java.net
• java.nio
• java.rmi
• java.util - support for data collections, string analyzers, date and time info
• java.util.zip - support for java archives creation
• java.sql
• java.security
• java.text
• javax.accessibility
• javax.swing - swing GUI components (minimal dependence on native code)
24
4 - JAVA PRIMER
• java.swing.event - support for event handling
4.10 interfaces
An interface in Java corresponds to the abstract class concept in C++. While multiple
inheritance is forbidden in Java (a class can be the subclass of a single base class), Java classes
can implement zero or more interfaces.
An interface is a collection of constants and "abstract" functions.
All variables (actually, constants) of an interface are automatically (by default) public, static and
final. All methods declared in an interface are (by default) public and abstract.
If a class is declared as implementing an interface but omits some of its methods, it must be
declared as abstract.
25
5 - javaScript
5 - JAVASCRIPT
5.1 so what is JavaScript?
JavaScript is a scripting language designed to add interactivity to HTML pages.
• A scripting language is a lightweight programming language

• A JavaScript source consists of lines of executable computer code
• A JavaScript is usually embedded directly into HTML pages
• JavaScript is an interpreted language (means that scripts execute without preliminary
compilation)
5.2 what can a JavaScript do?
• JavaScript gives HTML designers a programming tool - HTML authors are normally
not programmers, but JavaScript is a scripting language with a very simple syntax!
Almost anyone can put small "snippets" of code into their HTML pages
• JavaScript can put dynamic text into an HTML page - A JavaScript statement like this:
document.write("<h1>" + name + "</h1>") can write a variable text into an HTML page
• JavaScript can react to events - A JavaScript can be set to execute when something
happens, like when a page has finished loading or when a user clicks on an HTML
element
• JavaScript can read and write HTML elements - A JavaScript can read and change the
content of an HTML element
• JavaScript can be used to validate data - A JavaScript can be used to validate form
data before it is submitted to a server. This saves the server from extra processing
• JavaScript can be used to detect the visitor's browser - A JavaScript can be used to
detect the visitor's browser, and - depending on the browser - load another page
specifically designed for that browser
• JavaScript can be used to create cookies - A JavaScript can be used to store and
retrieve information on the visitor's computer
5.3 how and where?
JavaScripts in a page will be executed immediately while the page loads into the browser. This
is not always what we want. Sometimes we want to execute a script when a page loads, other
times when a user triggers an event.
5.3.1 scripts in the head section

Scripts to be executed when they are called, or when an event is triggered, go in the head section.
When you place a script in the head section, you will ensure that the script is loaded before
anyone uses it. Here is an example:
<html>
26
5 - javaScript
<head>
<script type="text/javascript">
....
</script>
</head>
5.3.2 scripts in the body section

Scripts which are to be executed when the page loads go in the body section. When you place a
script in the body section it generates the content of the page.
<html>
<head>
</head>
<body>
....
</script>
</body>
5.3.3 using an external JavaScript

Sometimes you might want to run the same JavaScript on several pages, without having to write
the same script on every page. To simplify this, you can write a JavaScript in an external file.
Save the external JavaScript file with a .js file extension.
Note: The external script cannot contain the <script> tag!
To use the external script, point to the .js file in the "src" attribute of the <script> tag:
<html>
<head>
<script src="myScript.js">
</script>
</head>
<body>
</body>
</html>
5.4 javaScript variables and expressions
A variable is a "container" for some information whose value can change during the script.
5.4.1 Variable names

Rules for variable names:
• Variable names are case sensitive
• They must begin with a letter or the underscore character
5.4.2 variable declaration

A variable can be declared or even created with the var statement:
var strnum = "2157 Sunrise Blvd";
27
5 - javaScript
or
strnum = "2157 Sunrise Blvd";
5.4.3 variable assignment

A value can be assigned to a variable at declaration time:
var strnum = "Morii 771"
Or just use a plain assignment:
strname = "Morii 771"
5.4.4 variable types

A variable declaration in JavaScript does not contain a type declaration. The type of the variable
is determined by any assignment of a value to that variable. This means that the type of the
variable can change during the execution of a JavaScript script.
5.5 javaScript flow control
Apart from the usual flow control constructs, namely – if ... else, switch(), for(), while(), break,
continue, while() it is worth mentioning the for ... in and the try ... catch constructs.
5.5.1 JavaScript For...In Statement

The for...in statement is used to loop (iterate) through the elements of an array or through the
properties of an object.
The code in the body of the for ... in loop is executed once for each element/property.
Syntax
for (variable in object)

{
code to be executed
}
The variable argument can be a named variable, an array element, or a property of an object.
Example
Using for...in to loop through an array:
<html>
<body>
var x;
var mycars = new Array();
mycars[0] = "Saab";
mycars[1] = "Volvo";
mycars[2] = "BMW";
28
5 - javaScript
for (x in mycars)
{
document.write(mycars[x] + "<br />");
}
</script>
</body>
</html>
5.5.2 Catching Errors

When browsing Web pages on the internet, we all have seen a JavaScript alert box telling us
there is a runtime error and asking "Do you wish to debug?". Error message like this may be
useful for developers but not for users. When users see errors, they often leave the Web page.
This chapter will teach you how to trap and handle JavaScript error messages, so you don't lose
your audience.
There are two ways of catching errors in a Web page:
• By using the try...catch statement (available in IE5+, Mozilla 1.0, and Netscape 6)
• By using the onerror event. This is the old standard solution to catch errors (available
since Netscape 3)
5.5.3 Try...Catch Statement

The try...catch statement allows you to test a block of code for errors. The try block contains the
code to be run, and the catch block contains the code to be executed if an error occurs.
Syntax
try
{
//Run some code here
}
catch(err)
{
//Handle errors here
}
Example
<html>
<head>
var txt=""
function message()
{
try
{
adddlert("Welcome guest!");
}
catch(err)
{
txt="There was an error on this page.\n\n";
txt+="Error description: " + err.description + "\n\n";
29
5 - javaScript
txt+="Click OK to continue.\n\n";
alert(txt);
}
}
</script>
</head>
<body>
<input type="button" value="View message" onclick="message()" />
</body>
</html>
5.6 operators
The only new one is the comparison operator === (equal values and same type). Also, strings can
be added (concateneted) using the + operator.
5.7 popup boxes
5.7.1 alert Box

An alert box is often used if you want to make sure information comes through to the user.
When an alert box pops up, the user will have to click "OK" to proceed.
Syntax:
alert("sometext")
5.7.2 confirm Box

A confirm box is often used if you want the user to verify or accept something. When a confirm
box pops up, the user will have to click either "OK" or "Cancel" to proceed. If the user clicks "OK",
the box returns true. If the user clicks "Cancel", the box returns false.
Syntax:
confirm("sometext")
5.7.3 prompt Box

A prompt box is often used if you want the user to input a value before entering a page. When a
prompt box pops up, the user will have to click either "OK" or "Cancel" to proceed after entering
an input value. If the user clicks "OK" the box returns the input value. If the user clicks "Cancel",
the box returns null.
Syntax:
prompt("sometext","defaultvalue")
30
5 - javaScript
5.8 functions
5.8.1 function definition

A function contains some code that will be executed only by an event or by a call to that function.
A function can be called from anywhere within the page (or even from other pages if the function
is embedded in an external .js file). Functions are defined at the beginning of a page, in the
<head> section. Example:
<html>
<head>
function displaymessage() { alert("Hello World!") }
</script>
</head>
<body>
<form>
<input type="button" value="Click me!"
onclick="displaymessage()" >
</form>
</body>
</html>
If the line: alert("Hello world!!"), in the example above had not been written within a function, it
would have been executed as soon as the line was loaded. Now, the script is not executed before
the user hits the button. We have added an onClick event to the button that will execute the
function displaymessage() when the button is clicked.
More about JavaScript events in the JS Events chapter.
The syntax for creating a function is:

function functionname(var1,var2,...,varX) { some code }
var1, var2, etc are variables or values passed into the function. The { and the } defines the start
and end of the function.
Note: A function with no parameters must include the parentheses () after the function name:
function functionname() { some code }
Note: Do not forget about the importance of capitals in JavaScript! The word function must be
written in lowercase letters, otherwise a JavaScript error occurs! Also note that you must call a
function with the exact same capitals as in the function name.
5.8.2 the return Statement

The return statement is used to specify the value that is returned from the function. So, functions
that are going to return a value must use the return statement. An example is the function below
should return the product of two numbers (a and b):
function prod(a,b) { x=a*b return x }
When you call the function above, you must pass along two parameters:
31
5 - javaScript
product=prod(2,3)
The returned value from the prod() function is 6, and it will be stored in the variable called
product.
5.9 javaScript objects
5.9.1 Object Oriented Programming

JavaScript is an Object Oriented Programming (OOP) language. An OOP language allows you to
define your own objects and make your own variable types.
We will start by looking at the built-in JavaScript objects, and how they are used. The next pages
will explain each built-in JavaScript object in detail.
Note that an object is just a special kind of data. An object has properties and methods.
5.9.2 Properties
Properties are the values associated with an object.
In the following example we are using the length property of the String object to return the number
of characters in a string:
var txt="Hello World!";
document.write(txt.length);
</script>
The output of the code above will be:

12
5.9.3 Methods
Methods are the actions that can be performed on objects.
In the following example we are using the toUpperCase() method of the String object to display a
text in uppercase letters:
var str="Hello world!";
document.write(str.toUpperCase());
</script>
The output of the code above will be:

HELLO WORLD!
5.10 javaScript built in objects
32
5 - javaScript
5.10.1 the String Object

The String object is used to manipulate a stored piece of text.
Properties
FF: Firefox, N: Netscape, IE: Internet Explorer
Property Description FF N IE
constructor A reference to the function that created the object 1 4 4
length Returns the number of characters in a string 1 2 3
prototype Allows you to add properties and methods to the object 1 2 4
Methods
Method Description FF N IE
anchor() Creates an HTML anchor 1 2 3
big() Displays a string in a big font 1 2 3
blink() Displays a blinking string 1 2
bold() Displays a string in bold 1 2 3
charAt() Returns the character at a specified position 1 2 3
charCodeAt() Returns the Unicode of the character at a specified position 1 4 4
concat() Joins two or more strings 1 4 4
fixed() Displays a string as teletype text 1 2 3
fontcolor() Displays a string in a specified color 1 2 3
fontsize() Displays a string in a specified size 1 2 3
fromCharCode() Takes the specified Unicode values and returns a string 1 4 4
indexOf() Returns the position of the first occurrence of a specified string 1 2 3
value in a string
italics() Displays a string in italic 1 2 3
lastIndexOf() Returns the position of the last occurrence of a specified string 1 2 3
value, searching backwards from the specified position in a
string
link() Displays a string as a hyperlink 1 2 3
match() Searches for a specified value in a string 1 4 4
replace() Replaces some characters with some other characters in a 1 4 4
string
search() Searches a string for a specified value 1 4 4
slice() Extracts a part of a string and returns the extracted part in a 1 4 4
new string
small() Displays a string in a small font 1 2 3
split() Splits a string into an array of strings 1 4 4
strike() Displays a string with a strikethrough 1 2 3
sub() Displays a string as subscript 1 2 3
substr() Extracts a specified number of characters in a string, from a 1 4 4
start index
33
5 - javaScript
substring() Extracts the characters in a string between two specified 1 2 3

indices
sup() Displays a string as superscript 1 2 3
toLowerCase() Displays a string in lowercase letters 1 2 3
toUpperCase() Displays a string in uppercase letters 1 2 3
toSource() Represents the source code of an object 1 4 -
valueOf() Returns the primitive value of a String object 1 2 4
5.10.2 the Date Object

The JavaScript Date object is used to work with dates and times.
Properties
constructor Returns a reference to the Date function that created the 1 4 4
object
Methods
Date() Returns today's date and time 1 2 3
getDate() Returns the day of the month from a Date object (from 1 2 3
1-31)
getDay() Returns the day of the week from a Date object (from 0-6) 1 2 3
getFullYear() Returns the year, as a four-digit number, from a Date 1 4 4
object
getHours() Returns the hour of a Date object (from 0-23) 1 2 3
getMilliseconds() Returns the milliseconds of a Date object (from 0-999) 1 4 4
getMinutes() Returns the minutes of a Date object (from 0-59) 1 2 3
getMonth() Returns the month from a Date object (from 0-11) 1 2 3
getSeconds() Returns the seconds of a Date object (from 0-59) 1 2 3
getTime() Returns the number of milliseconds since midnight Jan 1, 1 2 3
1970
getTimezoneOffset() Returns the difference in minutes between local time and 1 2 3
Greenwich Mean Time (GMT)
getUTCDate() Returns the day of the month from a Date object according 1 4 4
to universal time (from 1-31)
getUTCDay() Returns the day of the week from a Date object according 1 4 4
to universal time (from 0-6)
getUTCMonth() Returns the month from a Date object according to 1 4 4
universal time (from 0-11)
34
5 - javaScript
getUTCFullYear() Returns the four-digit year from a Date object according to 1 4 4

universal time
getUTCHours() Returns the hour of a Date object according to universal 1 4 4
time (from 0-23)
getUTCMinutes() Returns the minutes of a Date object according to 1 4 4
getUTCSeconds() Returns the seconds of a Date object according to 1 4 4
getUTCMilliseconds() Returns the milliseconds of a Date object according to 1 4 4
getYear() Returns the year, as a two-digit or a three/four-digit 1 2 3
number, depending on the browser. Use getFullYear()
instead !!
parse() Takes a date string and returns the number of milliseconds 1 2 3
since midnight of January 1, 1970
setDate() Sets the day of the month in a Date object (from 1-31) 1 2 3
setFullYear() Sets the year in a Date object (four digits) 1 4 4
setHours() Sets the hour in a Date object (from 0-23) 1 2 3
setMilliseconds() Sets the milliseconds in a Date object (from 0-999) 1 4 4
setMinutes() Set the minutes in a Date object (from 0-59) 1 2 3
setMonth() Sets the month in a Date object (from 0-11) 1 2 3
setSeconds() Sets the seconds in a Date object (from 0-59) 1 2 3
setTime() Calculates a date and time by adding or subtracting a 1 2 3
specified number of milliseconds to/from midnight January
1, 1970
setUTCDate() Sets the day of the month in a Date object according to 1 4 4
setUTCMonth() Sets the month in a Date object according to universal 1 4 4
time (from 0-11)
setUTCFullYear() Sets the year in a Date object according to universal time 1 4 4
(four digits)
setUTCHours() Sets the hour in a Date object according to universal time 1 4 4
(from 0-23)
setUTCMinutes() Set the minutes in a Date object according to universal 1 4 4
time (from 0-59)
setUTCSeconds() Set the seconds in a Date object according to universal 1 4 4
time (from 0-59)
setUTCMilliseconds() Sets the milliseconds in a Date object according to 1 4 4
setYear() Sets the year in the Date object (two or four digits). Use 1 2 3
setFullYear() instead !!
toDateString() Returns the date portion of a Date object in readable form
toGMTString() Converts a Date object, according to Greenwich time, to a 1 2 3
string. Use toUTCString() instead !!
toLocaleDateString() Converts a Date object, according to local time, to a string 1 4 4
and returns the date portion
35
5 - javaScript
toLocaleTimeString() Converts a Date object, according to local time, to a string 1 4 4

and returns the time portion
toLocaleString() Converts a Date object, according to local time, to a string 1 2 3
toString() Converts a Date object to a string 1 2 4
toTimeString() Returns the time portion of a Date object in readable form
toUTCString() Converts a Date object, according to universal time, to a 1 4 4
string
UTC() Takes a date and returns the number of milliseconds since 1 2 3
midnight of January 1, 1970 according to universal time
valueOf() Returns the primitive value of a Date object 1 2 4
5.10.3 the Array Object

The JavaScript Array object is used to store a set of values in a single variable name.
Properties
constructor Returns a reference to the array function that created the object 1 2 4
index 1 3 4
input 1 3 4
length Sets or returns the number of elements in an array 1 2 4
Methods
concat() Joins two or more arrays and returns the result 1 4 4
join() Puts all the elements of an array into a string. The elements are 1 3 4
separated by a specified delimiter
pop() Removes and returns the last element of an array 1 4 5.5
push() Adds one or more elements to the end of an array and returns 1 4 5.5
the new length
reverse() Reverses the order of the elements in an array 1 3 4
shift() Removes and returns the first element of an array 1 4 5.5
slice() Returns selected elements from an existing array 1 4 4
sort() Sorts the elements of an array 1 3 4
splice() Removes and adds new elements to an array 1 4 5.5
toString() Converts an array to a string and returns the result 1 3 4
unshift() Adds one or more elements to the beginning of an array and 1 4 6
returns the new length
36
5 - javaScript
valueOf() Returns the primitive value of an Array object 1 2 4
5.10.4 the Number Object

The Number object is an object wrapper for primitive numeric values.
Syntax for creating a new Number object.
var myNum=new Number(number);
Properties
FF: Firefox, IE: Internet Explorer
Property Description FF IE
constructor Returns a reference to the Number function that created the 1 4
object
MAX_VALUE Returns the largest possible value in JavaScript 1 4
MIN_VALUE Returns the smallest possible value in JavaScript 1 4
NaN Represents "Not-a-number" value 1 4
NEGATIVE_INFINITY Represents a value that is less than MIN_VALUE 1 4
POSITIVE_INFINITY Represents a value that is greater than MAX_VALUE 1 4
prototype Allows you to add properties and methods to the object 1 4
Methods
Method Description FF IE
toExponential() Converts the value of the object into an exponential notation 1 5.5
toFixed() Formats a number to the specified number of decimals 1 5.5
toLocaleString()
toPrecision() Converts a number into an exponential notation if it has more 1 5.5
digits than specified
toString() Converts the Number object into a string 1 4
valueOf() Returns the value of the Number object 1 4
5.10.5 the Boolean Object

The JavaScript Boolean object is an object wrapper for a Boolean value.
Properties
constructor Returns a reference to the Boolean function that created the 1 2 4
object
37
5 - javaScript
Methods
toSource() Returns the source code of the object 1 4 -
toString() Converts a Boolean value to a string and returns the result 1 4 4
valueOf() Returns the primitive value of a Boolean object 1 4 4
5.10.6 the Math Object

The JavaScript Math object allows you to perform common mathematical tasks. It includes
several mathematical constants and functions.
Properties
F
Property Description N IE
F
E Returns Euler's constant (approx. 2.718) 1 2 3
LN2 Returns the natural logarithm of 2 (approx. 0.693) 1 2 3
LN10 Returns the natural logarithm of 10 (approx. 2.302) 1 2 3
LOG2E Returns the base-2 logarithm of E (approx. 1.442) 1 2 3
LOG10E Returns the base-10 logarithm of E (approx. 0.434) 1 2 3
PI Returns PI (approx. 3.14159) 1 2 3
SQRT1_2 Returns the square root of 1/2 (approx. 0.707) 1 2 3
SQRT2 Returns the square root of 2 (approx. 1.414) 1 2 3
Methods
Method Description FF N I
E
abs(x) Returns the absolute value of a number 1 2 3
acos(x) Returns the arccosine of a number 1 2 3
asin(x) Returns the arcsine of a number 1 2 3
atan(x) Returns the arctangent of x as a numeric value between -PI/2 1 2 3
and PI/2 radians
atan2(y,x) Returns the angle theta of an (x,y) point as a numeric value 1 2 3
between -PI and PI radians
ceil(x) Returns the value of a number rounded upwards to the nearest 1 2 3
integer
cos(x) Returns the cosine of a number 1 2 3
exp(x) Returns the value of Ex 1 2 3
floor(x) Returns the value of a number rounded downwards to the 1 2 3
nearest integer
log(x) Returns the natural logarithm (base E) of a number 1 2 3
38
5 - javaScript
max(x,y) Returns the number with the highest value of x and y 1 2 3

min(x,y) Returns the number with the lowest value of x and y 1 2 3
pow(x,y) Returns the value of x to the power of y 1 2 3
random() Returns a random number between 0 and 1 1 2 3
round(x) Rounds a number to the nearest integer 1 2 3
sin(x) Returns the sine of a number 1 2 3
sqrt(x) Returns the square root of a number 1 2 3
tan(x) Returns the tangent of an angle 1 2 3
valueOf() Returns the primitive value of a Math object 1 2 4
5.11 how to create your own objects
An object is just a special kind of data, with a collection of properties and methods.
Let's illustrate with an example: A person is an object. Properties are the values associated with
the object. The persons' properties include name, height, weight, age, skin tone, eye color, etc. All
persons have these properties, but the values of those properties will differ from person to person.
Objects also have methods. Methods are the actions that can be performed on objects. The
persons' methods could be eat(), sleep(), work(), play(), etc.
5.11.1 Properties
The syntax for accessing a property of an object is:
objName.propName
You can add properties to an object by simply giving it a value. Assume that the personObj
already exists - you can give it properties named firstname, lastname, age, and eyecolor as
follows:
personObj.firstname="John";
personObj.lastname="Doe";
personObj.age=30;
personObj.eyecolor="blue";
document.write(personObj.firstname);
The code above will generate the following output:

John
5.11.2 Methods
An object can also contain methods.
You can call a method with the following syntax:
objName.methodName()
There are different ways to create a new object:
5.11.3 create a direct instance of an object

The following code creates an instance of an object and adds four properties to it:
39
5 - javaScript
personObj=new Object();
personObj.firstname="John";
personObj.lastname="Doe";
personObj.age=50;
personObj.eyecolor="blue";
Adding a method to the personObj is also simple. The following code adds a method called eat()
to the personObj:
personObj.eat=eat;
5.11.4 Create a template of an object

The template defines the structure of an object:
function person(firstname,lastname,age,eyecolor)
{
this.firstname=firstname;
this.lastname=lastname;
this.age=age;
this.eyecolor=eyecolor;
}
Notice that the template is just a function. Inside the function you need to assign things to
this.propertyName. The reason for all the "this" stuff is that you're going to have more than one
person at a time (which person you're dealing with must be clear). That's what "this" is: the
instance of the object at hand.
Once you have the template, you can create new instances of the object, like this:
myFather=new person("John","Doe",50,"blue");
myMother=new person("Sally","Rally",48,"green");
You can also add some methods to the person object. This is also done inside the template:
function person(firstname,lastname,age,eyecolor)
{
this.firstname=firstname;
this.lastname=lastname;
this.age=age;
this.eyecolor=eyecolor;
this.newlastname=newlastname;
}
Note that methods are just functions attached to objects. Then we will have to write the
newlastname() function:
function newlastname(new_lastname)
{
this.lastname=new_lastname;
}
40
5 - javaScript
The newlastname() function defines the person's new last name and assigns that to the person.
JavaScript knows which person you're talking about by using "this.". So, now you can write:
myMother.newlastname("Doe").
5.12 JavaScript Events
New to HTML 4.0 was the ability to let HTML events trigger actions in the browser, like starting a
JavaScript when a user clicks on an HTML element.
Every element on a web page has certain events which can trigger JavaScript functions. For
example, we can use the onClick event of a button element to indicate that a function will run
when a user clicks on the button. We define the events in the HTML tags.
Examples of events:
● A mouse click
● A web page or an image loading
● Mousing over a hot spot on the web page
● Selecting an input box in an HTML form
● Submitting an HTML form
● A keystroke
Note: Events are normally used in combination with functions, and the function will not be
executed before the event occurs!
Tne following table contains an exhaustive list of events together with the support version of
FireFox, Netscape an Internet Explorer for each such event.
Event The event occurs when... FF N IE

onabort Loading of an image is interrupted 1 3 4
onblur An element loses focus 1 2 3
onchange The user changes the content of a field 1 2 3
onclick Mouse clicks an object 1 2 3
ondblclick Mouse double-clicks an object 1 4 4
onerror An error occurs when loading a document or an image 1 3 4
onfocus An element gets focus 1 2 3
onkeydown A keyboard key is pressed 1 4 3
onkeypress A keyboard key is pressed or held down 1 4 3
onkeyup A keyboard key is released 1 4 3
onload A page or an image is finished loading 1 2 3
onmousedown A mouse button is pressed 1 4 4
onmousemove The mouse is moved 1 6 3
onmouseout The mouse is moved off an element 1 4 4
41
5 - javaScript
onmouseover The mouse is moved over an element 1 2 3

onmouseup A mouse button is released 1 4 4
onreset The reset button is clicked 1 3 4
onresize A window or frame is resized 1 4 4
onselect Text is selected 1 2 3
onsubmit The submit button is clicked 1 2 3
onunload The user exits the page 1 2 3
5.12.1 onload and onUnload

The onload and onUnload events are triggered when the user enters or leaves the page.
The onload event is often used to check the visitor's browser type and browser version, and load
the proper version of the web page based on the information.
Both the onload and onUnload events are also often used to deal with cookies that should be set
when a user enters or leaves a page. For example, you could have a popup asking for the user's
name upon his first arrival to your page. The name is then stored in a cookie. Next time the visitor
arrives at your page, you could have another popup saying something like: "Welcome John Doe!".
5.12.2 onFocus, onBlur and onChange

The onFocus, onBlur and onChange events are often used in combination with validation of form
fields.
Below is an example of how to use the onChange event. The checkEmail() function will be called
whenever the user changes the content of the field:
<input type="text" size="30" id="email" onchange="checkEmail()">;
5.12.3 onSubmit
The onSubmit event is used to validate ALL form fields before submitting it.
Below is an example of how to use the onSubmit event. The checkForm() function will be called
when the user clicks the submit button in the form. If the field values are not accepted, the submit
should be cancelled. The function checkForm() returns either true or false. If it returns true the
form will be submitted, otherwise the submit will be cancelled:
<form method="post" action="xxx.htm" onsubmit="return checkForm()">
5.12.4 onMouseOver and onMouseOut

onMouseOver and onMouseOut are often used to create "animated" buttons.
Below is an example of an onMouseOver event. An alert box appears when an onMouseOver
event is detected:
<a href="http://www.w3schools.com" onmouseover="alert('An onMouseOver
event');return false">
<img src="w3schools.gif" width="100" height="30"> </a>
42
5 - javaScript
5.13 HTML DOM Objects
In addition to the built-in JavaScript objects, you can also access and manipulate all of the HTML
DOM objects with JavaScript. Besides the generic objects listed bellow, the bulk of the HTML
DOM objects will be discussed in the next chapter.
Object Description
Window The top level object in the JavaScript hierarchy. The Window object
represents a browser window. A Window object is created automatically
with every instance of a <body> or <frameset> tag
Navigator Contains information about the client's browser
Screen Contains information about the client's display screen
History Contains the visited URLs in the browser window
Location Contains information about the current URL
43
6 - Html dom
6 - HTML DOM
44
7 - AJAX
7 - AJAX
7.1 what is ajax?
Ajax is only a name given to a set of tools that were previously existing. It is not a
technology in itself, but rather a collection of technologies bound together by JavaScript.
• Html and CSS for presenting.

• JavaScript (ECMAScript) for local processing, and DOM (Document Object
Model) to access data inside the page or to access elements of Xml file read on
the server (with the getElementByTagName method for example)...
• The XMLHttpRequest class read or send data on the server asynchronously.
optionally...
• The DomParser class may be used
• PHP or another scripting language may be used on the server.
• XML and XSLT to process the data if returned in Xml form.
• SOAP may be used to dialog with the server.
The "Asynchronous" word, means that the response of the server while be processed
when available, without to wait and to freeze the display of the page.
7.2 the XMLHttpRequest class
Allows to interact with the servers, thanks to its methods and attributes.
Attributes
ReadyState the code successively changes value from 0 to 4 that means for "ready".
200 is ok
Status
404 if the page is not found.
ResponseText Holds loaded data as a string of characters.
ResponseXml Holds a Xml loaded file, DOM's method allows to extract data.
Onreadystatechange Onreadystatechange
Methods
mode: type of request, GET or POST
Open(mode, url, url: the location of the file, with a path.
boolean) boolean: true (asynchronous) / false (synchrous).
Optionally, a login and a password may be added to arguments.
Send("string") null for a GET command.
45
7 - AJAX
7.3 the ajax toolkit framework

It is an Eclipse add-on that provides tools for building IDE for Ajax runtimes, and testing Ajax
applications. This toolkit uses XULRunner, the Xul runtime, for embedding Gecko, the Html
displayer in Eclipse.
7.4 drawbacks of ajax

● If JavaScript is not activated, Ajax can't work. The user must be asked to set JavaScript
from within options of the browser, with the "noscript" tag.
● Since data to display are loaded dynamically, they are not part of the page, and the
keywords inside are not used by search engines.
● The asynchronous mode may change the page with delays (when the processing on the
server take some times), this may be disturbing.
● The back button may be deactivated (this is not the case in examples provided here).
7.5 specifications
Ajax is based on these specifications:
● XML 1, HTML 4.0, DOM 2, from W3C
● ECMAScript 1.5 (standard for JavaScript) from ECMA
● W3C draft specification for XMLHttpRequest.
46
8 - WEB APPLICATIONS
8.1 the structure of a web application
A web application is a collection of Java servlets, JSP pages, other helper classes and class
libraries, other static resources (HTML, images, etc.) and an xml file, the deployment descriptor.
A web application consists of 4 parts:
1. a public directory – containing html, jsp files and other public resources. This is the root
directory of the application.
2. a WEB-INF/web.xml file – the deployment descriptor.
3. a WEB-INF/classes directory.
4. a WEB-INF/lib directory.
Example:
Assume that we use a Tomcat web server and that the environment variable
%TOMCAT_HOME% is set to C:\TW\Tomcat. Then, the root directory of some web application
can be:
C:\TW\Tomcat\webapps\bank11\ccards
and the mandatory directories are:
C:\TW\Tomcat\webapps\bank11\ccards\WEB-INF\classes
C:\TW\Tomcat\webapps\bank11\ccards\WEB-INF\lib
8.2 web containers
A web container is a Java runtime providing implementation of the Java servlet API and some
other facilities to the JSP pages. It responsible for initializing, invoking and managing the life
cycle of servlets and JSPs.
A web container may either implement the basic HTTP services or delegates these services to
an external web server.
Web containers can be part of an application or web server or a separate runtime. Here is a
description of these situations.
• web container in a J2EE application server. Commercial implementations of the J2EE

specifications, like WebLogic, Inprise Application Server or IBM's WebSphere include web
containers.
• web container built into web servers. Most known cases are the Sun's Java WebServer and
the Jakarta Tomcat web server (which will be used in our applications).
• web container as a separate runtime. Some web servers, like Apache or IIS require a
separate runtime to run servlets and a web server plug-in to integrate this Java runtime with
47
the web server. Typical integration scenarios are Tomcat with Apache and JRun (of Allaire)
with most of the J2EE application servers.
Web Application Web Application
Java Servlets Java Servlets
JSP Pages JSP Pages
JavaServer Faces JavaServer Faces
Java
Classes
Deployment descriptor Deployment descriptor
J2EE Web Container
8.3 deployment descriptor
The deployment descriptor is an xml file (namely, web.xml) which allows the customization of
the web application at deployment time.
The deployment descriptor serves several purposes, like:
1. Initialization of parameters for servlets, JSPs and JavaServer Faces.
2. Servlet, JSPs and JavaServer Faces definitions, servlet classes, precompiled JSP entities are
declared (names, classes, descriptions).
3. Servlet, JSPs and JavaServer Faces mappings.
4. MIME types used by the web application.
5. Security related entries – may specify which pages require login and the roles different users
may have.
48
6. Others, like what pages are error, welcome pages, entries related to session configuration.
Here is a small, but typical web.xml file:
<?xml version="1.0" encoding="ISO-8859-1" ?>

<!DOCTYPE web-app (View Source for full doctype...)>
<web-app>

<servlet>
<servlet-name>Login</servlet-name>
<servlet- class>com.bank11.ccards.servlets.LoginServlet
</servlet-class>
</servlet>
</web-app>
8.4 practical deployment issues
There are several issues with the web applications deployment. Behind a very benign URL, like
"http://localhost:8080/ccards/servlet/Enroll" there are 3 things which have to be fixed in order to
make things work properly.
Assume that we work with Tomcat and that the environment variable %TOMCAT_HOME% (or
$TOMCAT_HOME, in an UNIX environment) is set to "C:\TW\Tomcat".
1. The "/servlet" part of the URL tells the web server (Tomcat, in our case) to execute the
invoker servlet. This association is made in the file "%TOMCAT_HOME%\conf\web.xml".
Unfortunately, the lines which deal with this issue are commented out in the latest version
of Tomcat (for so-called "security issues"). To make anything work:
• de-comment the following section:
<servlet-mapping>
<servlet-name>invoker</servlet-name>
<url-pattern>/servlet/*</url-pattern>
</servlet-mapping>
in the configuration file "%TOMCAT_HOME%\conf\web.xml"
2. The "/ccards" part of the URL is, basicly, the name of the web application. In general, the
base directory of an application is a subdirectory of the "%TOMCAT_HOME%\webapps"
directory. This subdirectory has (in general) the same name as the application itself.
However, for flexibility, the location of the base directory of a web application may be any
sub(sub)directory of "%TOMCAT_HOME%\webapps". The association between the name
of the web application and the location of its base directory is made by a <context>
element in the "%TOMCAT_HOME%\conf\server.xml" file. For example, if the base
directory of the "/ccards" web application is "%TOMCAT_HOME
%\webapps\vdumitrascu\cc", then the corresponding <context> element in the
"%TOMCAT_HOME%\conf\server.xml" file looks like:
49
<context path="/ccards" docbase="vdumitrascu/cc" />
3. The "/Enroll" part of the URL identifies the servlet. Basicly, it is the alias of the real servlet
class, whose name is rather long. Let's say that this class is "EnrollServlet.class" and that it
is part of the package "com.bank11.ccards.servlets". Then the "EnrollServlet.class" file
must be located in the directory "%TOMCAT_HOME%\webapps\vdumitrascu\cc\WEB-INF\
classes\com.bank11.ccards.servlets". This association between the (short) alias of the
servlet and its real (long) name is made in the web.xml file of the web application. More
exactly the corresponding <servlet> element should look like:
<servlet>
<servlet-name>Enroll</servlet-name>
<servlet-class>
com.bank11.ccards.servlets.EnrollServlet
</servlet-class>
</servlet>
50
9 - SERVLETS
9 - SERVLETS
9.1 the servlets as part of web applications
Java servlets – small, platform independent programs, which extend the functionality of the
web server.
Technically speaking, a servlet is a Java class that extends the GenericServlet (or, more often,
the HttpServlet) class.
The Java servlet API provides a simple frame for building web applications on web servers.
The current Java Servlet specification (as of 10.2007) is 2.5 and is in maintenance state.
Version 2.4 of the specification is in its final state. Java EE 5 SDK contains an implementation of
the Java Servlet 2.5 specification.
9.2 servlet packages and classes
The Java servlet API consists of 2 packages, which are part of the J2 SDK, Enterprise Edition.
These packages are:
• javax.servlet
• javax.servlet.http
The classes and interfaces defined in the javax.servlet package are protocol independent, while
the second one, the javax.servlet.http contains classes and interfaces which are HTTP specific.
The classes an interfaces of the Java servlet API can be divided in several categories, namely:
• servlet implementation
• servlet configuration
• servlet exceptions
• request and responses
• session tracking
• servlet context
• servlet collaboration
• miscellaneous
9.3 the Servlet interface
The Servlet interface is part of the javax.servlet package. It declares the following
methods:
51
9 - SERVLETS
public void init(ServletConfig config) throws ServletException;

public void service(ServletRequest req, ServletResponse resp) throws
ServletException, IOException;
public void destroy() throws ServletException;
public ServletConfig getServletConfig();
public String getServletInfo();
After instantiating the servlet, the web container calls its init() method. The method
performs all initialization required, before the servlet processes any HTTP request. The servlet
specification insures that the init() method is called just once for any given instance of the
servlet.
The web container calls the service() method in response to any incoming request. This
method has two arguments, arguments which implement the ServletRequest and
ServletResponse interfaces, respectively.
More on the servlet lifecycle, in a different section.
9.4 the GenericServlet class
public abstract class GenericServlet implements

Servlet, ServletConfig, Serializable
This class provides a basic implementation of the Servlet interface. Since this class
implements the ServletConfig interface, as well, the developer may call ServletConfig
methods directly, without having to obtain a ServletConfig object first. All classes extending
the GenericServlet class should provide an implementation for the service() method.
Methods specific to this class:
public void init()

public void log(String msg)
public void log(String msg, Throwable t)
9.5 the HttpServlet class
It is very likely that the only implementation of the Servlet interface we'll ever use is one that
processes an HTTP request. The servlet API provides such a specific class, namely the
HttpServlet class.
public abstract class HttpServlet extends GenericServlet implements

Serializable
52
9 - SERVLETS
The HttpServlet provides an HTTP specific implementation of the Servlet interface. This
abstract class specifies the following methods:
public void service(ServletRequest req, ServletResponse resp)

public void service(HttpServletRequest req, HttpServletResponse resp)
protected void doGet(HttpServletRequest req, HttpServletResponse resp)

protected void doPost(HttpServletRequest req, HttpServletResponse
resp)
protected void doDelete(HttpServletRequest req, HttpServletResponse
resp)
protected void doOptions(HttpServletRequest req, HttpServletResponse
resp)
protected void doPut(HttpServletRequest req, HttpServletResponse resp)
protected void doTrace(HttpServletRequest req, HttpServletResponse
resp)
9.6 the ServletConfig interface
This interface abstracts configuration information about the servlet, namely:

• initialization parameters (as name-value pairs)
• the name of the servlet
• a ServletContext object, containing web container information
This interface specifies the following methods:
public String getInitParameter(String name)

public Enumeration getInitParameterNames()
public ServletContext getServletContext()
public String getServletName()
9.7 servlet exceptions
The Java servlet API specifies two servlet specific exceptions:
javax.servlet.ServletException
javax.servlet.UnavailableException
The ServletException class extends java.lang.Exception and can be thrown by the

init(), service(), doXXX() and destroy() methods of the Servlet interface
implementations.
53
9 - SERVLETS
The UnavailableException indicates to the web container that the servlet instance is
unavaialble. It also extends the java.lang.Exception class.
9.8 the servlet lifecycle
Generally, a servlet instance goes through the following stages:

• instantiation
• initialization
• service
• destroy
• unavailable
The container creates a servlet instance as first response to an incoming (HTTP) request or at
container startup. Typically, the web container creates a single instance of the servlet, which will
service all incoming requests. If the servlet does not implement the
javax.servlet.SingleThreadModel, concurrent requests are serviced in more than one
service thread, which requires that the service() method be thread safe.
After instantiation, the container calls the init() method of the servlet, method which
performs the initialization of the servlet. Typically, this method contains JDBC driver loading, DB
connection opening, etc.
The web container makes sure that the init() method of the servlet will be completed before
invoking its service() method. Also, the servlet's destroy() method will be called before the
servlet itself is destroyed.
9.9 the ServletRequest interface
Here are some of the methods of this interface:
public Object getAttribute(String name)

public Object setAttribute(String name, Object attr) public
Enumeration getAttributeNames()
public int getContentLength()
public String getContentType()
public String getParameter(String name)
public Enumeration getParameterNames()
public Enumeration getParameterValues()
public String getServerName()
public int getServerPort()
public String getRemoteAddr()
public String getRemoteHost()
Most of the above methods are self explanatory. But what is the difference between a
parameter and an attribute? While the parameters of the request are part of the request itself, the
attributes of the request are attached by the web containers or by the servlets/JSPs.
54
9 - SERVLETS
There are 3 different ways for attaching and retrieving attributes. The first one is to attach
attributes to the request object. The other two use the HttpSession and ServletContext objects,
respectively. The purpose of attributes is to allow the container to provide additional data to a
servlet or JSP or to allow sending data from a servlet to another.
9.10 the HttpServletRequest interface
public interface HttpServletRequest extends ServletRequest
This interface contains HTTP specific methods. One has to take in account the structure of an
HTTP request when overviewing the most important methods of this interface. Here are some of
them:
public Cookie[] getCookies()

public long getDateHeader()
public String getHeader(String name)
public Enumeration getHeaders(String name)
public Enumeration getHeaderNames()
public String getContextPath()
public String getPathInfo()
public String getQueryString()
public String getRemoteUser()
9.11 the ServletResponse interface
This interface defines methods for constructing responses to servlet requests.

Here are the most important ones:
public ServletOutputStream getOutputStream()

public PrintWriter getWriter()
public void setContentLength(int len)
public void setContentType(String type)
public void setBufferSize(int size)
public int getBufferSize()
public void flushBuffer()
55
9 - SERVLETS
9.12 the HttpServletResponse interface
This interface extends the ServletResponse interface and defines methods specific for
constructing responses to HTTP requests.
Here are the most important ones:
public void addCookie(Cookie cookie)

public String encodeURL(String url)
public void sendError(int status)
public void sendError(int status, String message)
public void setHeader(String headerName, String value)
public void addHeader(String headerName, String value)
public void setStatus(int statusCode)
9.13 the ServletContext interface
A servlet context defines servlet's view of the web application and provides access to resources
common to all servlets of the web application. Each servlet context is rooted at a specific path in
the web server. The deployment of a web application involves adding an application specific
<context> tag which associates the the name of the application with its root directory. This is
done in server's (container's) server.xml file.
The ServletContext interface abstracts the context of a web application. A reference to an
object of this type can be obtained by invoking the getServletContext() method of the
HttpServlet object.
public String getMIMEType(String fileName)

public String getResource(String path)
public ServletContext getContext(String urlPath)
public String getInitParameter(String name)
public Enumeration getInitParameterNames()
public Object getAttribute(String name)
public Enumeration getAttributeNames()
public void setAttribute(String name, Object attr)
public String removeAttribute(String name)
9.14 the Enroll servlet
The Enroll servlet services the request sent by the web browser when we submit the Enroll form
56
9 - SERVLETS
(file Enroll.html)
Here is its abbreviated form (topics which are DB related are postponed) of the
"EnrollServlet.java" file:
package com.bank11.ccards.servlets;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class EnrollServlet extends HttpServlet

{
public void init(ServletConfig config)
throws ServletException
{
super.init(config);
}
public void doPost(HttpServletRequest req,
HttpServletResponse resp)
throws ServletException, IOException
{
resp.setContentType(“text/html”);
PrintWriter out = resp.getWriter();
// output your page here
out.println("<html>");
out.println("<head>");
out.println("<title>Servlet</title>");
out.println("</head>");
out.println("<body>");
out.println("merge");
out.println("<br>");
out.println("</body>");
out.println("</html>");
out.close();
}
}
57
10 - JDBC
10 - JDBC
10.1 what is jdbc?
JDBC stands for Java Data Base Connectivity and is the Java version of ODBC (Open Data
Base Connectivity). It offers an API for SQL-compliant relational databases access. It abstracts
the vendor-specific details and offers support for the most common database access functions.
10.2 jdbc drivers
Each database vendor offers its own version of DB access API. A JDBC driver is a middleware
layer that translates JDBC calls into vendor specific calls. These drivers fall into four standard
categories, as recognised by the DB industry.
Type 1. JDBC – ODBC Bridge

The driver translates the JDBC calls into equivalent ODBC calls. Both the JDBC and the JDBC-
ODBC calls are invoked within the client application. This solution is inefficient, due to the
multiple layers of indirection involved and to the limitations imposed to the JDBC layer by the
ODBC frame.
The standard JDK includes all the classes for this bridge , namely
sun.jdbc.odbc.JdbcOdbcDriver .
Java app Data

source
JDBC JDBC-ODBC ODBC ODBC

API bridge API layer
Type 2. Part Java, Part Native Driver

The drivers in this category use a combination of Java implementation and vendor specific
APIs for DB access. The driver translates JDBC specific calls into vendor specific API calls. The
DB returns the result of the call to the API, which in turn, forwards them to the JDBC driver. It is
much faster than the Type 1 drivers, because it eliminates one level of indirection.
58
10 - JDBC
Java app Data

source
JDBC JDBC Vendor

API driver API
Type 3. Intermediate Database Access Server

Type 3 drivers are DataBase servers which act as intermediate tier between multiple clients and
multible Database servers. The client application sends a JDBC call through a JDBC driver to the
intermediate Database servers. These servers translate the call into a native driver call which
handles the actual DB connection. This type of drivers are implemented by several application
servers, like WebLogic (of BEA) or Inprise Application Server (of Borland).
Java app Data

source
JDBC JDBC JDBC driver Native

API driver server driver
Type 4. Pure Java Drivers

These are the most efficient drivers. The JDBC API calls are converted to direct network calls
using vendor provided protocols. All major vendors provide type 4 JDBC drivers for their
Database products.
Java app Data

source
JDBC JDBC
API driver
59
10 - JDBC
For an extensive list of JDBC drivers, check the site:

http://industry.java.sun.com/products.j/jdbc/drivers .
10.3 connecting to a database
There are two main steps in connecting to an existing database. The first one is
loading a database driver.
A database driver is specified by the driver name. Here are some examples of actual database
driver names:
• com.borland.datastore.jdbc.DataStoreDriver
• com.sybase.jdbc.SybDriver
• com.ibm.db2.jdbc.net.DB2Driver
• oracle.jdbc.driver.OracleDriver
• sun.jdbc.odbc.JdbcOdbcDriver
The Java code to load the driver name is somewhat obscure, but let's take it for granted:
import java.sql.*;
import java.util.*;
try
{
Class.forName("org.gjt.mm.mysql.Driver").newInstance();
} catch (Exception e) {
// driver not found
e.printStackTrace();
}
The actual location of the database is specified by its URL (also known as connection URL).
The driver URL has 3 parts separated by colons, as follows:
jdbc:<subprotocol>:subname
• jdbc is the protocol name (actually, the only protocol allowed in JDBC).
• the sub-protocol is used to identify the JDBC driver, as specified by the driver vendor.
• subname – the syntax of this field is vendor specific and allows the identification
Here are some examples of JDBC driver URLs:
• jdbc:sybase:localhost:2025
• jdbc:db2://db2.bank11.com:50002/ccards
• jdbc:oracle:thin:@loclahost:1521:ORCL
60
10 - JDBC
The second step in connecting to an existing database is to open the connection, by using the
connection URL.
Here is some sample code which shows how this is done:
String connURL = "jdbc:mysql://localhost:3306/ccards";

String user = "root";
String passwd = "root"
Connection conn = DriverManager.getConnection(connURL,
user, passwd);
Since we just used it, let's have a better look in the next section at the DriverManager class.
10.4 the DriverManager class
This class belongs to the javax.sql package and offers a common access layer on top of
different JDBC drivers. Each driver used by the application must be registered (loaded) before the
DriverManager class tries to obtain a connection.
There are 3 versions of the getConnection() method of the DriverManager class. Here
they are:
public static Connection getConnection(String connURL)

throws SQLException
public static Connection getConnection(String connURL, String user,
String passwd) throws SQLException
public static Connection getConnection(String connURL,
java.util.Properties info) throws SQLException
While the first two forms of getConnection() are pretty straightforward, let's see an example of
hou to use the last of the three forms.
Properties prp = new Properties();

prp.put("autocommit", "true");
prp.put("create", "true");
Connection conn = DriverManager.getConnection(connURL, prp);
10.5 the Connection interface
The Connection interface is part of then javax.sql package. Once we get the hold of a
Connection object, we can use it for various purposes, but we will restrict ourselves to creating
SQL statements. Public methods for creating statements:
61
10 - JDBC
Statement createStatement() throws SQLException

Statement createStatement(int resultType, int resultSetConcurrency)
throws SQLException
PreparedStatement prepareStatement(String sql)
throws SQLException
CallableStatement prepareCall(String sql)
throws SQLException
10.6 statement interfaces
The objects we encountered in the previous section , namely, Statement,

PreparedStatement and CallableStatement abstract regular SQL statements, prepared
statements and stored procedures, respectively.
The Statement interface has (among others) the following methods:
1. methods for executing statements:

• execute()
• executeQuery()
• executeUpdate()
2. methods for batch updates:

• addBatch()
• executeBatch()
• clearBatch()
3. methods for result set fetch size and direction:

• setFetchSize()
• getFetchSize()
• setFetchDirection()
• getFetchDirection()
4. method to get the current result set:

• getResultSet()
5. methods for result set concurrency and type:

• getResultSetConcurrency()
• getResultSetType()
62
10 - JDBC
6. other methods:
• setQueryTimeout()
• getQueryTimeout()
• setMaxFieldSize()
• getMaxFieldSize()
• cancel()
• getConnection()
The Statement interfaces also support the same methods for transaction support as the
Connection objects.
Objects implementing the Connection interface are mainly used for SQL queries execution.
Here is a typical example:
Statement stmt = conn.createStatement();

String sqlString = "CREATE TABLE customer ...";
stmt.executeUpdate(sqlString);
10.7 the ResultSet interface
The result of a query by a Statement object is a java.sql.ResultSet object which is

available to the user and allows access to the data retrieved. The interface ResultSet is
implemented by driver vendors.
Methods to retrieve data:

• getAsciiStream()
• getBoolean()
• getDate()
• getInt()
• getShort()
• getTimeStamp()
• getBinaryStream()
• getBytes()
• getFloat()
• getObject()
• getTime()
• getString()
• getByte()
63
10 - JDBC
• getDouble()
• getLong()
• getBigDecimal()
• getMetaData()
• getClob()
• getWarnings()
• getBlob()
Most of these methods require the column index (which in SQL starts at 1, not at 0) or the
column name, as the argument.
The usage of these rertrieval methods assumes the prior knowledge of the type and the index
(or name) of a particular column. What if we don't have this knowledge? Fortunately, all this data
about the DB schema (or metadata) can be retrieved using the ResultSetMetaData interface.
The invokation of the getMetaData() method of a ResultSet object returns an object of
ResultSetMetaData type.
Here are the most important methods specified by the ResultSetMetaData interface:
• getCatalogName()
• getTableName()
• getSchemaName()
• getColumnCount()
• getColumnName()
• getColumnLabel()
• getColumnType()
• getColumnTypeName()
• getColumnClassName()
• getColumnDisplaySize()
• getScale()
• getPrecision()
• isNullable()
• isCurrency()
• isSearchable()
• isCaseSensitive()
• isSigned()
• isAutoIncrement()
• isReadOnly()
• isDefinitelyWritable()
10.8 the PreparedStatement interface
64
10 - JDBC
If an SQL statement is used several times and its different forms differ only with respect to the
data they specify, a better choice is the usage of a PreparedStatement object. Prepared
statements are parametrized and each parameter (usually, a field (column) value or name) is
represented by a question mark '?'.
The following lines of Java code give an example of how to use PreparedStatement objects:
Statement stmt = con.createStatement();

PreparedStatement pstmt = con.prepareStatement("INSERT INTO customer
VALUES (?, ?, ?)");
stmt.executeUpdate("CREATE TABLE customer (id int, firstName
varchar(32) lastName varchar(24))");
// set parameters for preparedStatement
pstmt.setInt(1, 1021);
pstmt.setString(2, "Vasile");
pstmt.setString(3, "Dumitrascu");
int count = pstmt.executeUpdate();
10.9 jdbc and sql types and their corresponding java classes
JDBC Type Purpose SQL Type Java Type

ARRAY SQL array ARRAY java.sql.Array
BIGINT 64 bit integer BIGINT long
BINARY binary value none byte[]
BIT one bit value BIT boolean
BLOB binary large object BLOB java.sql.Blob
CHAR char string CHAR String
CLOB character large object CLOB java.sql.Clob
DATE day, month, year DATE java.sql.Date
DECIMAL decimal value DECIMAL java.math.Big
Decimal
DISTINCT distinct DISTINCT none
DOUBLE double precision DOUBLE PRECISION double
FLOAT double precision FLOAT double
INTEGER 32 bit integer INTEGER int
JAVA_OBJECT stores Java objects none Object
LONGVARBINARY variable length binary none byte[]
value
LONGVARCHAR variable length char string none String
NULL null values NULL null
65
10 - JDBC
JDBC Type Purpose SQL Type Java Type

NUMERIC decimal value NUMERIC java.math.Big
Decimal
OTHER db specific types none Object
REAL single precision REAL float
REF
SMALLINT 16 bit integer SMALLINT short
STRUCT
TIME hrs, mins, secs TIME java.sql.Time
TIMESTAMP date, time, nanoseconds TIMESTAMP java.sql.Times
tamp
TINYINT 8 bit integer TINYINT short
VARBINARY variable length binary none byte[]
value
VARCHAR variable length char string VARCHAR String
10.10 JDBC Data Sources
In the JDBC 2.0 optional package, the DriverManager interface is replaced by the
DataSource interface as main method of obtaining DB connections.
While the DriverManager interface was used at run time to load explicitly a JDBC driver, the
new mechanism uses a centralized JNDI service to locate a javax.sql.DataSource object.
This interface is, basicly, a factory for creating DB connections. It is part of the javax.sql
package.
Main methods:
public Connection getConnection() throws SQLException

public Connection getConnection(String user, String pwd) throws
SQLException
66
11 - JSP
11 - JSP
11.1 java server pages as part of web applications
A Java Server Page (JSP) is a standard HTML or XML file which contains new scripting tags.
A JSP is loaded by a JSP container and is converted (to servlet code). If the JSP is modified,
the servlet code is regenerated.
The current JSP specification is JSP 2.1 and is related to the 2.5 Java Servlet specification.
The JSP specific interfaces, classes and exceptions are part of two packages, namely
javax.servlet.jsp and javax.servlet.jsp.tagext.
The javax.servlet.jsp package contains a number of classes and interfaces that describe and
define the contracts between a JSP page implementation class and the runtime environment
provided for an instance of such a class by a conforming JSP container.
The package javax.servlet.jsp defines two interfaces – JspPage and HttpJspPage. The
interface HttpJspPage is the interface that a JSP processor-generated class for the HTTP protocol
must satisfy. The JspPage interface is the interface that a JSP processor-generated class must
satisfy.
The package javax.servlet.jsp.tagext contains classes and interfaces for the definition of
JavaServer Pages Tag Libraries.
11.2 java beans
A java bean is a java class which:
• implements the java.io.Serializable interface

• provides a no-argument constructor
• for each of its properties, provides get and set methods
• implements a property change mechanism
Here is a typical example of a java bean.
/*
* NewBean.java
*/
import java.beans.*;
import java.io.Serializable;
/**
* @author sm
*/
public class NewBean extends Object implements Serializable {
67
11 - JSP
public static final String PROP_SAMPLE_PROPERTY =

"sampleProperty";
private String sampleProperty;
private PropertyChangeSupport propertySupport;
public NewBean() {
propertySupport = new PropertyChangeSupport(this);
}
public String getSampleProperty() {

return sampleProperty;
}
public void setSampleProperty(String value) {

String oldValue = sampleProperty;
sampleProperty = value;
propertySupport.firePropertyChange(PROP_SAMPLE_PROPERTY,
oldValue, sampleProperty);
}
public void addPropertyChangeListener(PropertyChangeListener

listener) {
propertySupport.addPropertyChangeListener(listener);
}
public void removePropertyChangeListener(PropertyChangeListener

listener) {
propertySupport.removePropertyChangeListener(listener);
}
}
11.3 the java.servlet.jsp.JspPage interface
This interface has 2 methods:
public void jspInit()

public void jspDestroy()
The javax.servlet.HttpJspPage interface has a single method:
public void jspService(HttpServletRequest req,

HttpServletResponse resp) throws ServletException, IOException
The implementation of this method is generated by the web container – never by the developer.
68
11 - JSP
11.4 jsp tags
There are 3 categories of JSP tags (elements):
1. directives – affect the structure of the whole jsp

2. scripting elements – java code inserted in the JSP page
3. actions – special tags affecting the run time behaviour of the JSP
Rules for JSP tags:

• attribute values are always quoted (single or double quotes)
• URLs follow the servlet conventions
• if the URL does not start with / , it is interpreted relative to the position of the current JSP
11.5 jsp directives
The JSP directives are messages sent by the Java Server Page to the JSP container. These
directives do not produce any client output and affect the whole JSP file.
The general format of a JSP directive is as follows:

<%@directive_name attr1="val1" ... attrn="valn" %>
Ther are three JSP directives: page, include and taglib.
The page directive format:

<%@page attr1="val1" ... %>
attributes:
• language – values: "java"
• extends – superclass of the generated class
• import – list of packages classes
• session – "true" or "false", the implicit session object is available
• buffer – buffering model for the output stream
• autoflush – if "true", the buffer is flushed automatically if full
• isThreadSafe – "true" or "false"
• isErrorPage – "true" or "false"
• contentType – MIME type of the response
• info
• errorPage – the URL of an error page, in case of error
69
11 - JSP
The include directive instructs the container to include inline the content of the resource
specified by "fileName". The format of this directive:
<%@include file="fileName" %>
The taglib directive allows the usage of custom tags (tag extensions). It has the following
format:
<%@taglib uri="tagLibUri" prefix="tagPrefix" %>
where the tagPrefix indicates a name scope.
11.6 scripting elements
11.6.1 declarations
<%! java vars and method declarations %>
Basicly, a bloc of java code used to define class-wide variables and methods in the generated
servlet.
11.6.2 scriptlets
<% valid java statements %>
Block of java code which is executed during request processing. In Tomcat, this code goes to
inside the service() method.
11.6.3 expressions
<%= java expressions to be evaluated %>
A scriptlet that sends a value of a Java expression to back to the client. It is evaluated at
request processing time and the result is converted to a string which is then displayed.
11.6.4 standard actions
70
11 - JSP
Tags that affect the runtime behaviour of the JSP and the response to the client. A tag can be
embedded into a JSP page. The standard actions are detailed in the next paragraphs.
11.7 the useBean standard action
<jsp:useBean>
Used to instantiate a Java bean or locate a bean instance. Assigns it to available name or id.
The syntax for this action is:

<jsp:useBean id="beanName" scope="sName" beandetails />
where beandetails is one of the following:

• class="className"
• class="className" type="typeName"
• beanName="beanName" type="typeName"
• type="typeName"
11.8 the setProperty standard action
<jsp:setProperty>
Used in conjunction with the <jsp:useBean> action to set the value of the bean properties.

<jsp:setProperty name="beanName" propertydetails />
where propertydetails is one of the following:

• property="*"
• property="propertyName"
• property="propertyName" param="parameterName"
• property="propertyName" value="propertyValue"
where propertyValue is a string or a scriptlet.
Attributes description:
• name - the name of a bean instance, already defined in a <jsp:useBean>
• property -
71
11 - JSP
11.9 the getProperty standard action
<jsp:getProperty>
Used to access the properties of a bean, converts them to string and displays the output to the
client.

<jsp:getProperty name="beanName" property="propName" />
• name - the name of a bean instance whose property is to be retrieved
• property - name of the property to be retrieved
11.10 the param standard action
<jsp:param>
Provide other tags with additional information in the form of name:value pairs. It is used in
conjunction with the <jsp:include>, <jsp:forward>, <jsp:plugin> actions.

<jsp:param name="paramName" value="paramValue" />
11.11 the include standard action
<jsp:include>
Used for the inclusion of a static or dynamic resource into the current JSP page at request
processing time. An included page has access only to the JspWriter object and cannot set
headers or cookies. While the <%@include> directive is executed at compile time and has static
content, the <jsp:include> action is executed at request processing time and has static or dynamic
content.

<jsp:include page="pageURL" flush="true" />
• page - the URL of the page, same format as the <%@include> directive.
• flush - only the "true" value is supported.
72
11 - JSP
11.12 the forward standard action
<jsp:forward>
Used to forward the the request to another JSP, servlet or to a static resource..

<jsp:forward page="pageURL" />
The action may include several <jsp:param> tags, as well. It is used mainly, when we want to
separate the application into different views, depending on request.
11.13 the plugin standard action
<jsp:plugin>
Used in pages to generate client browser specific HTML tags (<OBJECT> or <EMBED>) that
result in download of Java plugins(if required), followed by the execution of the applet or
JavaBeans component specified by the tag.

<jsp:plugin type="bean|applet" code="objCode" codeBase="objCodeBase"
align="align" archive="archiveList" height="height" hspace="hSpace"
jreversion="jreVersion" name="componentName" vspace="vSpace"
width="width" nspluginurl="netscapeURL" iepluginurl="IEURL">
<jsp:params>
<jsp:param name="paramName" value="paramValue" />
...
</jsp:params>
</jsp:plugin>
• name - the name of a bean instance, already defined in a <jsp:useBean>
11.14 implicit objects
JSP provides several implicit objects, based on the servlet API, objects which are automaticly
available.
1. request - represents the object that triggered the service() method invokation and has type
HttpServletRequest with scope request
2. response - represents server's response to the request, it has HttpServletResponse type and
73
11 - JSP
page scope
3. pageContext - provides a single point of access to attributes and shared data within the page,
it has type PageContext with scope page
4. session - it has HttpSession type and session scope
5. application - represents the servlet context, it has type ServletContext and scope
application
6. out - it represents the buffered version of java.io.PrintWriter, writes to the output
stream to the client, it has javax.servlet.jsp.JspWriter type and scope page
7. config - it is the SevletConfig for the current JSP page, it is of type ServletConfig and has
page scope
8. page - it is an instance of the page's implementation of the servlet class, it has
java.lang.Object type and scope page
11.15 scopes
1. request - an object with request scope is bound to the HttpServletRequest object; the
object can be accessed by invoking the getAttribute() method on the implicit request
object; the generated servlet binds the object to HttpServletRequest object using the
setAttribute(String key, Object value) method
2. session - an object with session scope is bound to the HttpSession object; the object can
be accessed by invoking the getValue() method on the implicit session object; the
generated servlet binds the object to HttpSession object using the setAttribute(String
key, Object value) method
3. application - an object with application scope is bound to the ServletContext object; the
object can be accessed by invoking the getAttribute() method on the implicit application
object; the generated servlet binds the object to the ServletContext object using the
setAttribute(String key, Object value) method
4. page - an object with page scope is bound to the PageContext object; the object can be
accessed by invoking the getAttribute() method on the implicit pageContext object; the
generated servlet binds the object to PageContext object using the setAttribute(String
key, Object value) method
74
12 - javaserver faces
12 - JAVASERVER FACES
12.1 what is javaServer faces?
JavaServer Faces technology is a server-side user interface component framework for Java
based web applications. This technology includes:
1. A set of APIs for:
• representing UI components, like input fields, buttons, links

• UI components management
• events handling
• input validation
• error handling
• page navigation specification
• support for internationalization and accessibility.
2. A JavaServer Pages (JSP) custom tag library for expressing a JavaServer Faces
interface within a JSP page.
12.2 javaServer Faces Technology 1.2
The latest version of JavaServer Faces technology is version 1.2, the final version of which has
been released through the Java Community Process under JSR-252.
The latest implementation of version 1.2 is the patch release, version 1.2_04.
There are 2 JSF specific tag libraries defined in this specification, namely the core JSF tags and
the html JSF tags.
12.3 the html JSF tags
This tag library contains JavaServer Faces component tags for all UIComponent + HTML
RenderKit Renderer combinations defined in the JavaServer Faces Specification.
12.4 the core JSF tags
The core JavaServer Faces tags define custom actions that are independent of any particular
RenderKit.
75
12.5 the structure of a JSF application
Here is a typical directory structure for a JSP application. The directory myJSFapp is the base
directory of the application.
myJSFapp
/ant
build.xml
/JavaSource
/WebContent
/WEB-INF
/classes
/lib
jsf-impl.jar
jsf-api.jar
faces-config.xml
web.xml
/pages
Comments on this structure:

• myJSFapp – application base directory with application name
• /ant – directory containing Ant build scripts with a default build.xml file
• /JavaSource – application specific java source classes and properties files
• /WebContent – contains the Web application files used by the application server or by
the web container
• /WEB-INF – contains files used as part of the runtime Web application
• /classes – compiled Java classes and properties files copied from the /JavaSource
directory
• /lib - contains libraries required by the application, like third party jar files
• jsf-impl.jar, jsf-api.jar – files included in the /lib directory, mandatory for any JSF
application
• web.xml – the deployment descriptor of the application, included in the /WEB-INF
directory
• faces-config.xml – the JSF configuration file, included in the /WEB-INF directory
• /pages – directory containing JSP and HTML presentation pages
12.6 how does JSF work? a first example
Example taken from http://www.exadel.com/tutorial/jsf/jsftutorial-kickstart.html.

A JSF application is nothing else but a servlet/JSP application. It has a deployment descriptor,
JSP pages, custom tag libraries, static resources, and so on. What makes it different is that a JSF
application is event-driven. The way the application behaves is controlled by an event listener
class. Let's have a look at the steps needed to build a JSF application:
1. Create JSP pages
2. Define navigation rules
3. Create managed beans
4. Create properties files
5. Edit JSP pages
6. Create an index.jsp file
76
7. Compile the application

8. Deploy and run the application
12.6.1 creating JSP Pages

Create the inputname.jsp and greeting.jsp files in WebContent/pages/. You only need to
create the JSP files. The directory structure already exists.
These files will act as place holders for now. We will complete the content of the files a little bit
later.
Now that we have the two JSP pages, we can create a navigation rule.
12.6.2 navigation
Navigation is the heart of JavaServer Faces. The navigation rule for this application is described
in the faces-config.xml file. This file already exists in the skeleton directory structure. You just
need to create its contents.
In our application, we just want to go from inputname.jsp to greeting.jsp. As a diagram, it would
look something like this:
Image from Exadel Studio Pro

The navigation rule shown in the picture is defined below. The rule says that from the view (page)
inputname.jsp go to the view (page) greeting.jsp, if the "outcome" of executing inputname.jsp
is greeting. And that's all there is to this.
<navigation-rule>
<from-view-id>/pages/inputname.jsp</from-view-id>
<navigation-case>
<from-outcome>greeting</from-outcome>
<to-view-id>/pages/greeting.jsp</to-view-id>
</navigation-case>
</navigation-rule>
This is, of course, a very simple navigation rule. You can easily create more complex ones. To
read more about navigation rules, visit the JSP Navigation Example forum item.
12.6.3 creating the Managed Bean

Next, we will create a myJFSapp folder inside the JavaSource folder. Inside this myJFSapp
folder, we will create a PersonBean.java file. This class is straight-forward. It's a simple Java
77
bean with one attribute and setter/getter methods. The bean simply captures the name entered by
a user after the user clicks the submit button. This way the bean provides a bridge between the
JSP page and the application logic. (Please note that the field name in the JSP file must exactly
match the attribute name in the bean.)
12.6.3.1 PersonBean.java
Put this code in the file:
package myJFSapp;
public class PersonBean {
String personName;
/**
* @return Person Name
*/
public String getPersonName() {
return personName;
}
/**
* @param Person Name
*/
public void setPersonName(String name) {
personName = name;
}
}
Later you will see how to "connect" this bean with the JSP page.
12.6.3.2 declaring the Bean in faces-config.xml

Now, the second part of faces-config.xml describes our Java bean that we created in the
previous steps. This section defines a bean name PersonBean. The next line is the full class
name, myJFSapp.PersonBean. request sets the bean scope in the application.
<managed-bean>
<managed-bean-name>personBean</managed-bean-name>
<managed-bean-class>myJFSapp.PersonBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
12.6.3.3 faces-config.xml
Your final faces-config.xml file should look like this:
<?xml version="1.0"?>
<!DOCTYPE faces-config PUBLIC
"-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN"
"http://java.sun.com/dtd/web-facesconfig_1_1.dtd">
<faces-config>
<navigation-rule>
<from-view-id>/pages/inputname.jsp</from-view-id>
<navigation-case>
<from-outcome>greeting</from-outcome>
<to-view-id>/pages/greeting.jsp</to-view-id>
78
</navigation-case>
</navigation-rule>
<managed-bean>
<managed-bean-name>personBean</managed-bean-name>
<managed-bean-class>myJFSapp.PersonBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
</faces-config>
12.6.4 creating a Properties File (Resource Bundle)

A properties file is just a file with param=value pairs. We use the messages stored in the
properties file in our JSP pages. Keeping the messages separate from the JSP page allows us to
quickly modify the messages without editing the JSP page.
Let's create a bundle folder in the JavaSource/myJFSapp folder and then a
messages.properties file in the bundle folder. We need to place it in the JavaSource folder so
that during project compilation, this properties file will be copied to the classes folder where the
runtime can find it.
12.6.4.1 messages.properties
Put this text in the properties file:
inputname_header=JSF KickStart
prompt=Tell us your name:
greeting_text=Welcome to JSF
button_text=Say Hello
sign=!
We now have everything to create the JSP pages.
12.6.5 editing the JSP Pages

Two pages should already have been created in myJFSapp/WebContent/pages.
12.6.5.1 inputname.jsp
Put the following coding into this file:
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<f:loadBundle basename="myJFSapp.bundle.messages" var="msg"/>
<html>
<head>
<title>enter your name page</title>
</head>
<body>
<f:view>
<h1>
<h:outputText value="#{msg.inputname_header}"/>
</h1>
<h:form id="helloForm">
<h:outputText value="#{msg.prompt}"/>
<h:inputText value="#{personBean.personName}" required=”true”>
<f:validateLength minimum="2" maximum="10"/>
</h:inputText>
79
<h:commandButton action="greeting" value="#{msg.button_text}" />

</h:form>
</f:view>
</body>
</html>
Now, let's explain the important sections in this file after displaying the code for each section
starting from the top.
The first line of these three is a directive that tells us where to find JSF tags that define HTML
elements and the second directive tells us where to find JSF tags that define core JSF elements.
The third line loads our properties file (resource bundle) that holds messages that we want to
display in our JSP page.
<h:inputText value="#{msg.inputname_header}" required=”true”>
This tag simply tells us to look in the resource bundle that we defined at the top of the page. The
required attribute of the h:inputText tag insures that an empty name will not be sent. One can
also add a line like
<f:validateLength minimum="2" maximum="10"/>
to make sure that the length of this field is reasonable long.
Then, look up the value for inputname_header in that file and print it here.
1 <h:form id="helloForm">
2 <h:outputText value="#{msg.prompt}"/>
3 <h:inputText value="#{personBean.personName}" required=”true”>
4 <f:validateLength minimum="2" maximum="10"/>
5 </h:inputText>
6 <h:commandButton action="greeting" value="#{msg.button_text}" />
7 </h:form>
Line 1. Creates an HTML form using JSF tags.

Line 2. Prints a message from the properties file using the value of prompt.
Lines 3-5. Creates an HTML input text box. In the value attribute we connect (bind) this field to
the managed bean attribute that we created before.
Line 6. JSF tags for the HTML form's submit button. The button's value is being retrieved from the
properties file. While the button's action attribute is set to greeting which matches the
navigation-outcome in faces-config.xml file. That's how JSF knows where to go next.
12.6.5.2 greeting.jsp
Put this coding inside the second JSP file:
<html>
<head>
80
<title>greeting page</title>
</head>
<body>
<f:view>
<h3>
<h:outputText value="#{msg.greeting_text}" />,
<h:outputText value="#{personBean.personName}" />
<h:outputText value="#{msg.sign}" />
</h3>
</f:view>
</body>
</html>
This page is very simple. The first three lines are identical to our first page. Theses lines import
JSF tag libraries and our properties file (resource bundle) with the messages.
The main code of interest to us is between the <h3>..</h3> tags. The first line will take a
message from the resource bundle and print it on the page. The second line will access a Java
bean, specifically the bean attribute personName, and also print its contents on the page.
Once this page is displayed in a Web browser, you will see something like this:
Welcome to JSF, name!
12.6.6 creating the index.jsp File

We will now create a third JSP file that doesn't actually function as a presentation page. It uses a
JSP tag to "forward" to the inputname.jsp page.
Create the index.jsp file inside the WebContent folder. Note that this file is not created in the
pages folder like the previous JSP files.
Having an index.jsp file will allow us to start the application like this:
http://localhost:8080/myJFSapp/
Now, put this coding into the file:

<html>
<body>
<jsp:forward page="/pages/inputname.jsf" />
</body>
</html>
If you look at the path for the forward, you'll notice the file suffix is .jsf and not .jsp. This is used
here, because in the web.xml file for the application *.jsf is the URL pattern used to signal that
the forwarded page should be handled by the JavaServer Faces servlet within Tomcat.
We are almost done with this example.
12.6.7 Compiling
An Ant build script is provided for you. To build the application run the build.xml script from the
ant folder:
ant build
12.6.8 Deploying
Before you can run this application within the servlet container, we need to deploy it. We will use
81
null (link) deployment to deploy the application in-place. To do this we need to register a context
in Tomcat's {TomcatHome}\conf\server.xml file.
To do this, insert this code:
<Context debug="0"
docBase="Path_to_WebContent"
path="/myJFSapp" reloadable="true"/>
near the end of the server.xml file within the Host element just before the closing </Host> tag.
Of course, Path_to_WebContent needs to be replaced with the exact path on your system to the
WebContent folder inside the myJFSapp folder (for example,
C:/examples/myJFSapp/WebContent).
12.6.9 Running
Next, start the Tomcat server (probably using the script startup.bat in Tomcat's bin directory).
When Tomcat is done loading, launch a web browser and enter:
http://localhost:8080/myJFSapp. (Port 8080 is the default port in Tomcat. Your setup, though,
might possibly be different).
12.7 creating a JSF application in Eclipse with the facesIDE plugin
Example taken from http://amateras.sourceforge.jp/docs/FacesIDE/SampleJSFApp.html .
12.7.1 Overview
This is a tutorial in which we create a simple JSF application to demonstrate FacesIDE's
functionality. This is a "login" application, which asks an user for an ID and password, verifies the
information, and forwards the user to a success or error page.
The application will use a few JSP pages with JSF elements, and a session-scoped managed
bean to coordinate their interactions. Along the way we'll use the following FacesIDE functionality:
• add JSF support to a project
• use the New JSF/JSP file wizard
• use the JSP Editor (see HTML/JSP/XML Editor)
• use the faces-config.xml Editor (see faces-config.xml Editor)
As a prerequisite for the tutorial, make sure FacesIDE and required plugins have been installed;
see Installing & Uninstalling. We don't assume that a J2EE server-specific plugin, such as the
Sysdeo Tomcat plugin has been installed.
12.7.2 Creating A Project

Here we create an Eclipse project, and set up folders for a web application. The folder structure
created is simply one that works for this author; your mileage may vary.
1. From the menubar select File/New/Project.... The New Project wizard appears.
2. Select Java Project; click Next.
3. Enter project name, say, jsf-login; click Finish
4. Create the web root folder: in Package Explorer select the jsf-login project, and from
the menubar select File/New/Folder; name the folder webroot
5. Create the web pages folder: in Package Explorer select the webroot folder, and from its
context menu select File/New/Folder; name the folder pages. This folder will contain all
82
"functional" pages.
6. Use FacesIDE to add JSF support: we use a FacesIDE wizard to create J2EE-
prescribed folders and files in webroot, and to add JSF libraries to the project.
a. in Package Explorer select the jsf-login project
b. from the menubar select File/New/Other...
c. in the wizard that appears, select Amateras/JSF/Add JSF Support; click Next
d. in the Add JSF Support page, for Web Application Root enter /jsf-
login/webroot; make sure all checkboxes are checked; click Next.
7. From the menubar open Project/Properties
8. Select the Amateras node; note that Root: has automatically been set to /webroot;
make sure HTML validation and DTD/XSD validation are enabled.
9. Create the source folder: select the Java Build Path node; select the Source tab; click
Add Folder...; in the dialog that appears create a folder named src directly under the
project folder (jsf-login); click Yes through messages that appear.
10.Set the output folder: in the Default output folder textbox at the bottom, enter jsf-
login/webroot/WEB-INF/classes; click OK to dismiss the properties dialog.
Your folder structure should now be as follows:

jsf-login
|
+-- src
|
+-- webroot
|
+-- WEB-INF
| |
| +-- classes (not shown in Java perspective)
| |
| +-- lib
|
+-- pages
12.7.3 Creating & Configuring Managed Beans

Here we create a class called LoginManager which will be used as a backing bean for the login
process. We then configure it to be a managed bean.
1. In Package Explorer select the src folder; from its context menu select New/Class. The
New Java Class wizard appears.
2. In the Package field, enter login; in the Name field enter LoginManager. Click Finish.
The Java code editor opens.
3. Enter and save the following code for the LoginManager class:
// LoginManager.java
package login;
public class LoginManager {

private String _uid = "";
private String _pwd = "";
public String getUserID() { return _uid; }

public void setUserID(String uid) { _uid = uid; }
83
public String getPassword() { return _pwd; }

public void setPassword(String pwd) { _pwd = pwd; }
public String loginAction() {

String action = null;
if ( _uid.equalsIgnoreCase("foo") &&
_pwd.equalsIgnoreCase("bar") )
action = "loginPass";
else
action = "loginFail";
return action;
}
}
4. Use FacesIDE to configure the bean: we use a FacesIDE editor to configure

LoginManager as a session-scoped managed bean.
a. in Package Explorer select jsf-login/webroot/WEB-INF/faces-
config.xml; from its context menu select Open With/faces-config.xml Editor.
The faces-config.xml editor opens.
b. along the bottom of the editor there are 3 tabs; click Managed Bean.
c. click Add; input widgets appear
d. for name enter mgr; for class enter login.LoginManager; for scope select
session.
e. from the menubar select File/Save, then close the editor
12.7.4 Creating JSP Pages

Here we create the JSP pages that make up the application's user interface. We will have 4
pages: a start page (index.jsp), and 3 content pages (login.jsp, success.jsp and
error.jsp). Content pages are placed in webroot/pages; index.jsp is placed directly in
webroot, and its sole function is to forward users to the login page.
All pages except login.jsp are simple pages with static content, so we create them first, using
the Workbench's standard file-creation facilities. Then we create login.jsp using a FacesIDE
wizard.
1. Create index.jsp:
a. in Package Explorer select webroot; from its context menu select New/File; the
New File wizard appears.
b. for File name enter index.jsp; make sure that the parent folder is set to /jsf-
login/webroot; click Finish; the JSP Editor opens.
c. enter the following code, save the file and close the editor.


<html>
<body>
<jsp:forward page="faces/pages/login.jsp" />
</body>
</html>
2. Create success.jsp: create this file similarly to index.jsp, but in webroot/pages.

Enter the following code:

84
<html>
<head>
<title>jsf-login</title>
</head>
<body>
<h2>Success!</h2>
</body>
</html>
3. Create error.jsp: create this file similarly to index.jsp, but in webroot/pages.

Enter the following code:


<html>
<head>
<title>jsf-login</title>
</head>
<body>
<h2>Error!</h2>
The user-id and or password were invalid. Please try
again.
</body>
</html>
4. Create login.jsp:
a. in Package Explorer select webroot/pages; from its context menu select New/
Other...; the New wizard appears.
b. select Amateras/JSF/Faces JSP File; click Next
c. for File name enter login.jsp; make sure that Container is set to /jsf-
login/webroot/pages, and that Use MyFaces Tomahawk components and
Use MyFaces SandBox components are unchecked, and choose default for
Template; click Finish; the FacesIDE JSP Editor opens, with the following
template code.
<%@ page contentType="text/html; charset=Cp1252" %>

<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=Cp1252"/>
<title></title>
</head>
<body>
<f:view>
<h:form>
</h:form>
</f:view>
</body>
</html>
We will now edit this page to contain our input widgets, etc.
d. place the cursor between the <title></title> elements; enter jsf-login
e. Open the JSF palette, and dock it along the right. (See Show View Dialog)
f. create a few blank lines between the <h:form> elements; place your cursor in
one of these lines, expand the JSF HTML panel in the palette, and click on the
85
icon for <h:inputText>; this inserts the corresponding JSF element at the
cursor location.
Note: the JSP editor is aware of referenced tag libraries, and uses them for code
completion as well. Thus if you were to type <h: and hit CTRL + Spacebar, you
would get a popup window of JSF HTML elements.
g. now we want to add attributes to this element, and the JSP Editor can help with
code- completion. To see this in action, place the cursor inside the <h:inputText>
element, and hit CTRL + Spacebar; a code-completion window pops up, as
shown below.
h. in the code-completion window scroll down to value, and hit Enter; this inserts
value="" at the cursor. We will now bind this to the userID property of
LoginManager; FacesIDE can provide code completion here as well.
i. place the cursor between the quotes in value="", enter #{mgr., and hit CTRL +
Spacebar; a code-completion window pops up, with bean properties available in
mgr. This is shown below:
86
(Recall that we configured LoginManager as a managed bean called mgr.)

j. select userID from the code-completion window; complete the expression with
the closing {
k. insert another <h:inputText> element; set its value binding expression to
value="#{mgr.password}"
l. insert a <h:commandButton> element; set its value to Login, and its action
to the value binding expression #{mgr.loginAction}
The final code, with the barest presentational formatting, is shown below:
<%@ page contentType="text/html; charset=Cp1252" %>

<html>
<head>
<title>jsf-title</title>
</head>
<body>
<f:view>
<h:form>
UserID: <h:inputText value="#{mgr.userID}"/>
<br/>Password: <h:inputText
value="#{mgr.password}"/>
<br/><h:commandButton value="Login"
action="#{mgr.loginAction}"/>
</h:form>
</f:view>
</body>
</html>
12.7.5 Creating Navigation Rules

Here we create navigation rules among pages, using a FacesIDE editor.
1. Open faces-config.xml; it should open in the faces-config.xml Editor.
2. Select the Navigation tab
3. from the Navigation panel in the palette at left, click on Page, then click inside the editor
window; this inserts a page icon into the editor, and the page's properties appear in the
Workbech's Properties view. This is shown below.
87
Note that the icon has a small triangle overlay--this indicates that something is wrong,
specifically that FacesIDE could not locate a page at path /page1.jsp
4. in the Properties view, change the value of path to /index.jsp. You can also change
it on the diagram directly (select the page and click once more); notice that the warning
triangle disappears.
5. add 3 more pages, and set them to /pages/login.jsp, /pages/success.jsp and /
pages/error.jsp. Arrange them as shown below:
88
Now we'll add navigation rules among the pages.

6. from the palette at left, select Navigation Case, then click first on the icon for
login.jsp and then on the icon for success.jsp. This inserts a forward-action
between the two pages, and is represented by an arrow. "Decharge" the mouse pointer by
clicking on the pointer icon in the palette, then click on the newly-added forward-action
icon to select it. Its properties appear in the Properties view. This is shown below:
89
7. in the Properties view (or direct editing on the diagram), change the value of from-
outcome to loginPass. Recall that this is the success-value returned by
LoginManager's loginAction method. You can also change values by direct-editing
(select once and re-click) in the diagram
8. Similarly add a forward-action from login.jsp to error.jsp, and set its from-
outcome to loginFail
We're done with setting up navigation rules. We'll set some properties in web.xml, and we'll then
be ready to deploy the application.
12.7.6 Editing web.xml

Here we edit web.xml for the specifics of our application. As it turns out, since we have such a
trivial application, all we need do in web.xml is indicate the Faces Servlet mapping.
1. open web.xml; scroll to the bottom and look for the comment

2. by default virtual path-based mapping is commented out, and extension-based mapping is
turned on. We want virtual path-based mapping, so uncomment it. You may comment out
the entry for extension-based mapping, or leave it as-is.
The application is now complete, and you should be able to deploy it to your server of choice.
Once deployed browse to index.jsp, and you should be automatically forwarded to
login.jsp. Use UserID/Password of foo/bar, and you should be sent to the success page; any
other id/password should send you to the error page.
Deployment to some servers is described below:
90
12.7.7 Deploying To Tomcat 5.0

1. start Tomcat; open its Manager application in a browser; the default URL for this is
http://localhost:8080/manager/html
2. scroll down to Deploy; we'll deploy our app by providing its directory; for Context path
enter /jsf-login; for WAR or Directory URL enter the path to webroot, as
file:///...; leave XML Configuration File URL blank; click Deploy
3. the Manager application should reload, and you should see /jsf-login in the list of
running applications. Click on its link to launch the application.
12.8 packges in the JavaServer Faces API
The classes and interfaces of the JavaServer Faces API are grouped in several packages,
namely:
• javax.faces
• javax.faces.application
• javax.faces.component
• javax.faces.component.html
• javax.faces.context
• javax.faces.convert
• javax.faces.el
• javax.faces.event
• javax.faces.lifecycle
• javax.faces.model
• javax.faces.render
• javax.faces.validator
• javax.faces.webapp
12.9 the javax.faces package
Contains 2 classes – FactoryFinder and FacesException

public final class FactoryFinder extends Object
FactoryFinder implements the standard discovery algorithm for all factory objects specified in the
JavaServer Faces APIs. For a given factory class name, a corresponding implementation class is
searched for based on the following algorithm. Items are listed in order of decreasing search
precedence:
• If the JavaServer Faces configuration file bundled into the WEB-INF directory of the
webapp contains a factory entry of the given factory class name, that factory is used.
• If the JavaServer Faces configuration files named by the javax.faces.CONFIG_FILES
ServletContext init parameter contain any factory entries of the given factory class
name, those factories are used, with the last one taking precedence.
• If there are any JavaServer Faces configuration files bundled into the META-INF directory
of any jars on the ServletContext's resource paths, the factory entries of the given
factory class name in those files are used, with the last one taking precedence.
• If a META-INF/services/{factory-class-name} resource is visible to the web
application class loader for the calling application (typically as a result of being present in
the manifest of a JAR file), its first line is read and assumed to be the name of the factory
91
implementation class to use.

• If none of the above steps yield a match, the JavaServer Faces implementation specific
class is used.
public class FacesException extends RuntimeException
This class encapsulates general JavaServer Faces exceptions.
12.10 the javax.faces.application package
Contains the following classes:

• Application - A set of APIs for representing UI components and managing their state,
handling events and input validation, defining page navigation, and supporting
internationalization and accessibility.
• ApplicationFactory - a factory object that creates (if needed) and returns Application
instances. Implementations of JavaServer Faces must provide at least a default
implementation of Application.
• FacesMessage - represents a single validation (or other) message, which is typically
associated with a particular component in the view. A FacesMessage instance may be
created based on a specific messageId.
• FacesMessage.Severity - used to represent message severity levels in a typesafe
enumeration.
• NavigationHandler – An object of this type is passed the outcome string returned by an
application action invoked for this application, and will use this (along with related state
information) to choose the view to be displayed next.
• StateManager - directs the process of saving and restoring the view between requests.
• StateManagerWrapper - Provides a simple implementation of StateManager that can
be subclassed by developers wishing to provide specialized behavior to an existing
StateManager instance. The default implementation of all methods is to call through to
the wrapped StateManager.
• ViewHandler - the pluggablity mechanism for allowing implementations of or applications
using the JavaServer Faces specification to provide their own handling of the activities in
the Render Response and Restore View phases of the request processing lifecycle. This
allows for implementations to support different response generation technologies, as well
as alternative strategies for saving and restoring the state of each view.
• ViewHandlerWrapper - Provides a simple implementation of ViewHandler that can be
subclassed by developers wishing to provide specialized behavior to an existing
ViewHandler instance. The default implementation of all methods is to call through to
the wrapped ViewHandler.
• ViewExpiredException - implementations must throw this FacesException when
attempting to restore the view
StateManager.restoreView(javax.faces.context.FacesContext, String,
String) results in failure on postback.
92
12.11 the javax.faces.component package
Defines both a set of interfaces and classes. The interfaces defined in this package are:
• ActionSource - an interface that may be implemented by any concrete UIComponent
that wishes to be a source of ActionEvents, including the ability to invoke application
actions via the default ActionListener mechanism.
• ActionSource2 - extends ActionSource and provides a JavaBeans property analogous
to the "action" property on ActionSource. The difference is the type of this property is
a MethodExpression rather than a MethodBinding. This allows the ActionSource
concept to leverage the new Unified EL API.
• ContextCallBack - A simple callback interace that enables taking action on a specific
UIComponent (either facet or child) in the view while preserving any contextual state for
that component instance in the view.
• EditableValueHolder - an extension of ValueHolder that describes additional features
supported by editable components, including ValueChangeEvents and Validators.
• NamingContainer - an interface that must be implemented by any UIComponent that
wants to be a naming container.
• StateHolder - interface implemented by classes that need to save their state between
requests.
• ValueHolder - an interface that may be implemented by any concrete UIComponent that
wishes to support a local value, as well as access data in the model tier via a value
binding expression, and support conversion between String and the model tier data's
native data type.
The classes in this package are all UI related. Here they are:
• UIColumn - a UIComponent that represents a single column of data within a parent
UIData component.
• UICommand - a UIComponent that represents a user interface component which, when
activated by the user, triggers an application specific "command" or "action". Such a
component is typically rendered as a push button, a menu item, or a hyperlink.
• UIComponent - the base class for all user interface components in JavaServer Faces.
The set of UIComponent instances associated with a particular request and response are
organized into a component tree under a UIViewRoot that represents the entire content
of the request or response.
• UIComponentBase - a convenience base class that implements the default concrete
behavior of all methods defined by UIComponent.
• UIData - a UIComponent that supports data binding to a collection of data objects
represented by a DataModel instance, which is the current value of this component itself
(typically established via a ValueBinding). During iterative processing over the rows of
data in the data model, the object for the current row is exposed as a request attribute
under the key specified by the var property.
• UIForm - a UIComponent that represents an input form to be presented to the user, and
whose child components represent (among other things) the input fields to be included
when the form is submitted.
• UIGraphic - a UIComponent that displays a graphical image to the user. The user cannot
93
manipulate this component; it is for display purposes only.

• UIInput - a UIComponent that represents a component that both displays output to the
user (like UIOutput components do) and processes request parameters on the
subsequent request that need to be decoded.
• UIMessage - This component is responsible for displaying messages for a specific
UIComponent, identified by a clientId.
• UIMessages - The renderer for this component is responsible for obtaining the messages
from the FacesContext and displaying them to the user.
• UINamingContainer - a convenience base class for components that wish to implement
NamingContainer functionality.
• UIOutput - a UIComponent that has a value, optionally retrieved from a model tier bean
via a value binding expression, that is displayed to the user. The user cannot directly
modify the rendered value; it is for display purposes only.
• UIPanel - a UIComponent that manages the layout of its child components.
• UIParameter - a UIComponent that represents an optionally named configuration
parameter for a parent component.
• UISelectBoolean - a UIComponent that represents a single boolean (true or false)
value. It is most commonly rendered as a checkbox.
• UISelectItem - a component that may be nested inside a UISelectMany or
UISelectOne component, and causes the addition of a SelectItem instance to the list
of available options for the parent component.
• UISelectMany - a UIComponent that represents the user's choice of a zero or more
items from among a discrete set of available options. The user can modify the selected
values. Optionally, the component can be preconfigured with zero or more currently
selected items, by storing them as an array in the value property of the component.This
component is generally rendered as a select box or a group of checkboxes.
• UISelectOne - a UIComponent that represents the user's choice of zero or one items
from among a discrete set of available options. The user can modify the selected value.
Optionally, the component can be preconfigured with a currently selected item, by storing
it as the value property of the component.
• UIViewRoot - the UIComponent that represents the root of the UIComponent tree. This
component has no rendering, it just serves as the root of the component tree.
12.12 the java.faces.component.html package
Contains HTML related classes.
• HtmlColumn - represents a column that will be rendered in an HTML table element.

• HtmlCommandButton - represents an HTML input element for a button of type
submit or reset. The label text is specified by the component value.
• HtmlCommandLink - represents an HTML a element for a hyperlink that acts like a
submit button. This component must be placed inside a form, and requires JavaScript to
be enabled in the client.
94
• HtmlDataTable - represents a set of repeating data (segregated into columns by child

UIColumn components) that will be rendered in an HTML table element.
• HtmlForm - represents an HTML form element. Child input components will be
submitted unless they have been disabled.
• HtmlGraphicImage - represents an HTML img element, used to retrieve and render a
graphical image.
• HtmlInputHidden - represents an HTML input element of type hidden.
• HtmlInputSecret - represents an HTML input element of type password. On a
redisplay, any previously entered value will not be rendered (for security reasons) unless
the redisplay property is set to true.
• HtmlInputText - represents an HTML input element of type text.
• HtmlInputTextarea - represents an HTML textarea element.
• HtmlMessage - by default, the rendererType property must be set to
"javax.faces.Message". This value can be changed by calling the
setRendererType() method.
• HtmlMessages - by default, the rendererType property must be set to
"javax.faces.Messages" This value can be changed by calling the
setRendererType() method.
• HtmlOutputFormat - represents a component that looks up a localized message in a
resource bundle, optionally uses it as a MessageFormat pattern string and substitutes in
parameter values from nested UIParameter components, and renders the result. If the
"dir" or "lang" attributes are present, render a span element and pass them through as
attributes on the span.
• HtmlOutputLabel - represents an HTML label element, used to define an accessible
label for a corresponding input element.
• HtmlOutputLink - represents an HTML a (hyperlink) element that may be used to link to
an arbitrary URL defined by the value property.
• HtmlOutputText - renders the component value as text, optionally wrapping in a span
element if CSS styles or style classes are specified.
• HtmlPanelGrid - renders child components in a table, starting a new row after the
specified number of columns.
• HtmlPanelGroup - causes all child components of this component to be rendered. This is
useful in scenarios where a parent component is expecting a single component to be
present, but the application wishes to render more than one.
• HtmlSelectBooleanCheckbox - represents an HTML input element of type checkbox.
The checkbox will be rendered as checked, or not, based on the value of the value
property.
• HtmlSelectManyCheckbox - represents a multiple-selection component that is rendered
as a set of HTML input elements of type checkbox.
• HtmlSelectManyListbox - represents a multiple-selection component that is rendered as
an HTML select element, showing either all available options or the specified number of
options.
• HtmlSelectManyMenu - represents a multiple-selection component that is rendered as an
HTML select element, showing a single available option at a time.
95
• HtmlSelectOneListbox - represents a single-selection component that is rendered as an

HTML select element, showing either all available options or the specified number of
options.
• HtmlSelectOneMenu - represents a single-selection component that is rendered as an
HTML select element, showing a single available option at a time.
• HtmlSelectOneRadio - represents a single-selection component that is rendered as a set
of HTML input elements of typeradio.
12.13 the java.faces.context package
Contains the following classes:
• ExternalContext - allows the Faces API to be unaware of the nature of its containing
application environment. In particular, this class allows JavaServer Faces based
appications to run in either a Servlet or a Portlet environment.
• FacesContext - contains all of the per-request state information related to the processing
of a single JavaServer Faces request, and the rendering of the corresponding response. It
is passed to, and potentially modified by, each phase of the request processing lifecycle.
• FacesContextFactory - a factory object that creates (if needed) and returns new
FacesContext instances, initialized for the processing of the specified request and
response objects.
• ResponseStream - an interface describing an adapter to an underlying output
mechanism for binary output.
• ResponseWriter - an abstract class describing an adapter to an underlying output
mechanism for character-based output.
• ResponseWriterWrapper - provides a simple implementation of ResponseWriter that
can be subclassed by developers wishing to provide specialized behavior to an existing
ResponseWriter instance. The default implementation of all methods is to call through
to the wrapped ResponseWriter.
12.14 the java.faces.convert package
12.14.1 the interface Converter

Converter is an interface describing a Java class that can perform Object-to-String and String-to-
Object conversions between model data objects and a String representation of those objects that
is suitable for rendering.
The classes implementing this interface within this package are:
• BigDecimalConverter
• BigIntegerConverter
• BooleanConverter
96
• ByteConverter
• CharacterConverter
• DateTimeConverter
• DoubleConverter
• EnumConverter
• FLoatConverter
• IntegerConverter
• LongConverter
• NumberConverter
• ShortConverter
The package also contains one exception:

• ConverterException - an exception thrown by the getAsObject() or getAsText()
method of a Converter, to indicate that the requested conversion cannot be performed.
12.15 the java.faces.el package
Contains classes and interfaces for evaluating and processing reference expressions.
Classes:
• MethodBinding - an object that can be used to call an arbitrary public method, on an

instance that is acquired by evaluatng the leading portion of a method binding expression
via a ValueBinding.
• PropertyResolver - represents a pluggable mechanism for accessing a "property" of an
underlying Java object instance.
• ValueBinding - an object that can be used to access the property represented by an
action or value binding expression.
• VariableResolver - represents a pluggable mechanism for resolving a top-level variable
reference at evaluation time.
Exceptions:
• EvaluationException - an exception reporting an error that occurred during the

evaluation of an expression in a MethodBinding or ValueBinding.
• MethodNotFoundException - an exception caused by a method name that cannot be
resolved against a base object.
• PropertyNotFoundException - an exception caused by a property name that cannot be
resolved against a base object.
• ReferenceSyntaxException - an exception reporting a syntax error in a method binding
97
expression or value binding expression.
12.16 the java.faces.event package
Contains interfaces describing events and event listeners, and concrete event implementation
classes.
Interfaces:
• ActionListener - listener interface for receiving ActionEvents.

• FacesListener - a generic base interface for event listeners for various types of
FacesEvents.
• PhaseListener - interface implemented by objects that wish to be notified at the
beginning and ending of processing for each standard phase of the request processing
lifecycle.
• ValueChangeListener - listener interface for receiving ValueChangeEvents.
Classes:
• ActionEvent - represents the activation of a user interface component (such as a

UICommand).
• FacesEvent - the base class for user interface and application events that can be fired by
UIComponents.
• PhaseEvent - represents the beginning or ending of processing for a particular phase of
the request processing lifecycle, for the request encapsulated by the specified
FacesContext.
• PhaseId - typesafe enumeration of the legal values that may be returned by the
getPhaseId() method of the FacesEvent interface.
• ValueChangeEvent - a notification that the local value of the source component has
been change as a result of user interface activity.
One exception - AbortProcessingException - thrown by event listeners to terminate the

processing of the current event.
12.17 the java.faces.lifecycle package
This package contains 2 classes.

The Lifecycle class manages the processing of the entire lifecycle of a particular JavaServer
Faces request.
The LifecycleFactory class is a factory object that creates (if needed) and returns Lifecycle
instances.
98
12.18 the java.faces.model package
Contains the interface DataModelListener and several classes providing standard model data
beans for JavaServer Faces. Classes:
• ArrayDataModel - a convenience implementation of DataModel that wraps an array of

Java objects.
• DataModel - an abstraction around arbitrary data binding technologies that can be used to
adapt a variety of data sources for use by JavaServer Faces components that support
per-row processing for their child components (such as UIData).
• DataModelEvent - represents an event of interest to registered listeners that occurred on
the specified DataModel.
• ListDataModel - a convenience implementation of DataModel that wraps an List of
Java objects.
• ResultDataModel - a convenience implementation of DataModel that wraps a JSTL
Result object, typically representing the results of executing an SQL query via JSTL
tags.
• ResultSetDataModel - a convenience implementation of DataModel that wraps a
ResultSet of Java objects. Note that the specified ResultSet MUST be scrollable.
• ScalarDataModel - a convenience implementation of DataModel that wraps an
individual Java object.
• SelectItem - represents a single item in the list of supported items associated with a
UISelectMany or UISelectOne component.
• SelectItemGroup - a subclass of SelectItem that identifies a set of options that will be
made available as a subordinate "submenu" or "options list", depending upon the
requirements of the UISelectMany or UISelectOne renderer that is actually used.
12.19 the java.faces.render package
Contains classes defining the rendering model.
• Renderer - converts the internal representation of UIComponents into the output stream
(or writer) associated with the response we are creating for a particular request. Each
Renderer knows how to render one or more UIComponent types (or classes), and
advertises a set of render-dependent attributes that it recognizes for each supported
UIComponent.
• RenderKit - represents a collection of Renderer instances that, together, know how to
render JavaServer Faces UIComponent instances for a specific client. Typically,
RenderKits are specialized for some combination of client device type, markup
language, and/or user Locale. A RenderKit also acts as a Factory for associated
Renderer instances, which perform the actual rendering process for each component.
99
• RenderKitFactory - a factory object that registers and returns RenderKit instances.

Implementations of JavaServer Faces must provide at least a default implementation of
RenderKit.
• ResponseStateManager - the helper class to StateManager that knows the specific
rendering technology being used to generate the response.
12.20 the java.faces.validator package
Interface defining the validator model, and concrete validator implementation classes.
A Validator implementation is a class that can perform validation (correctness checks) on a
EditableValueHolder.
Implementation classes:
• DoubleRangeVlidator - a Validator that checks the value of the corresponding
component against specified minimum and maximum values
• LengthValidator - a Validator that checks the number of characters in the String
representation of the value of the associated component.
• LongRangeValidator - a Validator that checks the value of the corresponding
component against specified minimum and maximum values.
The package contains an exception, as well.
A ValidatorException is an exception thrown by the validate() method of a Validator to
indicate that validation failed.
12.21 the java.faces.webapp package
Contains classes required for integration of JavaServer Faces into web applications, including a
standard servlet, base classes for JSP custom component tags, and concrete tag implementations
for core tags.
• AttributeTag - Tag implementation that adds an attribute with a specified name and
String value to the component whose tag it is nested inside, if the component does not
already contain an attribute with the same name.
• ConverterTag - a base class for all JSP custom actions that create and register a
Converter instance on the ValueHolder associated with our most immediate
surrounding instance of a tag whose implementation class is a subclass of
UIComponentTag.
• FacesServlet - a servlet that manages the request processing lifecycle for web
applications that are utilizing JavaServer Faces to construct the user interface.
• FacetTag - the JSP mechanism for denoting a UIComponent is to be added as a facet
to the component associated with its parent.
• UIComponentBodyTag - a base class for all JSP custom actions, related to a
UIComponent, that need to process their tag bodies.
100
• UIComponentTag - the base class for all JSP custom actions that correspond to user
interface components in a page that is rendered by JavaServer Faces.
• ValidatorTag - a base class for all JSP custom actions that create and register a
Validator instance on the EditableValueHolder associated with our most
immediate surrounding instance of a tag whose implementation class is a subclass of
UIComponentTag.
101
13 - JAVA MESSAGE SERVICE

13.1 JMS elements
The Java Message Service (JMS) API is a Java Message Oriented Middleware (MOM) API for
sending messages between two or more clients. JMS is a part of the Java Platform, Enterprise
Edition, and is defined by a specification developed under the Java Community Process as JSR
914.
The following are JMS elements:
• JMS provider - An implementation of the JMS interface for a Message Oriented
Middleware (MOM). Providers are implemented as either a Java JMS implementation or
an adapter to a non-Java MOM.
• JMS client - an application or process that produces and/or consumes messages.
• JMS producer - a JMS client that creates and sends messages.
• JMS consumer - a JMS client that receives messages.
• JMS message - an object that contains the data being transferred between JMS clients.
• JMS queue - a staging area that contains messages that have been sent and are waiting
to be read. As the name queue suggests, the messages are delivered in the order sent. A
message is removed from the queue once it has been read.
• JMS topic - a distribution mechanism for publishing messages that are delivered to
multiple subscribers.
13.2 JMS models
The JMS API supports two models:

• point-to-point or queuing model
• publish and subscribe model
In the point-to-point or queuing model, a producer posts messages to a particular queue and a
consumer reads messages from the queue. Here, the producer knows the destination of the
message and posts the message directly to the consumer's queue. It is characterized by following:
• Only one consumer will get the message
• The producer does not have to be running at the time the consumer consumes the
message, nor does the consumer need to be running at the time the message is sent
• Every message successfully processed is acknowledged by the consumer
The publish/subscribe model supports publishing messages to a particular message topic. Zero or
more subscribers may register interest in receiving messages on a particular message topic. In
this model, neither the publisher nor the subscriber know about each other. A good metaphor for it
is anonymous bulletin board. The following are characteristics of this model:
• Multiple consumers can get the message
• There is a timing dependency between publishers and subscribers. The publisher has to
create a subscription in order for clients to be able to subscribe. The subscriber has to
remain continuously active to receive messages, unless it has established a durable
102
subscription. In that case, messages published while the subscriber is not connected will
be redistributed whenever it reconnects.
Using Java, JMS provides a way of separating the application from the transport layer of
providing data. The same Java classes can be used to communicate with different JMS providers
by using the JNDI information for the desired provider. The classes first use a connection factory
to connect to the queue or topic, and then use populate and send or publish the messages. On the
receiving side, the clients then receive or subscribe to the messages.
13.3 the JMS API programming model
13.4 the JMS API
The JMS API is provided in the Java package javax.jms.
13.4.1 the ConnectionFactory interface

An administered object that a client uses to create a connection to the JMS provider. JMS clients
access the connection factory through portable interfaces so the code does not need to be
changed if the underlying implementation changes. Administrators configure the connection
factory in the Java Naming and Directory Interface (JNDI) namespace so that JMS clients can
look them up. Depending on the type of message, users will use either a queue connection factory
or topic connection factory.
103
At the beginning of a JMS client program, you usually perform a JNDI lookup of a connection
factory, then cast and assign it to a ConnectionFactory object.
For example, the following code fragment obtains an InitialContext object and uses it to look
up a ConnectionFactory by name. Then it assigns it to a ConnectionFactory object:
Context ctx = new InitialContext();
ConnectionFactory connectionFactory = (ConnectionFactory)
ctx.lookup("jms/ConnectionFactory");
In a J2EE application, JMS administered objects are normally placed in the jms naming
subcontext.
13.4.2 the Connection interface

Once a connection factory is obtained, a connection to a JMS provider can be created. A
connection represents a communication link between the application and the messaging server.
Depending on the connection type, connections allow users to create sessions for sending and
receiving messages from a queue or topic.
Connections implement the Connection interface. When you have a ConnectionFactory
object, you can use it to create a Connection:
Connection connection = connectionFactory.createConnection();
Before an application completes, you must close any connections that you have created. Failure
to close a connection can cause resources not to be released by the JMS provider. Closing a
connection also closes its sessions and their message producers and message consumers.
connection.close();
Before your application can consume messages, you must call the connection's start()
method. If you want to stop message delivery temporarily without closing the connection, you call
the stop method.
13.4.3 the Destination interface

An administered object that encapsulates the identity of a message destination, which is where
messages are delivered and consumed. It is either a queue or a topic. The JMS administrator
creates these objects, and users discover them using JNDI. Like the connection factory, the
administrator can create two types of destinations: queues for Point-to-Point and topics for
Publish/Subscribe.
For example, the following line of code performs a JNDI lookup of the previously created topic
jms/MyTopic and casts and assigns it to a Destination object:
Destination myDest = (Destination) ctx.lookup("jms/MyTopic");
The following line of code looks up a queue named jms/MyQueue and casts and assigns it to a
Queue object:
Queue myQueue = (Queue) ctx.lookup("jms/MyQueue");
13.4.4 the MessageConsumer interface

An object created by a session. It receives messages sent to a destination. The consumer can
receive messages synchronously (blocking) or asynchronously (non-blocking) for both queue and
topic-type messaging.
For example, you use a Session to create a MessageConsumer for either a queue or a topic:
104
MessageConsumer consumer = session.createConsumer(myQueue);

MessageConsumer consumer = session.createConsumer(myTopic);
You use the Session.createDurableSubscriber() method to create a durable topic

subscriber. This method is valid only if you are using a topic.
After you have created a message consumer, it becomes active, and you can use it to receive
messages. You can use the close() method for a MessageConsumer to make the message
consumer inactive. Message delivery does not begin until you start the connection you created by
calling its start() method. (Remember always to call the start() method; forgetting to start
the connection is one of the most common JMS programming errors.)
You use the receive method to consume a message synchronously. You can use this method at
any time after you call the start method:
connection.start();
Message m = consumer.receive();
connection.start();
Message m = consumer.receive(1000); // time out after a second
To consume a message asynchronously, a message listener object may be used.
13.4.5 the MessageListener interface

A message listener is an object that acts as an asynchronous event handler for messages. This
object implements the MessageListener interface, which contains one method, onMessage().
In the onMessage() method, you define the actions to be taken when a message arrives.
You register the message listener with a specific MessageConsumer by using the
setMessageListener() method. For example, if you define a class named Listener that
implements the MessageListener interface, you can register the message listener as follows:
Listener myListener = new Listener();
consumer.setMessageListener(myListener);
After you register the message listener, you call the start() method on the Connection to
begin message delivery. (If you call start() before you register the message listener, you are
likely to miss messages.)
When message delivery begins, the JMS provider automatically calls the message listener's
onMessage() method whenever a message is delivered. The onMessage() method takes one
argument of type Message, which your implementation of the method can cast to any of the other
message types.
A message listener is not specific to a particular destination type. The same listener can obtain
messages from either a queue or a topic, depending on the type of destination for which the
message consumer was created. A message listener does, however, usually expect a specific
message type and format. Moreover, if it needs to reply to messages, a message listener must
either assume a particular destination type or obtain the destination type of the message and
create a producer for that destination type.
13.4.6 the MessageProducer interface

An object created by a session that sends messages to a destination. The user can create a
sender to a specific destination or create a generic sender that specifies the destination at the
time the message is sent.
You use a Session to create a MessageProducer for a destination. Here, the first example
creates a producer for the destination myQueue, and the second for the destination myTopic:
105
MessageProducer producer = session.createProducer(myQueue);

MessageProducer producer = session.createProducer(myTopic);
You can create an unidentified producer by specifying null as the argument to

createProducer. With an unidentified producer, you do not specify a destination until you send
a message.
After you have created a message producer, you can use it to send messages by using the send
method:
producer.send(message);
You must first create the messages; if you created an unidentified producer, use an overloaded
send method that specifies the destination as the first parameter. For example:
MessageProducer anon_prod = session.createProducer(null);
anon_prod.send(myQueue, message);
13.4.7 the Message interface

An object that is sent between consumers and producers; that is, from one application to another.
A message has three main parts:
1. A message header (required): Contains operational settings to identify and route
messages
2. A set of message properties (optional): Contains additional properties to support
compatibility with other providers or users. It can be used to create custom fields or filters
(selectors).
3. A message body (optional): Allows users to create five types of messages (text message,
map message, bytes message, stream message, and object message).
The message interface is extremely flexible and provides numerous ways to customize the
contents of a message.
The JMS API provides methods for creating messages of each type and for filling in their
contents. For example, to create and send a TextMessage, you might use the following
statements:
TextMessage message = session.createTextMessage();
message.setText(msg_text); // msg_text is a String
producer.send(message);
At the consuming end, a message arrives as a generic Message object and must be cast to the
appropriate message type. You can use one or more getter methods to extract the message
contents. The following code fragment uses the getText method:
Message m = consumer.receive();
if (m instanceof TextMessage) {
TextMessage message = (TextMessage) m;
System.out.println("Reading message: " + message.getText());
} else {
// Handle error
}
13.4.8 the Session interface

Represents a single-threaded context for sending and receiving messages. A session is single-
threaded so that messages are serialized, meaning that messages are received one-by-one in the
order sent. The benefit of a session is that it supports transactions. If the user selects transaction
support, the session context holds a group of messages until the transaction is committed, then
delivers the messages. Before committing the transaction, the user can cancel the messages
106
using a rollback operation. A session allows users to create message producers to send
messages, and message consumers to receive messages.
Sessions implement the Session interface. After you create a Connection object, you use it to
create a Session:
Session session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
The first argument means that the session is not transacted; the second means that the session
automatically acknowledges messages when they have been received successfully.
To create a transacted session, use the following code:
Session session = connection.createSession(true, 0);
Here, the first argument means that the session is transacted; the second indicates that message
acknowledgment is not specified for transacted sessions.
107
14 - ENTERPRISE JAVA BEANS

14.1 enterprise java beans versus (ordinary) java beans
(Ordinary) Java beans provide a format for general-purpose components, while the EJB
(Enterprise Java Beans) architecture provides a format for highly specialized business logic
components.
What are Enterprise Java Beans? A collection of Java classes together with an xml file,
bundled into a single unit. The Java classes must follow certain rules and must offer certain
callback methods.
The EJBs will run in an EJB container which is part of an application server.
Version 1.1 of EJB specification provides two EJB types:
• session beans - intended to be used by a single client (client extension on the server);
bean's life span can be no longer than client's
• entity beans - object oriented representation of data in a DB; multiple clients can access it
simultaneously while its life-span is the same as the data it represents
The 2.0 EJB specification adds another bean type:
• message-driven beans
14.2 enterprise java beans architecture
108
14.3 the ejb container and its services
The EJB container provides an execution environment for a component. The component lives
inside a container, container which offers services to the component. On the other side, the
container lives (in general) in an application server, server which provides an execution
environment for containers.
The main reason for using EJBs is to take advantage of the services provided by the container.
These services are:

• persistence - DB interaction
• transactions - transaction management can be complex, especially if we have more
databases and more access components
• data caching - no developer coding, improved performance
• security - EJB access can be stated without extra coding
• error handling - consistent error handling framework - logging, component recovery
• scalability
• portability
• manageability
14.4 the home interface
The home interface of an ejb is an interface that extends the EJBHome interface. It provides
methods named create() with application specific arguments, returning the remote interface and
throwing CreateException and RemoteException. It uses only argument types allowed by
the RMI standard.
Handle – abstraction for a network reference to an EJB.
The methods specified by the EJBHome interface (not implemented (in general) by the
programmer) are the following:
public void remove(Handle han) throws RemoteException, RemoveException

public void remove(Object primaryKey) throws RemoteException,
RemoveException
public EJBMetaData getEJBMetaData() throws RemoteException
public HomeHandle getHomeHandle() throws RemoteException
Code example for the a home interface, called MyBeanHome:
package myBeans;
109
import.javax.ejb.*;
import java.rmi.RemoteException;
public interface MyBeanHome extends EJBHome
{
MyBeanObject create() throws CreateException,
RemoteException;
14.5 the remote interface
The remote interface of a bean is a standard Java interface that extends EJBObject and
Remote and declares the business logic methods of the bean. The developer does not
implement this interface.
While the Remote interface declares no methods, the EJBObject declares the following ones:
public EJBHome getEJBHome() throws RemoteException

public Object getPrimaryKey() throws RemoteException
public Handle getHandle() throws RemoteException
public boolean isIdentical(EJBObject obj) throws
RemoteException
public void remove() throws RemoteException, RemoveException
Code example for a remote interface called MyBeanObject:
package myBeans;
import.javax.ejb.*;
import java.rmi.RemoteException;
public interface MyBeanObject extends EJBObject
{
// assume that we have two business logic methods
void processEntry(String firstName, String lastName, int custId)
throws RemoteException;
void deleteEntry(int custId) throws RemoteException;
14.6 client programmer's viewpoint
For an EJB client application, we need to know:
110
1. how to create or find the bean

2. what methods to use (know its interface)
3. how to release its its resources
The client is able to create an EJB thru an object implementing an interface called EJBHome.
This object acts like a factory for EJBs, creating them for the client application.
The client gains access to the EJB through a remote interface, implemented by an object built
by the EJB host in the deployment process.
Here are the main part of the client code:
authentication
Client's authentication is done in a way which is server specific. In the case of an web
application, this can be done (for example) thru SSL.
getting an initial context
• if the client is another EJB executing in the same container and the bean to be used is
declared as a resource in the deployment descriptor, the InitialContext is already available:
Context ctx = new InitialContext();
• if the client executes outside the container, getting the InitialContext requires the usage of
some server-side properties. Here is an example:
try
{
Properties prop = new Properties();
prop.put(Context.INITIAL_CONTEXT_FACTORY,
"org.jnp.interfaces.NamingContextFactory";
prop.put(Context.PROVIDER_URL,
"localhost:1099");
Context ctx = new InitialContext(prop);
}
find the home interface of the bean
• for a client executing inside the container, the code may look like:
111
Object homeRef = ctx.lookup("java:comp/env/ejb/MyBean");
• if the client executes outside the container, the bean can be associated to any name in the
JNDI name space. It is JNDI's task to identify the resource associated to the name provided:
Object homeRef = ctx.lookup("MyBean");
cast the home interface reference
To make sure that the client works with the underlying communication protocol, the client
should use the narrow() method of javax.rmi.PortableRemoteObject:
MyBeanHome home =
(MyBeanHome)PortableRemoteObject.narrow(homeRef,
MyBeanHome.class);
create an instance of the bean
The instance of the bean is created on the server. The client only has a remote interface to this
instance (i.e. the client has a stub).
Here is the code:
MyBeanObject myBeanObject = home.create();
call business methods on the bean
myBeanObject.processEntry("Dumitrascu", "Vasile", 1102);
remove the bean instance
myBeanObject.remove();
14.7 bean programmer's viewpoint
An EJB consists of (at least) 3 classes and an xml file. It is bean's programmer task to create
them (at least), as follows:
112
1. the bean itself (the class that contains the business logic )
2. the home interface of the bean
3. the remote interface of the bean
4. the deployment descriptor, which is an xml file, called ejb-jar.xml
Since the home interface and the remote interface have been detailed in the previous sections,
we concentrate now on the bean class itself. Besides the implementation of the business methods
(which were declared in the remote interface, as well), the bean class must implement (although
the implementation itself may be empty) a certain set of methods, set which is specific to each
major type of beans (session or entity).
Assuming that our bean (called MyBean) is a session bean, the code implementing this class
may look like this:
package myBeans;
import.javax.ejb.SessionContext;
public class MyBean implements javax.ejb.SessionBean
{
public void processEntry(String firstName, String
lastName, int custId)
{
// method implementation
...
}
public void deleteEntry(int custId)
{
// method implementation
...
}
// mandatory methods for session beans
// method implementations may be empty
public void ejbCreate() {}
public void ejbRemove() {}
public void ejbActivate() {}
public void ejbPassivate() {}
public void setSessionContext(SessionContext ctx) {}
The deployment descriptor of the bean will be detailed in another section.
113
14.8 session beans
There are two types of session beans, namely stateful and stateless beans.
A stateful session bean preserves data between client accesses. A stateless bean does not.
When an EJB server needs to conserve its resources, it can evict stateful session beans from
memory. This reduces the number of instances maintained by the server. To passivate the bean
and preserve its conversational state, the bean's state is serialized to a secondary storage. When
a client invokes a method on the EJB object, the object is activated, that is, a new stateful
instance is instantiated and populated from the passivated storage.
14.9 container callbacks for session beans
There are 5 mandatory callbacks for classes implementing the SessionBean interface.
public void ejbActivate()
public void ejbPassivate()
public void ejbCreate()
public void ejbRemove()
public void setSessionContext(SessionContext ctx)
The first two methods will never be called for stateless session beans, because the container
will never activate a stateless session bean.
14.10 the life cycle of a stateful session bean
Figure 13.1 illustrates the stages that a session bean passes through during its lifetime. The client
initiates the life cycle by invoking the create method. The EJB container instantiates the bean
and then invokes the setSessionContext and ejbCreate methods in the session bean. The
bean is now ready to have its business methods invoked.
Figure 13.1 Life Cycle of a Stateful Session Bean
114
While in the ready stage, the EJB container may decide to deactivate, or passivate, the bean by
moving it from memory to secondary storage. (Typically, the EJB container uses a least-recently-
used algorithm to select a bean for passivation.) The EJB container invokes the bean's
ejbPassivate method immediately before passivating it. If a client invokes a business method
on the bean while it is in the passive stage, the EJB container activates the bean, calls the bean's
ejbActivate method, and then moves it to the ready stage.
At the end of the life cycle, the client invokes the remove method, and the EJB container calls the
bean's ejbRemove method. The bean's instance is ready for garbage collection.
Your code controls the invocation of only two life-cycle methods: the create and remove
methods in the client. All other methods in Figure 13.1 are invoked by the EJB container. The
ejbCreate method, for example, is inside the bean class, allowing you to perform certain
operations right after the bean is instantiated. For example, you might wish to connect to a
database in the ejbCreate method.
14.11 the life cycle of a stateless session bean
Because a stateless session bean is never passivated, its life cycle has only two stages:
nonexistent and ready for the invocation of business methods. Figure 13.2 illustrates the stages of
a stateless session bean.
Figure 13.2 Life Cycle of a Stateless Session Bean
14.12 entity beans
Entity beans represent actual data (usually, stored in a Database).
The EJB container provides the developer several persistence services:

1. container callbacks to manage caching within a transaction
2. support for concurrent access
115
3. maintaining a cache between transactions

4. providing all the persistence management code (no SQL code necessary)
There are 2 main types of entity beans.

• CMPs (Container Managed Persistence)
• BMPs (Bean Managed Persistence) for which the bean developer provides the actual
persistence (SQL) code
14.13 primary keys
Every entity bean has a primary key. This primary key must be represented by a primary key
class. The requirements that must be satisfied by the primary key are different for the two main
types of entity beans.
For BMPs:
• the primary key can be any legal RMI/IIOP type
• it must provide suitable implementations for hashCode(), equals()
• must have a unique value among beans of a particular type
For CMPs:
• the container must be able to create a primary key
• the key class must have a no argument constructor
The fully qualified name of the primary key is always specified in the deployment descriptor
(except when it is not known until deployment)
An example:
<prim-key-class>com.bank11.ccards.CustomerID</prim-key-class>
or
<prim-key-class>java.lang.String</prim-key-class>
In the case of CMP using a simple type as primary key, the field is specified:
<prim-key-field>sportsTeamID</prim-key-field>
14.14 mandatory callbacks for entity beans
Besides the CRUD callbacks which are discusses later in this section, an entity bean must
116
implement (although this implementation may be left empty) the following methods:
public void ejbActivate()

public void ejbPassivate()
public void setEntityContext(EntityContext ctx)
public void unsetEntityContext()
CRUD translates through Create, Read, Update and Delete. These methods are mandatory for
entity beans.
14.14.1 create
When a client calls a create() method on a session bean's home interface, an instance of
that bean is created. On the other side, when a client calls create() on an entity bean's home
interface, state data is stored into data store (usually, a Database) (we actually insert a record in a
database). This is transactional data that is accessible to multiple clients. We can have more
create() methods, all throwing RemoteException, CreateException.
Each create() method from the Home interface of the bean has 2 correspondent methods in
the bean implementation class, namely ejbCreate() and ejbPostCreate(), methods which
have the same parameters, in the same order, as the parameters in the original create()
method.
• the return type of the ejbCreate() is the same as the primary key, but the developer returns
null for CMP.
• for BMP, ejbCreate() must have insertion SQL code and returns an instance of the primary
key, not null.
14.14.2 read
• ejbLoad(), left empty most of the time in CMP, but needs actual SQL code in BMP
• the bean's persistence implementation may choose to defer loading until it is used
• ejbLoad() may contain processing code
14.14.3 update
• ejbStore() in CMP; the method can be used for preprocessing data to be stored, but in
general, it is empty.
• in BMP, actual SQL update code; the updated data is to be stored immediately
14.14.4 delete
• the corresponding method in the bean implementation class is ejbRemove()
• data is deleted from DB (in the CMP case), for BMPs, the programmer will create actual SQL
code.
14.15 the life cycle of an entity bean
117
Figure 13.3 shows the stages that an entity bean passes through during its lifetime. After the EJB
container creates the instance, it calls the setEntityContext method of the entity bean class.
The setEntityContext method passes the entity context to the bean.
After instantiation, the entity bean moves to a pool of available instances. While in the pooled
stage, the instance is not associated with any particular EJB object identity. All instances in the
pool are identical. The EJB container assigns an identity to an instance when moving it to the
ready stage.
There are two paths from the pooled stage to the ready stage. On the first path, the client invokes
the create method, causing the EJB container to call the ejbCreate and ejbPostCreate
methods. On the second path, the EJB container invokes the ejbActivate method. While an
entity bean is in the ready stage, it's business methods can be invoked.
There are also two paths from the ready stage to the pooled stage. First, a client can invoke the
remove method, which causes the EJB container to call the ejbRemove method. Second, the
EJB container can invoke the ejbPassivate method.
Figure 23-6 Life Cycle of an Entity Bean
At the end of the life cycle, the EJB container removes the instance from the pool and invokes the
unsetEntityContext method.
In the pooled state, an instance is not associated with any particular EJB object identity. With
bean-managed persistence, when the EJB container moves an instance from the pooled state to
the ready state, it does not automatically set the primary key. Therefore, the ejbCreate and
ejbActivate methods must assign a value to the primary key. If the primary key is incorrect,
the ejbLoad and ejbStore methods cannot synchronize the instance variables with the
database. The ejbActivate method sets the primary key (id) as follows:
id = (String)context.getPrimaryKey();
118
In the pooled state, the values of the instance variables are not needed. You can make these
instance variables eligible for garbage collection by setting them to null in the ejbPassivate
method.
14.16 message-driven beans
A message-driven bean is an enterprise bean that allows J2EE applications to process messages
asynchronously. It acts as a JMS message listener, which is similar to an event listener except
that it receives messages instead of events. The messages may be sent by any J2EE component
- an application client, another enterprise bean, or a Web component - or by a JMS application or
system that does not use J2EE technology.
Message-driven beans currently process only JMS messages, but in the future they may be used
to process other kinds of messages.
14.16.1 when to use message-driven beans

Session beans and entity beans allow you to send JMS messages and to receive them
synchronously, but not asynchronously. To avoid tying up server resources, you may prefer not to
use blocking synchronous receives in a server-side component. To receive messages in an
asynchronous manner, message-driven bean can be used.
14.16.2 differences between message-driven beans and the other ejb's

The most visible difference between message-driven beans and session and entity beans is that
clients do not access message-driven beans through interfaces. Unlike a session or entity bean, a
message-driven bean has only a bean class.
In several respects, a message-driven bean resembles a stateless session bean.
• a message-driven bean's instances retain no data or conversational state for a specific
client.
• all instances of a message-driven bean are equivalent, allowing the EJB container to
assign a message to any message-driven bean instance. The container can pool these
instances to allow streams of messages to be processed concurrently.
• a single message-driven bean can process messages from multiple clients.
The instance variables of the message-driven bean instance can contain some state across the
handling of client messages - for example, a JMS API connection, an open database connection,
or an object reference to an enterprise bean object.
When a message arrives, the container calls the message-driven bean's onMessage method to
process the message. The onMessage method normally casts the message to one of the five
JMS message types and handles it in accordance with the application's business logic. The
onMessage method may call helper methods, or it may invoke a session or entity bean to
process the information in the message or to store it in a database.
A message may be delivered to a message-driven bean within a transaction context, so that all
operations within the onMessage method are part of a single transaction. If message processing
is rolled back, the message will be redelivered.
14.16.3 differences between message-driven beans and stateless session

EJBs
Although the dynamic creation and allocation of message-driven bean instances mimics the
behavior of stateless session EJB instances, message-driven beans are different from stateless
119
session EJBs (and other types of EJBs) in several significant ways:

• message-driven beans process multiple JMS messages asynchronously, rather than
processing a serialized sequence of method calls.
• message-driven beans have no home or remote interface, and therefore cannot be
directly accessed by internal or external clients. Clients interact with message-driven
beans only indirectly, by sending a message to a JMS Queue or Topic.
14.16.4 concurrent support for message-driven beans

Message-driven Beans support concurrent processing for both topics and queues. Previously, only
concurrent processing for Queues was supported.
To ensure concurrency, change the weblogic-ejb-jar.xml deployment descriptor max-
beans-in-free-pool setting to >1. If this element is set to more than one, the container will
spawn as many threads as specified. For more information on this element see, max-beans-in-
free-pool.
14.16.5 invoking a message-driven bean

When a JMS Queue or Topic receives a message, use WebLogic Server to call an associated
message-driven bean as follows:
1. Obtain a new bean instance.
Obtain a new bean instance from the connection pool if one already exists, or create a
new one. See Creating and Removing Bean Instances.
2. If the bean cannot be located in the pool and a new one must be created, call the bean's
setMessageDrivenContext() to associate the instance with a container context. The bean
can utilize elements of this context as described in Using the Message-Driven Bean
Context.
3. Call the bean's onMessage() method to perform business logic. See Implementing
Business Logic with onMessage().
Note: These instances can be pooled.
14.16.6 developing message-driven beans

To create message-driven EJBs, you must follow certain conventions described in the JavaSoft
EJB 2.0 specification, as well as observe several general practices that result in proper bean
behavior.
14.16.7 bean class requirements

The EJB 2.0 specification provides detailed guidelines for defining the methods in a message-
driven bean class. The following output shows the basic components of a message-driven bean
class. Classes, methods, and method declarations in bold are required as part of the EJB 2.0
specification:
public class MessageTraderBean implements javax.ejb.MessageDrivenBean
{
public MessageTraderBean() {...};
// An EJB constructor is required, and it must not
// accept parameters. The constructor must not be declared as
// final or abstract.
public void onMessage(javax.jms.Message MessageName) {...}
// onMessage() is required, and must take a single parameter of
// type javax.jms.Message. The throws clause (if used) must not
120
// include an application exception. onMessage() must not be

// declared as final or static.
public void ejbRemove() {...}
// ejbRemove() is required and must not accept parameters.
// The throws clause (if used) must not include an application
//exception. ejbRemove() must not be declared as final or static.
finalize{};
// The EJB class cannot define a finalize() method
}
Creating and Removing Bean Instances
The WebLogic Server container calls the message-driven bean's ejbCreate() and
ejbRemove() methods when creating or removing an instance of the bean class. As with other
EJB types, the ejbCreate() method in the bean class should prepare any resources that are
required for the bean's operation. The ejbRemove() method should release those resources, so
that they are freed before WebLogic Server removes the instance.
Message-driven beans should also perform some form of regular clean-up routine outside of the
ejbRemove() method, because the beans cannot rely on ejbRemove() being called under all
circumstances (for example, if the EJB throws a runtime exception).
14.16.8 using the message-driven bean context

WebLogic Server calls setMessageDrivenContext() to associate the message-driven bean
instance with a container context.This is not a client context; the client context is not passed along
with the JMS message. WebLogic Server provides the EJB with a container context, whose
properties can be accessed from within the instance by using the following methods from the
MessageDrivenContext interface:
• getCallerPrincipal()
• isCallerInRole()
• setRollbackOnly()- The EJB can use this method only if it utilizes container-
managed transaction demarcation.
• getRollbackOnly() - The EJB can use this method only if it utilizes container-
• getUserTransaction()- The EJB can use this method only if it utilizes bean-
Note: Although getEJBHome() is also inherited as part of the MessageDrivenContext
interface, message-driven EJBs do not have a home interface. Calling getEJBHome()
from within a message-driven EJB instance yields an IllegalStateException.
14.16.9 implementing business logic with onMessage()

The message-driven bean's onMessage() method performs all of the business logic for the EJB.
WebLogic Server calls onMessage() when the EJB's associated JMS Queue or Topic receives a
message, passing the full JMS message object as an argument. It is the message-driven EJB's
responsibility to parse the message and perform the necessary business logic in onMessage().
Make sure that the business logic accounts for asynchronous message processing. For example,
it cannot be assumed that the EJB receives messages in the order they were sent by the client.
Instance pooling within the container means that messages are not received or processed in a
sequential order, although individual onMessage() calls to a given message-driven bean
instance are serialized.
See javax.jms.MessageListener.onMessage() for more information.
121
14.16.10 handling exceptions

Message-driven bean methods should not throw an application exception or a
RemoteException, even in onMessage(). If any method throws such an exception, WebLogic
Server immediately removes the EJB instance without calling ejbRemove(). However, from the
client perspective the EJB still exists, because future messages are forwarded to a new instance
that WebLogic Server creates.
14.16.11 transaction services for message-driven beans

As with other EJB types, message-driven beans can demarcate transaction boundaries either on
their own (using bean-managed transactions), or by having the WebLogic Server container
manage transactions (container-managed transactions). In either case, a message-driven bean
does not receive a transaction context from the client that sends a message. WebLogic Server
always calls a bean's onMessage() method by using the transaction context specified in the
bean's deployment descriptor, as required by the EJB 2.0 specification.
Because no client provides a transaction context for calls to a message-driven bean, beans that
use container-managed transactions must be deployed using the Required or NotSupported
transaction attribute in ejb-jar.xml. Transaction attributes are defined in ejb-jar.xml as
follows:
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>MyMessageDrivenBeanQueueTx</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>NotSupported</trans-attribute>
</container-transaction>
</assembly-descriptor>
14.16.12 message receipts

The receipt of a JMS message that triggers a call to an EJB's onMessage() method is not
generally included in the scope of a transaction. For EJBs that use bean-managed transactions,
the message receipt is always outside the scope of the bean's transaction, as described in the
EJB 2.0 specification.
For EJBs that use container-managed transaction demarcation, WebLogic Server includes the
message receipt as part of the bean's transaction only if the bean's transaction attribute is set to
Required.
14.16.13 message acknowledgment

For message-driven beans that use container-managed transaction demarcation, WebLogic
Server automatically acknowledges a message when the EJB transaction commits. If the EJB
uses bean-managed transactions, both the receipt and the acknowledgment of a message occur
outside of the EJB transaction context. WebLogic Server automatically acknowledges messages
for EJBs with bean-managed transactions, but the deployer can configure acknowledgment
semantics using the jms-acknowledge-mode deployment parameter.
Deploying Message-Driven Beans in WebLogic Server
To deploy a message-driven bean on WebLogic Server, you edit the XML file to create the
deployment descriptors that associate the EJB with a configured JMS destination.
Deployment Descriptors
The deployment descriptor for a message-driven bean also specifies:
122
• Whether the EJB is associated with a JMS Topic or Queue

• Whether an associated Topic is durable or non-durable
• Transaction attributes for the EJB
• JMS acknowledgment semantics to use for beans that demarcate their own transactions
14.16.14 deployment elements

The EJB 2.0 specification adds the following new XML deployment elements for deploying
message-driven beans.
• message-driven-destination specifies whether the EJB should be associated
with a JMS Queue or Topic destination.
• subscription-durability specifies whether or not an associated Topic
should be durable.
• jms-acknowledge-mode specifies the JMS acknowledgment semantics to use
for beans that demarcate their own transaction boundaries. This element has
two possible values: AUTO_ACKNOWLEDGE (the default) or
DUPS_OK_ACKNOWLEDGE.
These elements are defined in the ejb-jar.xml deployment file, as described in the EJB 2.0
specification. The following excerpt shows a sample XML stanza for defining a message-driven
bean:
<enterprise-beans>
<message-driven>
<ejb-name>exampleMessageDriven1</ejb-name>
<ejb-class>examples.ejb20.message.MessageTraderBean</ejb-class>
<transaction-type>Container</transaction-type>
<message-driven-destination>
<jms-destination-type>
javax.jms.Topic
</jms-destination-type>
</message-driven-destination>
...
</message-driven>
...
</enterprise-beans>
In addition to the new ejb-jar.xml elements, the weblogic-ejb-jar.xml file includes a new
message-driven-descriptor stanza to associate the message-driven bean with an actual
destination in WebLogic Server.
14.17 the life cycle of a message-driven bean
Figure 13.4 illustrates the stages in the life cycle of a message-driven bean.
The EJB container usually creates a pool of message-driven bean instances. For each instance,
the EJB container instantiates the bean and performs these tasks:
1. It calls the setMessageDrivenContext method to pass the context object to the
instance.
2. It calls the instance's ejbCreate method.
123
Figure 13.4 Life Cycle of a Message-Driven Bean
Like a stateless session bean, a message-driven bean is never passivated, and it has only two
states: nonexistent and ready to receive messages.
At the end of the life cycle, the container calls the ejbRemove method. The bean's instance is
then ready for garbage collection.
14.18 the deployment descriptor
The deployment descriptor of an EJB contains information about the bean in relation to the
application it belongs to.
This information can be divided into two main categories:
• structural information related to a particular EJB.
• application assembly information
Although not an exhaustive one, here is a typical list of entries (elements) in a deployment
descriptor:
1. access control entries - security issues; which users can access a bean or a particular
method of a bean
2. bean home name - name under which the bean is registered under JNDI
3. control descriptors - specifies control attributes for transactions
4. EJB class name
5. environment properties
6. the home interface name
7. the remote interface name
8. session specific elements
9. entity specific elements
10. attributes - like transaction, isolation level, security
124
Keeping in mind that the application assembler is to follow, here is how the deployment
descriptor may look like:
<?xnm version="1.1"?>
<ejb-jar>
<entrprise-beans>
<session>
<ejb-name>CCEnroll</ejb-name>
<home>com.bank11.ccards.ejb.CCEnrollHome</home>
<remote>com.bank11.ccards.CCEnrollObject</remote>
<ejb-class>com.bank11.ccards.CCEnroll</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container<transaction-type>
<ejb-ref>
<ejb-ref-name>ejb/CCAccount</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<home>com.bank11.ccards.ejb.AccountHome</home>
<remote>com.bank11.ccards.ejb.AccountObj</remote>
</ejb-ref>
<security-role-ref>
<description>
This role relates to cash advances from ATMs
</description>
<role-name>CashAdvATM</role-name>
<security-role-ref>
</session>
<entity>
<ejb-name>Account</ejb-name>
<home>com.bank11.ccards.ejb.AccountHome</home>
<remote>com.bank11.ccards.Accountbject</remote>
<ejb-class>com.bank11.ccards.Account</ejb-class>
<persistence-type>Container</persistence-type>
<prim-key-class>java.lang.Integer</prim-key-class>
<reentrant>False</reentrant>
<cmp-field>
125
<field-name>accountNumber</field-name>
</cmp-field>
<cmp-field>
<field-name>userName</field-name>
</cmp-field>
<cmp-field>
<field-name>customerID</field-name>
</cmp-field>
<cmp-field>
<prim-key-field>accountNumber</prim-key-field>
</cmp-field>
<env-entry>
<env-entry-name>env/minPaymentPerc</env-entry-name>
<env-entry-type>java.lang.Float</env-entry-type>
<env-entry-value>2.5</env-entry-value>
</env-entry>
</entity>
</enterprise-beans>
</ejb-jar>
The assembly descriptor combines EJBs into a deployable application. Here is a very lean one:
</ejb-jar>
<enterprise-beans>
...
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>CCEnroll</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>
126
127

Curs Tehnologii Web

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Curs Tehnologii Web

Uploaded by

Copyright:

Available Formats

1 - INTRODUCTION

1.2 the OSI model

Nr. Layer Description Protocol examples

5 Network Responsible for source to destination DDP, ICMP, IPSec, IPv4,

For a detailed description of these layers, check the site:

1.3 sockets - basics

Port number UDP protocol TCP protocol Other

2. registered ports - ranging from 1024 to 49151 – registered by ICANN, as a convenience

Port number UDP protocol TCP protocol Other

5050 Yahoo Messenger

3. dynamic (private) ports, ranging from 49152 to 65535

1.4 posix sockets

int socket(int family, int type, int protocol);

2.2 the structure of http transactions

<optional data block>

2.3 the initial request line

Contains 3 elements, separated by spaces:

Here is an example of an initial request line:

2.4 http commands (methods)

2.5 the GET and POST methods

- Annotation of existing resources;

- Providing a block of data, such as the result of submitting a

2.6 differences between GET and POST

2.7 the initial response (status) line

2.8 the status code

• 3xx redirects the client to another URL

2.9 header lines

2.10 the message body

2.11 mime types/subtypes

2.12 an example of an http transaction

To retrieve the file at the URL

After sending the response, the server closes the socket.

3.2 language definition

HTML is a system for describing documents. It is a special version of SGML (Standard

<!SGML "ISO 8879:1986"

3.3 html elements

An HTML element consists of:

<IMG SRC=”/images/logo.gif” ALT=”logo” HEIGHT=40 WIDTH=120>

3.3.1 The <A> element

3.3.2 The <IMG> element

3.4 the minimal structure of an html document

A minimal HTML document example:

3.6 table related elements

the <THEAD> element

the <TH> element

the <TR> element

the <TD> element

• "application/x-www-form-urlencoded" - the default value; however, since it converts spaces

3.8 form related elements

3.8.1 the <INPUT> element

3.8.2 the <SELECT> element

3.8.3 the <OPTION> element

Example of a <SELECT> element:

<SELECT NAME="action" STYLE="font-family: '@Arial Unicode

<OPTION>View Account Activity

4.2 java the interpreter, jit

4.3 java applications

public static void main(String[] args)

java [-options] class [args]

Where main options are:

To execute a .jar file, use the command:

java –jar [-options] jarfile [args]

4.4 object oriented concepts