Академический Документы
Профессиональный Документы
Культура Документы
The Java EE 7 (released in august 2013) is the current Java Enterprise Edition specification.
Compared to the previous specification, Java EE 7 introduces several new features:
New technologies, including the following:
Batch Applications for the Java Platform
Concurrency Utilities for Java EE
Java API for JSON Processing (JSON-P)
Java API for WebSocket
New features for Enterprise JavaBeans ( EJB) components (see Enterprise JavaBeans
Technology for details)
New features for servlets (see Java Servlet Technology for details)
New features for JavaServer Faces components (see JavaServer Faces Technology for
details)
New features for the Java Message Service (JMS) (see Java Message Service API for
details)
The next release is Java EE 8 and it's final specification is scheduled for 2017. The Java EE 8
specification is part of JSR 366 and (as of sept. 2015) the following schedule is expected:
Q4 2015 - early draft
Q1 2016 - public review
Q3 2016 - proposed final draft
H1 2017 - final release
The application model starts with the Java programming language and the Java Virtual Machine.
This combination provides high portability, scalability and developing efficiency.
Java EE is designed to support applications that implement enterprise services for customers,
employees, suppliers, partners, and others who make demands on or contributions to the enterprise.
Such applications are inherently complex, potentially accessing data from a variety of sources and
distributing applications to a variety of clients.
To better control and manage these applications, the business functions to support these various
1
1 - java platform, enterprise edition
users are conducted in the middle tier. The middle tier is typically run on dedicated server hardware
and has access to the full services of the enterprise.
The Java EE application model defines an architecture for implementing services as multi-tier
applications that deliver the scalability, accessibility, and manageability needed by enterprise-level
applications. This model partitions the work needed to implement a multi-tier service into two parts: the
business and presentation logic to be implemented by the developer, and the standard system
services provided by the Java EE platform. The developer can rely on the platform to provide solutions
for the hard systems-level problems of developing a multi-tier service.
The Java EE platform uses a distributed multitiered application model for enterprise applications.
Application logic is divided into components according to function, and the various application
components that make up a Java EE application are installed on different machines depending on the
tier in the multitiered Java EE environment to which the application component belongs. Figure 1.1
shows generic multitiered Java EE applications divided into the tiers described in the list below. The
Java EE application parts shown in figure 1.1 are presented in the Java EE components section.
client-tier components run on the client machine.
web-tier components run on the Java EE server.
business-tier components run on the Java EE server.
enterprise information system (EIS)-tier software runs on the EIS server
2
1 - java platform, enterprise edition
Although a Java EE application can consist of the three or four tiers shown in figure 1.1, Java EE
multitiered applications are generally considered to be three-tiered applications because they are
distributed over three locations: client machines, the Java EE server machine, and the database or
legacy machines at the back end. Three-tiered applications that run in this way extend the standard
two-tiered client and server model by placing a multithreaded application server between the client
application and back-end storage.
1.5.2 Applets
A web page received from the web tier can include an embedded applet. An applet is a small client
application written in the Java programming language that executes in the Java virtual machine
installed in the web browser. However, client systems will likely need the Java Plug-in and possibly a
security policy file in order for the applet to successfully execute in the web browser.
3
1 - java platform, enterprise edition
user interface (GUI) created from the Swing or the Abstract Window Toolkit (AWT) API, but a
command-line interface is certainly possible.
Application clients directly access enterprise beans running in the business tier. However, if
application requirements warrant it, an application client can open an HTTP connection to establish
communication with a servlet running in the web tier. Application clients written in languages other
than Java can interact with Java EE 7 servers, enabling the Java EE 7 platform to interoperate with
legacy systems, clients, and non-Java languages.
4
1 - java platform, enterprise edition
Java EE web components are either servlets or pages created using JSP technology (JSP pages)
and/or Java Server Faces technology. Servlets are Java programming language classes that
dynamically process requests and construct responses. JSP pages are text-based documents that
execute as servlets but allow a more natural approach to creating static content. Java Server Faces
technology builds on servlets and JSP technology and provides a user interface component framework
for web applications.
Static HTML pages and applets are bundled with web components during application assembly but
are not considered web components by the Java EE specification. Server-side utility classes can also
be bundled with web components and are not considered web components.
The web tier, like the client tier, might include a JavaBeans component to manage the user input
and send that input to enterprise beans running in the business tier for processing.
Business code, which is logic that solves or meets the needs of a particular business domain such
as banking, retail, or finance, is handled by enterprise beans running in the business tier. Figure 1.3
shows how an enterprise bean receives data from client programs, processes it (if necessary), and
sends it to the enterprise information system tier for storage. An enterprise bean also retrieves data
from storage, processes it (if necessary), and sends it back to the client program.
5
1 - java platform, enterprise edition
The enterprise information system tier handles EIS software and includes enterprise infrastructure
systems such as enterprise resource planning (ERP), mainframe transaction processing, database
systems, and other legacy information systems. For example, Java EE application components might
need access to enterprise information systems for database connectivity.
Normally, thin-client multitiered applications are hard to write because they involve many lines of
intricate code to handle transaction and state management, multithreading, resource pooling, and
other complex low-level details. The component-based and platform-independent Java EE
architecture makes Java EE applications easy to write because business logic is organized into
reusable components. In addition, the Java EE server provides underlying services in the form of a
container for every component type. Because you do not have to develop these services yourself, you
are free to concentrate on solving the business problem at hand.
6
1 - java platform, enterprise edition
Java EE server - the runtime portion of a Java EE product. A Java EE server provides EJB
and web containers.
Enterprise JavaBeans (EJB) container - manages the execution of enterprise beans for Java
EE applications. Enterprise beans and their container run on the Java EE server.
Web container - manages the execution of JSP page and servlet components for Java EE
applications. Web components and their container run on the Java EE server.
Application client container - manages the execution of application client components.
Application clients and their container run on the client.
Applet container - manages the execution of applets. Consists of a web browser and Java
Plug-in running on the client together.
Web services are web-based enterprise applications that use open, XML-based standards and
transport protocols to exchange data with calling clients. The Java EE platform provides the XML APIs
and tools you need to quickly design, develop, test, and deploy web services and clients that fully
interoperate with other web services and clients running on Java-based or non-Java-based platforms.
To write web services and clients with the Java EE XML APIs, all you do is pass parameter data to
the method calls and process the data returned; or for document-oriented web services, you send
documents containing the service data back and forth. No low-level programming is needed because
the XML API implementations do the work of translating the application data to and from an XML-
based data stream that is sent over the standardized XML-based transport protocols. These XML-
based standards and protocols are introduced in the following sections.
The translation of data to a standardized XML-based data stream is what makes web services and
clients written with the Java EE XML APIs fully interoperable. This does not necessarily mean that the
7
1 - java platform, enterprise edition
data being transported includes XML tags because the transported data can itself be plain text, XML
data, or any kind of binary data such as audio, video, maps, program files, computer-aided design
(CAD) documents and the like. The next section introduces XML and explains how parties doing
business can use XML tags and schemas to exchange data in a meaningful way.
1.10.1 XML
XML is a cross-platform, extensible, text-based standard for representing data. When XML data is
exchanged between parties, the parties are free to create their own tags to describe the data, set up
schemas to specify which tags can be used in a particular kind of XML document, and use XML
stylesheets to manage the display and handling of the data.
For example, a web service can use XML and a schema to produce price lists, and companies that
receive the price lists and schema can have their own stylesheets to handle the data in a way that best
suits their needs. Here are examples:
One company might put XML pricing information through a program to translate the XML to
HTML so that it can post the price lists to its intranet.
A partner company might put the XML pricing information through a tool to create a marketing
presentation.
Another company might read the XML pricing information into an application for processing.
8
1 - java platform, enterprise edition
Figure 1.5 illustrates the availability of the Java EE 6 platform APIs in each Java EE container type.
The following sections give a brief summary of the technologies required by the Java EE platform, and
the APIs used in Java EE applications.
9
1 - java platform, enterprise edition
10
1 - java platform, enterprise edition
11
1 - java platform, enterprise edition
12
1 - java platform, enterprise edition
13
1 - java platform, enterprise edition
named Java object, allowing Java EE applications to coexist with many legacy applications and
systems.
Java EE naming services provide application clients, enterprise beans, and web components with
access to a JNDI naming environment. A naming environment allows a component to be customized
without the need to access or change the component's source code. A container implements the
component's environment and provides it to the component as a JNDI naming context.
A Java EE component can locate its environment naming context using JNDI interfaces. A
component can create a javax.naming.InitialContext object and looks up the environment
naming context in InitialContext under the name java:comp/env. A component's naming
environment is stored directly in the environment naming context or in any of its direct or indirect
subcontexts.
A Java EE component can access named system-provided and user-defined objects. The names of
system-provided objects, such as JTA UserTransaction objects, are stored in the environment
naming context, java:comp/env. The Java EE platform allows a component to name user-defined
objects, such as enterprise beans, environment entries, JDBC DataSource objects, and message
connections. An object should be named within a subcontext of the naming environment according to
the type of the object. For example, enterprise beans are named within the subcontext
java:comp/env/ejb, and JDBC DataSource references in the subcontext
java:comp/env/jdbc.
14
1 - java platform, enterprise edition
A Java EE application is packaged into one or more standard units for deployment to any Java EE
platform-compliant system. Each unit contains:
A functional component or components (such as an enterprise bean, JSP page, servlet, or
applet)
An optional deployment descriptor that describes its content
Once a Java EE unit has been produced, it is ready to be deployed. Deployment typically involves
using a platforms deployment tool to specify location-specific information, such as a list of local users
that can access it and the name of the local database. Once deployed on a local platform, the
application is ready to run.
A Java EE application is delivered in an Enterprise Archive (EAR) file, a standard Java Archive
(JAR) file with an .ear extension. Using EAR files and modules makes it possible to assemble a
number of different Java EE applications using some of the same components. No extra coding is
needed; it is only a matter of assembling (or packaging) various Java EE modules into Java EE EAR
files.
An EAR file contains Java EE modules and deployment descriptors. A deployment descriptor is
an XML document with an .xml extension that describes the deployment settings of an application, a
module, or a component. Because deployment descriptor information is declarative, it can be changed
without the need to modify the source code. At runtime, the Java EE server reads the deployment
descriptor and acts upon the application, module, or component accordingly.
15
1 - java platform, enterprise edition
There are two types of deployment descriptors: Java EE and runtime. A Java EE deployment
descriptor is defined by a Java EE specification and can be used to configure deployment settings on
any Java EE-compliant implementation. A runtime deployment descriptor is used to configure Java
EE implementation-specific parameters. For example, the Sun Java System Application Server
Platform Edition 9 runtime deployment descriptor contains information such as the context root of a
web application, the mapping of portable names of an applications resources to the servers
resources, and Application Server implementation-specific parameters, such as caching directives.
The Application Server runtime deployment descriptors are named sun-moduleType.xml and are
located in the same META-INF directory as the Java EE deployment descriptor.
A Java EE module consists of one or more Java EE components for the same container type and
one component deployment descriptor of that type. An enterprise bean module deployment descriptor,
for example, declares transaction attributes and security authorizations for an enterprise bean. A Java
EE module without an application deployment descriptor can be deployed as a stand-alone module.
The four types of Java EE modules are as follows:
EJB modules, which contain class files for enterprise beans and an EJB deployment
descriptor. EJB modules are packaged as JAR files with a .jar extension.
Web modules, which contain servlet class files, JSP files, supporting class files, GIF and
HTML files, and a web application deployment descriptor. Web modules are packaged as JAR
files with a .war (Web ARchive) extension.
Application client modules, which contain class files and an application client deployment
descriptor. Application client modules are packaged as JAR files with a .jar extension.
Resource adapter modules, which contain all Java interfaces, classes, native libraries, and
other documentation, along with the resource adapter deployment descriptor. Together, these
implement the Connector architecture (see J2EE Connector Architecture) for a particular EIS.
Resource adapter modules are packaged as JAR files with an .rar (resource adapter
archive) extension.
16
1 - java platform, enterprise edition
In this section we attempt to answer a recurrent question why bother with servlets, java server
pages or java server faces when we can achieve faster the same results using a versatile language
like PHP? Without ignoring its major qualities, let's point out some of weaknesses of PHP, which are
inherent to its nature.
PHP scripts are tied to a the web server and require writing explicit database queries to generate
dynamic content. Even these queries are written in a way which is specific to a particular database
engine. In PHP, the application programmer writes the SQL queries and embeds them directly into the
script, mixing presentation and business logic in the process. No direct support is provided for the
management of component pooling and lifecycle management, client session management, database
connection pooling, persistence, transaction management, authentication, and access control. On the
other hand, all these may be achieved through an application server.
For those who want a deeper understanding of this debate, the following links may help.
http://stiri.rol.ro/dezbatere-forum-la-link-academy-php-vs-java-820468.html
http://www.cs.montana.edu/~tosun/phpvsjava.pdf
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=java&lang2=php
http://raibledesigns.com/rd/entry/php_vs_java_which_is
http://brand-maestro.com/php-vs-java-programming-language-better-future/
17
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 official version HTTP 1.0 dates from 05/95 and is the object of RFC 1945
(www.apps.ietf.org/rfc/rfc1945.html). It is authored by Tim Berners-Lee, Roy Fielding and Henrik
Nielsen.
The second 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.
The next version of the HTTP specification is HTTP 2.0 (or HTTP/2) has been released as RFC
7540 in May 2015 - https://tools.ietf.org/html/rfc7540
The working group for HTTP/2 hopes to address the following issues and goals:
Negotiation mechanism that allows clients and servers to elect to use HTTP 1.1, 2.0, or
potentially other non-HTTP protocols.
Maintain high-level similarity with HTTP 1.1 (for example with methods, status codes, header
fields, and URIs, and most header fields)
Decrease latency to improve page load speed in web browsers by considering:
Data compression of HTTP headers
Server push technologies
Fixing the head-of-line blocking problem in HTTP 1
Loading page elements in parallel over a single TCP connection
Support common existing use cases of HTTP, such as desktop web browsers, mobile web
browsers, web APIs, web servers at various scales, proxy servers, reverse proxy servers,
firewalls, and content delivery networks
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
18
2 - HTTP
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.
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:
19
2 - HTTP
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.
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.
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
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
3xx redirects the client to another URL
20
2 - HTTP
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.
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.
MIME stands for Multipurpose Internet Mail Extensions. Each extension consists of a type and a
subtype. RFC 1521 (www.apps.ietf.org/rfc/rfc1521.html) defines 7 types and several subtypes,
21
2 - HTTP
<html>
<body>
<h1>Happy birthday!</h1>
(more file contents)
.
.
</body>
</html>
22
2 - HTTP
HTTP/2 provides an optimized transport for HTTP semantics. HTTP/2 supports all of the core
features of HTTP/1.1 but aims to be more efficient in several ways.
The basic protocol unit in HTTP/2 is a frame. Each frame type serves a different purpose. For
example, HEADERS and DATA frames form the basis of HTTP requests and responses; other frame
types like SETTINGS, WINDOW_UPDATE, and PUSH_PROMISE are used in support of other
HTTP/2 features.
Flow control and prioritization ensure that it is possible to efficiently use multiplexed streams.
Flow control helps to ensure that only data that can be used by a receiver is transmitted. Prioritization
ensures that limited resources can be directed to the most important streams first.
HTTP/2 adds a new interaction mode whereby a server can push responses to a client. Server
push allows a server to speculatively send data to a client that the server anticipates the client will
need, trading off some network usage against a potential latency gain. The server does this by
synthesizing a request, which it sends as a PUSH_PROMISE frame. The server is then able to send a
response to the synthetic request on a separate stream.
Because HTTP header fields used in a connection can contain large amounts of redundant data,
frames that contain them are compressed. This has especially advantageous impact upon request
sizes in the common case, allowing many requests to be compressed into one packet.
23
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 (http://www.apps.ietf.org/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 latest version of HTML as SGML application is 4.01. It is a revision of 4.0 and was accepted in
December 1997. However, a working draft for the next major revision, namely HTML 5 was published
in January 2008. Originally named Web Applications 1.0, the specification includes several ideas of
the WHAT (Web Hypertext Application Technology) working group. It might take several years (a
formal target has been set for 2014) before the specification reaches final Recommendation status.
From 1999 on, HTML is part of a new specification XHTML. The XHTML 1.0 draft was released in
01.99 and mirrors the HTML 4.01 specification. The latest version (XHTML 2.0) was a working draft
but was abandoned in 2009 in favor of work on XHTML5, which is being defined alongside HTML5.
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 .
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.
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
13 1 13
24
3 - HTML
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
OTHER
CONCUR NO
25
3 - HTML
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: <, ", "水" (in
hexadecimal) - the chinese character for water. You get the point.
3.3 html5
As of December 2012, HTML5 is a candidate recommendation of the World Wide Web Consortium
(W3C). Its core aims have been to improve the language with support for the latest multimedia while
keeping it easily readable by humans and consistently understood by computers and devices (web
browsers, parsers, etc.). HTML5 is intended to subsume not only HTML 4, but also XHTML 1 and
DOM Level 2 HTML.
In October 2014, the HML5 specification was finalized and published as a W3C Recommendation.
It includes detailed processing models to encourage more interoperable implementations; it
extends, improves and rationalises the markup available for documents, and introduces markup and
application programming interfaces (APIs) for complex web applications.
HTML5 adds many new syntactic features. These include the new <video>, <audio> and <canvas>
elements, as well as the integration of scalable vector graphics (SVG) content (that replaces the uses
of generic<object> tags) and MathML for mathematical formulas. These features are designed to
make it easy to include and handle multimedia and graphical content on the web without having to
resort to proprietary plugins and APIs. Other new elements, such as <section>, <article>, <header>
and <nav>, are designed to enrich the semantic content of documents. New attributes have been
introduced for the same purpose, while some elements and attributes have been removed.
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
26
3 - HTML
element. An example:
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 <!-- and end at the first occurrence of -->. An
example:
Example:
<A HREF=http://web.info.uvt.ro/webmail/src/login.php>Login to
web mail</A>
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
27
3 - HTML
</HTML>
3.6 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 headers
and consist of a brief description of the content of the corresponding column. Here is a an example of
a table:
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
28
3 - HTML
3.8 forms
A form is a basic component container, allowing user input and parameter 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
29
3 - HTML
ENCTYPE - specifies the encoding type of the of the form content. Default value:
"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"
30
3 - HTML
31
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 (as of 10.2014) of Java Platform Enterprise
Edition is Java EE 7.
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
There exist 2 types of programs that can be written in Java. The first type are embedded in web
pages applets, the others are the standalone programs Java applications.
A java applet is a 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
32
4 - JAVA PRIMER
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:
A compiled java application (class) may be executed from the command line using an executable
called java (the java interpreter), as follows:
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:
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,
33
4 - JAVA PRIMER
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.
All basic types have associated classes which extend their functionality, namely: Byte, Short,
Integer, Long, Float, Double, Boolean, Character.
Other peculiarities: no pointers (only references), automatic garbage collection, no templates.
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)
34
4 - JAVA PRIMER
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.
35
4 - JAVA PRIMER
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.
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).
36
4 - JAVA PRIMER
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.
37
5 - javaScript
5 - JAVASCRIPT
5.1 so what is JavaScript?
The initial official name of this language was ECMAScript. ECMA stands for European Computer
Manufacturers Association and is an organization founded in 1961 to standardize computer systems in
Europe. The origins of this language date back to 1995, and was originally developed by Brendan Eich
of Netscape under the names Mocha, then LiveScript and finally, as JavaScript. Subsequently,
JavaScript was standardized by ECMA in June 1997 under the name ECMAScript. However, the
general public knows it only by the name given by its creator JavaScript. Adaptations of the ECMA
standard for other applications, like KDE or Adobe Flash bear different names, like QtScript or
ActionScript.
The version history of ECMAScript starts with version 1.0 from 03.1996, continuing with 1.1 in
08.1996, , version 1.5 in 11.2000 and the latest one, 1.8.5 dating back to 07.2010, but the whole
concept of versioning seems to be on verge of removal.
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
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
38
5 - javaScript
<html>
<head>
<script type="text/javascript">
....
</script>
</head>
<html>
<head>
</head>
<body>
<script type="text/javascript">
....
</script>
</body>
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>
A variable is a "container" for some information whose value can change during the script.
39
5 - javaScript
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.
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:
40
5 - javaScript
<html>
<body>
<script type="text/javascript">
var x;
var mycars = new Array();
mycars[0] = "Saab";
mycars[1] = "Volvo";
mycars[2] = "BMW";
for (x in mycars)
{
document.write(mycars[x] + "<br />");
}
</script>
</body>
</html>
try
{
// run some code here
}
catch(err)
{
// handle errors here
}
Example
<html>
41
5 - javaScript
<head>
<script type="text/javascript">
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";
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.
Syntax:
alert("sometext")
42
5 - javaScript
Syntax:
confirm("sometext")
Syntax:
prompt("sometext","defaultvalue")
5.8 functions
<html>
<head>
<script type="text/javascript">
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..
var1, var2, etc are variables or values passed into the function. The { and the } defines the start and
end of the function.
Note: Do not forget about the importance of capitals in JavaScript! The word function must be
43
5 - javaScript
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.
When you call the function above, you must pass along two parameters:
product=prod(2,3)
The returned value from the prod() function is 6, and will be stored in the variable called product.
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:
<script type="text/javascript">
var txt="Hello World!";
document.write(txt.length);
</script>
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:
<script type="text/javascript">
var str="Hello world!";
document.write(str.toUpperCase());
</script>
44
5 - javaScript
We can think of each Web page as a collection of several individual elements, which are called
Objects. For example, every Image on the page is an Object, every Link on the page is an Object.
Even this Document itself is an Object. At its most basic level, JavaScript allows you to control the
appearance of many of the Objects that make up a Web page as we previously saw.
Objects are storage containers that have Properties (data values associated with Objects) and
Methods (functions associated with Objects) that operate on that data. Objects may also have certain
Events that are associated with them. Events are special signals or messages which occur when
certain pre-defined actions take place within a Web browser, or when the user interacts with a Web
page. When an event message has been triggered, you need a way to intercept the message and
react to it. This is achieved through the use of Event Handlers.
For an exhaustive list of properties and methods of the above objects (and for the built in objects, as
well), check the site http://www.w3schools.com/jsref/default.asp
45
5 - javaScript
Properties
FF: Firefox, N: Netscape, IE: Internet Explorer
Property Description F N I
F E
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 F N I
F E
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
46
5 - javaScript
Properties
FF: Firefox, N: Netscape, IE: Internet Explorer
F I
Property Description N
F E
constructor Returns a reference to the Date function that created the 1 4 4
object
prototype Allows you to add properties and methods to the object 1 3 4
Methods
F I
Method Description N
F E
Date() Returns today's date and time 1 2 3
getDate() Returns the day of the month from a Date object (from 1- 1 2 3
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)
47
5 - javaScript
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)
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 universal 1 4 4
time (from 0-59)
getUTCSeconds() Returns the seconds of a Date object according to 1 4 4
universal time (from 0-59)
getUTCMilliseconds() Returns the milliseconds of a Date object according to 1 4 4
universal time (from 0-999)
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
universal time (from 1-31)
setUTCMonth() Sets the month in a Date object according to universal time 1 4 4
(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
universal time (from 0-999)
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 !!
48
5 - javaScript
Properties
FF: Firefox, N: Netscape, IE: Internet Explorer
F I
Property Description N
F E
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
prototype Allows you to add properties and methods to the object 1 2 4
Methods
Method Description F N I
F E
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
the new length .5
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
49
5 - javaScript
Properties
FF: Firefox, IE: Internet Explorer
F I
Property Description
F E
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 F I
F E
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
digits than specified .5
toString() Converts the Number object into a string 1 4
valueOf() Returns the value of the Number object 1 4
Properties
FF: Firefox, N: Netscape, IE: Internet Explorer
50
5 - javaScript
F I
Property Description N
F E
constructor Returns a reference to the Boolean function that created the 1 2 4
object
prototype Allows you to add properties and methods to the object 1 2 4
Methods
Method Description F N I
F E
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
Properties
FF: Firefox, N: Netscape, IE: Internet Explorer
F I
Property Description N
F E
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 F N I
F 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 and 1 2 3
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
51
5 - javaScript
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.12.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);
5.12.2 Methods
An object can also contain methods.
You can call a method with the following syntax:
objName.methodName()
52
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;
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;
53
5 - javaScript
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;
}
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").
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.
54
5 - javaScript
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.13.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:
55
5 - javaScript
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>
56
6 - Html DOM
6 - HTML DOM
6.1 what is the DOM?
The W3C Document Object Model (DOM) is a platform and language-neutral interface that allows
programs and scripts to dynamically access and update the content, structure, and style of a
document.
The W3C DOM provides a standard set of objects for HTML and XML documents, and a standard
interface for accessing and manipulating them.
The W3C DOM is separated into different parts (Core, XML, and HTML) and different levels (DOM
Level 1/2/3):
Core DOM - defines a standard set of objects for any structured document
XML DOM - defines a standard set of objects for XML documents
HTML DOM - defines a standard set of objects for HTML documents
A web browser is not obliged to use DOM in order to render an HTML document. However, the
DOM is required by JavaScript scripts that wish to inspect or modify a web page dynamically. In other
words, the Document Object Model is the way JavaScript sees its containing HTML page and browser
state.
Because the DOM supports navigation in any direction (e.g., parent and previous sibling) and allows
for arbitrary modifications, an implementation must at least buffer the document that has been read so
far (or some parsed form of it). Hence the DOM is likely to be best suited for applications where the
document must be accessed repeatedly or out of sequence order. If the application is strictly
sequential and one-pass, the SAX model is likely to be faster and use less memory. SAX (Simple API
for XML) is a sequential access parser API for XML. SAX provides a mechanism for reading data
from an XML document. It is a popular alternative to the Document Object Model (DOM).
6.2 history
The World Wide Web Consortium (W3C) developed the W3C Document Object Model in
response to the development of various proprietary models for HTML, particularly those used in Web
browsers. The existing vendor-specific interfaces were dubbed intermediate DOMs.
W3C began development of the DOM in the mid-1990s. Although the W3C never produced a
specification for DOM 0, it was nonetheless a partially documented model and was included in the
specification of HTML 4. By October 1998, the first specification of DOM (DOM 1) was released. DOM
2 was issued in November 2000, with specifics on the style sheet object model and style information
manipulation. DOM 3 was released in April 2004 and is the current release of the DOM specification.
As of January 2008, the Document Object Model activity is closed. The Document Object Model
Working Group was closed in the Spring of 2004, after the completion of the DOM Level 3
Recommendations. Several W3C Working Groups have since taken the lead in maintaining and
continuing to develop standard APIs for the Web since then; HTML, SVG, CSS, or WebAPI being
among them.
Right until now (oct. 2015), what drove the DOM Specifications was the WebApps WG. The W3C
Web Applications Working Group has taken over responsibility for the Document Object Model
specifications, including a new revision of DOM Level 3 Events, a new DOM Core specification, and
potentially any errata on older DOM specifications.
The main deadline for this work group's activity was May 2014. Among the deliverables expected
were the following:
57
6 - Html DOM
The Web Applications Working group has ceased its activity in October 2015. Its deliverables were
transferred to the Web Platform Working Group.
The W3C Web Platform Working Group is chartered to continue the development of the HTML
language, providing specifications that enable improved client-side application development on the
Web, including application programming interfaces (APIs) for client-side development and markup
vocabularies for describing and controlling client-side application behavior.
6.3 levels
The W3C DOM specifications are divided into levels, each of which contains required and optional
modules. To claim to support a level, an application must implement all the requirements of the
claimed level and the levels below it. An application may also support vendor-specific extensions
which don't conflict with the W3C standards. As of 2005, Level 1, Level 2, and some modules of Level
3 are W3C Recommendations which means they have reached their final form.
Level 0
The application supports an intermediate DOM, which existed before the creation of DOM Level 1.
Examples include the DHTML Object Model or the Netscape intermediate DOM. Level 0 is not a
formal specification published by the W3C but rather a shorthand that refers to what existed before the
standardization process.
Level 1
Navigation of DOM (HTML and XML) document (tree structure) and content manipulation (includes
adding elements). HTML-specific elements are included as well.
Level 2
XML namespace support, filtered views and events.
Level 3
Consists of 6 different specifications:
1. DOM Level 3 Core;
2. DOM Level 3 Load and Save;
3. DOM Level 3 XPath;
4. DOM Level 3 Views and Formatting;
5. DOM Level 3 Requirements; and
6. DOM Level 3 Validation, which further enhances the DOM
58
6 - Html DOM
6.4 specifications
Earlier, when each Web browser exclusively supported its own intermediate DOM, interoperability
problems were numerous. In order to be cross-browser compatible, that is, support multiple browsers,
large parts of Dynamic HTML code had to be rewritten for each browser to be supported. A common
DOM promised substantial simplification of the development of complex Web applications.
W3C DOM Level 1 has been a recommendation since 1 October 1998. The standardization effort
did not bring forth an immediate change, because non-conformant browsers such as Internet Explorer
4.x and Netscape 4.x were still widely used in 2000. By 2005, large parts of W3C DOM were well-
supported by common JavaScript-enabled Web browsers, including Microsoft Internet Explorer
(version 5 (1999) and version 6 (2001)), Gecko-based browsers (like Mozilla and Firefox), Opera,
Konqueror, and Safari. Web developers are starting to rely mostly or solely on W3C DOM, since it
allows browser compatibility with a large audience.
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 are presented in the next paragraph.
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
59
6 - Html DOM
The HTML DOM defines a standard set of objects for HTML, and a standard way to access and
manipulate HTML documents.
All HTML elements, along with their containing text and attributes, can be accessed through the
DOM. The contents can be modified or deleted, and new elements can be created.
The HTML DOM is platform and language independent. It can be used by any programming
language like Java, JavaScript, and VBScript.
Object Description
Document Represents the entire HTML document and can be used to access all
elements in a page
Anchor Represents an <a> element
Area Represents an <area> element inside an image-map
Base Represents a <base> element (specifies a default address or a default
target for all links on a page)
Body Represents the <body> element
Button Represents a <button> element
Event Represents the state of an event
Form Represents a <form> element
Frame Represents a <frame> element
Frameset Represents a <frameset> element
Iframe Represents an <iframe> element
Image Represents an <img> element
Input button Represents a button in an HTML form
Input checkbox Represents a checkbox in an HTML form
Input file Represents a fileupload in an HTML form
Input hidden Represents a hidden field in an HTML form
Input password Represents a password field in an HTML form
Input radio Represents a radio button in an HTML form
Input reset Represents a reset button in an HTML form
Input submit Represents a submit button in an HTML form
Input text Represents a text-input field in an HTML form
Link Represents a <link> element
Meta Represents a <meta> element
Option Represents an <option> element
Select Represents a selection list in an HTML form
Style Represents an individual style statement
Table Represents a <table> element
60
6 - Html DOM
The root node in the HTML above is <html>. All other nodes in the document are contained within
<html>.
The <html> node has two child nodes; <head> and <body>.
The <head> node holds a <title> node. The <body> node holds a <h1> and <p> node.
61
6 - Html DOM
The following example returns a nodeList of all <p> elements that are descendants of the element
with id="main":
document.getElementById('main').getElementsByTagName("p");
The length property defines the length of a node list (the number of nodes). You can loop through a
node list by using the length property:
x=document.getElementsByTagName("p");
62
6 - Html DOM
for (i=0;i<x.length;i++)
{
document.write(x[i].innerHTML);
document.write("<br />");
}
63
6 - Html DOM
Common/W3C events
There is a huge collection of events that can be generated by most element nodes:
Mouse events
Keyboard events
HTML frame/object events
HTML form events
User interface events
Mutation events (notification of any changes to the structure of a document)
Note that the event classification above is not exactly the same as W3C's classification.
64
6 - Html DOM
65
6 - Html DOM
Note that the events whose names start with DOM are currently not well supported. Mozilla and
Opera support DOMAttrModified, DOMNodeInserted, DOMNodeRemoved and
DOMCharacterDataModified. Safari, as of version 1.3, also supports these methods.
Also, Mozilla, Safari and Opera also support readystatechange event for the XMLHttpRequest
object. Mozilla also supports the beforeunload event using traditional event registration method (DOM
Level 0). Mozilla and Safari also support contextmenu, but Internet Explorer for the Mac does not.
Consider the situation when there are 2 elements nested together. Both have event handlers
registered on the same event type, say "click". When the user clicks on the inner element, there are
two possible ways to handle it:
Trigger the elements from outer to inner (event capturing). This model is implemented in
Netscape Navigator.
Trigger the elements from inner to outer (event bubbling). This model is implemented in
Internet Explorer and other browsers.
W3C takes a middle position in this struggle. Events are first captured until it reaches the target
element, and then bubbled up. During the event flow, an event can be responded to at any element in
the path (an observer) in either phase by causing an action, and/or by stopping the event (with method
event.stopPropagation() for Mozilla and command event.cancelBubble = true for
Internet Explorer), and/or by cancelling the default action for the event.
The Event object provides a lot of information about a particular event, including information about
target element, key pressed, mouse button pressed, mouse position, etc. Unfortunately, there are very
serious browser incompatibilities in this area. Hence only the W3C Event object is discussed here.
Event properties
66
6 - Html DOM
Event methods
Argument Argument
Name Description
type name
To prevent further propagation of an
stopPropagation
event during event flow.
To cancel the event if it is cancelable,
meaning that any default action normally
preventDefault
taken by the implementation as a result of
the event will not occur.
DOMString eventTypeArg Specifies the event type.
Specifies whether or not the event can
boolean canBubbleArg
initEvent bubble.
Specifies whether or not the event's
boolean cancelableArg
default action can be prevented.
67
7 - AJAX
7 - AJAX
7.1 what is ajax?
Ajax stands for Asynchronous JavaScript And XML. It is not a technology in itself, but rather a
collection of existing technologies bound together by JavaScript.
Mainly to build a fast, dynamic website, but also to save resources. For improving sharing of
resources, it is better to use the power of all the client computers rather than just an unique server and
network. Ajax allows to perform processing on the client computer (in JavaScript) with data taken from
the server.
The processing of web pages was formerly done only server-side, using web services or Php
scripts, before the whole page was sent within the network.
But Ajax can selectively modify a part of a page displayed by the browser and update it without the
need to reload the whole document with all images, menus, etc.
For example, fields of forms, choices of user, may be processed and the result displayed
immediately into the same page.
Lately, the Ajax functionality is provided in a more direct approach, using calls provided by
specialized JavaScript libraries, like jQuery or AngularJS.
The classic web application model works like this: most user actions in the interface trigger an
HTTP request back to a web server. The server does some processing retrieving data, crunching
numbers, talking to various legacy systems and then returns an HTML page to the client. Its a
model adapted from the Webs original use as a hypertext medium, but what makes the Web good for
68
7 - AJAX
This approach makes a lot of technical sense, but it doesnt make for a great user experience.
While the server is doing its thing, whats the user doing? Thats right, waiting. And at every step in a
task, the user waits some more.
Obviously, if we were designing the Web from scratch for applications, we wouldnt make users wait
around. Once an interface is loaded, why should the user interaction come to a halt every time the
application needs something from the server? In fact, why should the user see the application go to
the server at all?
An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by
introducing an intermediary an Ajax engine between the user and the server. It seems like
adding a layer to the application would make it less responsive, but the opposite is true.
Instead of loading a web page, at the start of the session, the browser loads an Ajax engine
written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both
rendering the interface the user sees and communicating with the server on the users behalf. The
Ajax engine allows the users interaction with the application to happen asynchronously
independent of communication with the server. So the user is never staring at a blank browser window
and an hourglass icon, waiting around for the server to do something.
69
7 - AJAX
The synchronous interaction pattern of a traditional web application (top) compared with the
asynchronous pattern of an Ajax application (bottom)
Every user action that normally would generate an HTTP request takes the form of a JavaScript call
to the Ajax engine instead. Any response to a user action that doesnt require a trip back to the server
such as simple data validation, editing data in memory, and even some navigation the engine
handles on its own. If the engine needs something from the server in order to respond if its
submitting data for processing, loading additional interface code, or retrieving new data the engine
makes those requests asynchronously, usually using XML, without stalling a users interaction with the
application.
70
7 - AJAX
Ajax uses a programming model with display and events. These events are user actions, they call
functions associated to elements of the web page.
Interactivity is achieved with forms and buttons. DOM allows to link elements of the page with
actions and also to extract data from Xml files provided by the server.
To get data on the server, the ajax engine uses the XMLHttpRequest object. This object provides
two methods:
- open: create a connection.
- send: send a request to the server.
Data provided by the server will be found in these attributes of the XMLHttpRequest object:
- responseXml - for a Xml file or
- responseText - for a simple text.
Take note that a new XMLHttpRequest object has to be created for each new file to load.
We have to wait for the data to be available to process it, and in this purpose, the state of availability
of data is given by the readyState attribute of XMLHttpRequest.
States of readyState follow (only the last one is really useful):
0: not initialized.
1: connection established.
2: request received.
3: answer in process.
4: finished.
Here is a closer look to the XMLHttpRequest class. It allows the interaction with the servers, thanks
to its methods and attributes.
Attributes
readyState - the code successively changes value from 0 to 4 that means "ready".
status - returned by the server - 200 is ok, 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 - the name of the function invoked
Methods
open(mode, url, boolean) - mode: type of request, GET or POST
- url: the location of the file
- boolean: true (asynchronous) / false (synchronous)
send("string") - null for a GET command
71
7 - AJAX
request.onreadystatechange = function()
{ // instructions to process the response };
if (request.readyState == 4)
{
// received, OK
}
else
{
// wait...
}
- open: command GET or POST, URL of the document, true for asynchronous.
- send: with POST only, the data to send to the server.
7.7 examples
7.7.1 How to get a text
<html>
<head>
<script>
function submitForm()
72
7 - AJAX
{
var req = null;
if(window.XMLHttpRequest) req = new XMLHttpRequest();
else if (window.ActiveXObject)
req = new ActiveXObject(Microsoft.XMLHTTP);
req.onreadystatechange = function()
{
if(req.readyState == 4)
if(req.status == 200)
document.ajax.dyn="Received:" + req.responseText;
else
document.ajax.dyn="Error code " + req.status;
};
<body>
<FORM method="POST" name="ajax" action="">
<INPUT type="BUTTON" value="Submit" ONCLICK="submitForm()">
<INPUT type="text" name="dyn" value="">
</FORM>
</body>
</html>
by this code:
73
7 - AJAX
req.setRequestHeader("Content-Type",
"application/x-www-form-urlencoded");
req.send(document.getElementById("dyn".value));
<div id="zone">
... some text to replace ...
</div>
document.getElementById("zone").innerHTML = "Received:" +
xhr.responseText;
It is an Eclipse add-on that provides tools for building IDE for Ajax runtimes, and testing Ajax
applications. The AJAX Toolkit Framework (ATF) provides and extensible framework and exemplary
tools for building IDEs for the many different AJAX runtime offerings (Dojo, Zimbra, Rico, etc) in the
market. Tools built upon these frameworks will initially include: enhanced JavaScript editing features
such as edit-time syntax checking; an embedded Mozilla web browser; an embedded DOM browser;
and an embedded JavaScript debugger.
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.10 Specifications
74
8 - WEB APPLICATIONS
8 - WEB APPLICATIONS
8.1 web application types
A web application is a dynamic extension of a web or application server. Web applications are of
the following types:
Presentation-oriented: A presentation-oriented web application generates interactive web
pages containing various types of markup language (HTML, XHTML, XML, and so on) and
dynamic content in response to requests.
Service-oriented: A service-oriented web application implements the endpoint of a web
service. Presentation-oriented applications are often clients of service-oriented web
applications.
In the Java EE platform, web components provide the dynamic extension capabilities for a web
server. Web components can be Java servlets, web pages implemented with JavaServer Faces
technology, web service endpoints, or JSP pages.
Servlets are Java programming language classes that dynamically process requests and construct
responses. Java technologies, such as JavaServer Faces and Facelets, are used for building
interactive web applications. (Frameworks can also be used for this purpose.) Although servlets and
JavaServer Faces and Facelets pages can be used to accomplish similar things, each has its own
strengths. Servlets are best suited for service-oriented applications (web service endpoints can be
implemented as servlets) and the control functions of a presentation-oriented application, such as
dispatching requests and handling nontextual data. JavaServer Faces and Facelets pages are more
appropriate for generating text-based markup, such as XHTML, and are generally used for
presentation-oriented applications.
Web components are supported by the services of a runtime platform called a web container. A
web container provides such services as request dispatching, security, concurrency, and lifecycle
management. A web container also gives web components access to such APIs as naming,
transactions, and email.
Certain aspects of web application behavior can be configured when the application is installed, or
deployed, to the web container. The configuration information can be specified using Java EE
annotations or can be maintained in a text file in XML format called a web application deployment
descriptor (DD). A web application DD must conform to the schema described in the Java Servlet
specification.
A web application consists of web components; static resource files, such as images and cascading
style sheets (CSS); and helper classes and libraries. The web container provides many supporting
services that enhance the capabilities of web components and make them easier to develop.
However, because a web application must take these services into account, the process for creating
and running a web application is different from that of traditional stand-alone Java classes.
The process for creating, deploying, and executing a web application can be summarized as follows:
1. Develop the web component code.
2. Develop the web application deployment descriptor, if necessary.
3. Compile the web application components and helper classes referenced by the components.
4. Optionally, package the application into a deployable unit.
5. Deploy the application into a web container.
6. Access a URL that references the web application.
75
8 - WEB APPLICATIONS
A web application is a collection of Java servlets, JSP pages, Java Server Faces, 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.
Besides these mandatory parts, a web application may contain other, generic or application server
specific files. Typically, the WEB-INF directory may contain a generic application.xml file or a vendor
specific xml file. For example, on a Weblogic application server, the WEB-INF directory contains an
extra deployment descriptor, called weblogic.xml.
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
Starting with Java EE 5, the content of the deployment descriptor may be replaced by annotations
within the java source files of the application.
Annotations are a form of syntactic metadata (smart comments) that can be added to Java source
code. Classes, methods, variables, parameters and packages may be annotated. Unlike Javadoc
tags, Java annotations can be reflective in that they can be embedded in class files generated by the
compiler and may be retained by the Java VM to be made retrievable at run-time.
A web container is a Java runtime providing implementation of the Java servlet API and some
other facilities to the JSP and JSF pages. It responsible for initializing, invoking and managing the life
cycle of servlets, JSPs and JSFs.
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.
76
8 - WEB APPLICATIONS
the web server. Typical integration scenarios are Tomcat with Apache and JRun (of Allaire)
with most of the J2EE application servers.
JavaServer
Faces
JavaServer
Faces
77
8 - WEB APPLICATIONS
Containers are the interface between a component and the low-level platform-specific functionality
that supports the component. Before a web, enterprise bean, or application client component can be
executed, it must be assembled into a Java EE module and deployed into its container.
The assembly process involves specifying container settings for each component in the Java EE
application and for the Java EE application itself. Container settings customize the underlying support
provided by the Java EE server, including services such as security, transaction management, Java
Naming and Directory Interface (JNDI) lookups, and remote connectivity. Here are some of the
highlights:
The Java EE security model lets you configure a web component or enterprise bean so that
system resources are accessed only by authorized users.
The Java EE transaction model lets you specify relationships among methods that make up
a single transaction so that all methods in one transaction are treated as a single unit.
JNDI lookup services provide a unified interface to multiple naming and directory services in
the enterprise so that application components can access these services.
The Java EE remote connectivity model manages low-level communications between
clients and enterprise beans. After an enterprise bean is created, a client invokes methods on
it as if it were in the same virtual machine.
Because the Java EE architecture provides configurable services, application components within the
same Java EE application can behave differently based on where they are deployed. For example, an
enterprise bean can have security settings that allow it a certain level of access to database data in
one production environment and another level of database access in another production environment.
78
8 - WEB APPLICATIONS
The container also manages nonconfigurable services such as enterprise bean and servlet life
cycles, database connection resource pooling, data persistence, and access to the Java EE platform
APIs.
The deployment descriptor is an xml file (named, in general, web.xml) which allows the
customization of the web application at deployment time. Extra deployment information can be
contained in separate xml file(s) (like application.xml) or included as annotation(s) in the java source
files.
The deployment descriptor serves several purposes, like:
1. Initialization of parameters for servlets, JSPs and Java Server Faces.
2. Servlet, JSPs and Java Server Faces definitions, servlet classes, precompiled JSP entities are
declared (names, classes, descriptions).
3. Servlet, JSPs and Java Server 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.
6. Others, like what pages are error, welcome pages, entries related to session configuration.
Here is a small, but typical web.xml file:
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:
79
8 - WEB APPLICATIONS
<servlet-mapping>
<servlet-name>invoker</servlet-name>
<url-pattern>/servlet/*</url-pattern>
</servlet-mapping>
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:
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>
80
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. Theoretically, servlets can communicate over any client-server protocol, but most
often, they communicate over the HTTP protocol.
The Java Servlet API provides a simple frame for building web applications on web servers.
The first Servlet specification (version 1.0) was finalized by Sun June 1997. It continued with
versions 2.0, 2.1 and 2.2 in the next couple of years. Starting with version 2.3, the Servlet specification
is part of the Java Community process. The current (as of Oct. 2015) Java Servlet specification is 3.1
(JSR 340) and dates back to May 2013. It is part of the Java EE 7 SDKs.
The 3.1 spec is supported in Tomcat 8.0, Glassfish 4.0 and Netbeans 7.3.1.
The servlet does not communicate directly with the client, but through a web container. The servlet
lives within this container which provides an execution environment for the servlet class. Web
containers are implemented by various vendors, in most cases as part of an application server.
The Java servlet API consists of 2 packages, which are part of the Java Platform 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 and 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
The Servlet interface is part of the javax.servlet package. It declares the following methods:
81
9 - SERVLETS
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 life cycle, in a different section.
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:
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.
The HttpServlet provides an HTTP specific implementation of the Servlet interface. This abstract
class specifies the following methods:
82
9 - SERVLETS
javax.servlet.ServletException
javax.servlet.UnavailableException
83
9 - SERVLETS
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.
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/JSFs.
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, JSP or JSF, or to
allow sending data from a servlet to another.
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:
84
9 - SERVLETS
This interface extends the ServletResponse interface and defines methods specific for
constructing responses to HTTP requests.
Here are the most important ones:
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.
85
9 - SERVLETS
There is only one ServletContext for the entire web application and all the components of the web
application can share it. The ServletContext is created by the container where the web application is
deployed.
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.
This file is the entry point for the web application. It can be accessed by specifying in the address
field of the browser the address of the (Tomcat, in our case) server, the port number (if not the default
value of 80) and the web application id (as specified in the context element of the sever.xml file). The
OAM.html file is displayed, because this is the welcome-file specified in the deployment descriptor
web.xml.
86
9 - SERVLETS
Once the data is introduced, the client presses the submit button, a validation script is executed, and
in case data is validated, it is transmitted for processing to the servlet OAMServlet (as specified in the
ACTION attribute of the <form> element of the OAM.html file).
The OAM servlet services the request sent by the web browser when we submit the OAM form (the
file OAM.html)
package com.bank11.ccards.servlets;
import java.io.IOException;
import java.io.PrintWriter;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
87
9 - SERVLETS
/**
* Processes requests for both HTTP GET and POST methods.
* @param request servlet request
* @param response servlet response
* @throws ServletException if a servlet-specific error occurs
* @throws IOException if an I/O error occurs
*/
Connection myConn=null;
boolean isThere;
@Override
public void init(ServletConfig config) throws ServletException{
super.init(config);
String driverName = getInitParameter("jdbcDriver");
String connURL = getInitParameter("dbServer");
try {
Class.forName(driverName).newInstance();
myConn = DriverManager.getConnection
(connURL,"tw2011","tw2011");
}catch(Exception e){
e.printStackTrace();
}
}
if(myConn == null){
outMess="Nu exista conexiune ";
}else{
String fName=request.getParameter("fname");
String lName=request.getParameter("lname");
String cnp=request.getParameter("cnp");
String street=request.getParameter("street");
String city=request.getParameter("city");
String county=request.getParameter("county");
String code=request.getParameter("code");
String phoneNumber=request.getParameter("phoneNo");
String email=request.getParameter("email");
String mName=request.getParameter("mname");
String pryAccount=request.getParameter("primaryacc");
try{
88
9 - SERVLETS
try {
//TODO output your page here
out.println("<html>");
out.println("<head>");
out.println("<title>Servlet OAM</title>");
out.println("</head>");
out.println("<body>");
out.println("<h1>Servlet OAM at " + request.getContextPath ()
+ "</h1>");
if(isThere==false){
out.println(outMess);
}else{
out.println(outMess+="<br />The CNP already exists in the
database");
}
out.println("</body>");
out.println("</html>");
}catch(Exception e){e.printStackTrace();
}finally {
89
9 - SERVLETS
out.close();
}
}
In the init() part, the jdbc driver is loaded and the connection with the database server is is
established.
In the processing part, the parameters of the request (coming from the input fields of the OAM.html
form) are retrieved and used to generate a database query.
This query is then executed and an INSERT is performed in case an user with the same CNP does
not exist in the CUSTOMERS table of the database.
Finally, the servlet generates a response to the client in the form of an html file containing the status
of the request.
90
9 - SERVLETS
91
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.
The first release of the JDBC specification dates back to Feb. 1997, as part of the Java
Development Kit (JDK) 1.1. After that, JDBC was part of Java Standard Edition (JSE). Starting with
version 3.0, JDBC evolution is part of the Java Community Process. JSR 54 defines JDBC 3.0 while
the current (4.0) JDBC specification is defined in JSR 221. Version 4.1 is specified by a maintenance
release of JSR 221 and is included in Java SE 7. The latest version (as of Oct 2015) is 4.2, a second
maintenance release of JSR 221 and is included in Java SE 8.
The JDBC 4.2 API consists of 2 packages:
1. the java.sql package
2. the javax.sql package, which provides several server-side capabilities
The JDBC API provides programmatic access from applications written in the Java programming
language to standard SQL. The JDBC API presents a standard API to access a wide range of
underlying data sources or legacy systems.
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
recognized by the DB industry. A new category of highly functional drivers with superior performance
may be considered, as well.
92
10 - JDBC
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.
93
10 - JDBC
This package contains the core JDBC API. An exhaustive list of the classes and interfaces of this
package can be found in the latest JDBC specification (4.0). The document containing this
specification is JSR 221 and can be viewed at http://jcp.org/en/jsr/detail?id=221.
Of the 80+ classes and interfaces defined in this specification, let's remind some of the most
important ones, defined in the JDBC 3.0 API.
java.sql.Array
java.sql.Blob
java.sql.CallableStatement
java.sql.Clob
java.sql.Connection
java.sql.Date
java.sql.Driver
java.sql.DriverManager
java.sql.ResultSet
java.sql.ResultSetMetaData
java.sql.SQLData
java.sql.SQLDataException
java.sql.SQLException
java.sql.SQLInput
java.sql.SQLOutput
java.sql.SQLPermission
java.sql.SQLXML
java.sql.SQLWarning
java.sql.Statement
java.sql.Struct
java.sql.Time
java.sql.Timestamp
java.sql.Types
94
10 - JDBC
The following list contains all of the classes and interfaces new or updated in version 4.0.
java.sql.CallableStatement
java.sql.Clob
java.sql.ClientinfoStatus
java.sql.Connection
java.sql.DatabaseMetaData
java.sql.NClob
java.sql.PreparedStatement
java.sql.ResultSet
java.sql.RowId
java.sql.RowIdLifeTime
java.sql.SQLClientInfoException
java.sql.SQLDataException
java.sql.SQLException
java.sql.SQLFeatureNotSupportedException
java.sql.SQLInput
java.sql.SQLIntegrityConstraintViolationException
java.sql.SQLInvalidAuthorizationSpecException
java.sql.SQLNonTransientConnectionException
java.sql.SQLNonTransientException
java.sql.SQLOutput
java.sql.SQLSyntaxErrorException
java.sql.SQLTimeoutException
java.sql.SQLTransactionRollbackException
java.sql.SQLTransientConnectionException
java.sql.SQLTransientException
java.sql.SQLXML
java.sql.SQLWarning
java.sql.Statement
java.sql.Types
java.sql.Wrapper
javax.sql.CommonDataSource
javax.sql.StatementEvent
javax.sql.StatementEventListener
The figure below shows the interactions and relationships between the major classes and interfaces
of the java.sql package.
The main steps in communicating with a database are:
1. loading a database driver
2. establishing a database connection
95
10 - JDBC
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.ibm.db2.jdbc.app.DB2Driver
oracle.jdbc.driver.OracleDriver
com.borland.datastore.jdbc.DataStoreDriver
com.sybase.jdbc.SybDriver
96
10 - JDBC
sun.jdbc.odbc.JdbcOdbcDriver
weblogic.jdbc.mssqlserver4.Driver
org.postgresql.Driver
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();
}
(Each object in java has (belongs to) a class, and has a respective Class object, which contains
metadata about it, that is accessible at runtime.)
The actual location of the database is specified by its URL (also known as connection URL). The
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
jdbc:sybase:localhost:2025?ServiceName=<databaseName>
jdbc:derby:net://<host>:1527/<databaseName>
jdbc:db2://db2.bank11.com:50002/ccards
jdbc:oracle:thin:@loclahost:1521:ORCL
jdbc:postgresql://<host>:5432/<databaseName>
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:
Since we just used it, let's have a better look in the next section at the DriverManager class.
97
10 - JDBC
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:
While the first two forms of getConnection() are pretty straightforward, let's see an example of how
to use the last of the three forms.
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. The most important methods for creating statements:
98
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:
99
10 - JDBC
to the user and allows access to the data retrieved. The interface ResultSet is implemented by
driver vendors.
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 retrieval 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
invocation 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()
100
10 - JDBC
isCaseSensitive()
isSigned()
isAutoIncrement()
isReadOnly()
isDefinitelyWritable()
By default, all created ResultSets have a type of forward only, a concurrency of read only, and
cursors are held over commit boundaries. An exception to this is that WebSphere currently changes
the cursor holdability default so that cursors are implicitly closed when committed. These
characteristics are configurable through methods that are accessible on Statement,
PreparedStatement and CallableStatement objects.
A cursor comprises a control structure for the successive traversal (and potential processing) of
records in a result set. One can think of a database cursor as an iterator over the collection of rows in
the result set.
10.10.2 Concurrency
Concurrency determines whether the ResultSet can be updated. The types are again defined by
constants in the ResultSet interface. The available concurrency settings are as follows:
CONCUR_READ_ONLY
A ResultSet that can only be used for reading data out of the database. This is the default setting.
CONCUR_UPDATEABLE
A ResultSet that allows you to make changes to it. These changes can be placed into the underlying
database.
JDBC 1.0 ResultSets are always forward only. Updateable ResultSets were added in JDBC 2.0.
101
10 - JDBC
Note: According to the JDBC specification, the JDBC driver is allowed to change the ResultSet type
of the ResultSet concurrency setting if the values cannot be used together. In such cases, the JDBC
driver places a warning on the Connection object.
There is one situation where the application specifies a TYPE_SCROLL_INSENSITIVE,
CONCUR_UPDATEABLE ResultSet. Insensitivity is implemented in the database engine by making a
copy of the data. You are then not allowed to make updates through that copy to the underlying
database. If you specify this combination, the driver changes the sensitivity to
TYPE_SCROLL_SENSITIVE and create the warning indicating that your request has been changed.
10.10.3 Holdability
The holdability characteristic determines whether calling commit on the Connection object closes
the ResultSet. The JDBC API for working with the holdability characteristic is new in version 3.0.
However, the native JDBC driver has provided a connection property for several releases that allows
you to specify that default for all ResultSets created under the connection. The API support overrides
any setting for the connection property. Values for the holdability characteristic are defined by
ResultSet constants and are as follows:
HOLD_CURSOR_OVER_COMMIT
All open cursors remain open when the commit clause is called. This is the native JDBC default
value.
CLOSE_CURSORS_ON_COMMIT
All open cursors are closed when commit clause is called.
// DisplayServlet.java
package com.bank11.ccards.servlets;
import java.sql.*;
import javax.servlet.*;
import javax.servlet.http.*;
import java.util.*;
String connURL="jdbc:mysql://localhost:3306/ccards";
102
10 - JDBC
try {
conn=DriverManager.getConnection(connURL,"root","root");
} catch (SQLException sqle) {
sqle.printStackTrace();
}
}
while(rs.next()) {
String firstName = rs.getString(FIRST_NAME);
String lastName = rs.getString(LAST_NAME);
BigDecimal accountNum = rs.getBigDecimal(ACCOUNT_NUM);
}
} catch (SQLException sqle) {
sqle.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
}
resp.setContentType("text/html");
java.io.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("</body>");
out.println("</html>");
out.close();
}
103
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
104
10 - JDBC
import java.sql.*;
uprs.moveToInsertRow();
uprs.updateString("COF_NAME", "Kona");
uprs.updateInt("SUP_ID", 150);
uprs.updateFloat("PRICE", 10.99f);
uprs.updateInt("SALES", 0);
uprs.updateInt("TOTAL", 0);
uprs.insertRow();
uprs.updateString("COF_NAME", "Kona_Decaf");
105
10 - JDBC
uprs.updateInt("SUP_ID", 150);
uprs.updateFloat("PRICE", 11.99f);
uprs.updateInt("SALES", 0);
uprs.updateInt("TOTAL", 0);
uprs.insertRow();
uprs.beforeFirst();
10.15 jdbc and sql types and their corresponding java classes
106
10 - JDBC
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 a factory for creating DB connections. It is part of the javax.sql package.
The DataSource interface is implemented by a driver vendors. There are three types of
implementations:
1. Basic implementation -- produces a standard Connection object
2. Connection pooling implementation -- produces a Connection object that will automatically
participate in connection pooling. This implementation works with a middle-tier connection
pooling manager.
3. Distributed transaction implementation -- produces a Connection object that may be used
for distributed transactions and almost always participates in connection pooling. This
implementation works with a middle-tier transaction manager and almost always with a
connection pooling manager.
Main methods:
107
10 - JDBC
package com.bank11.ccards.servlets;
import java.io.*;
import java.sql.*;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.naming.*;
import javax.sql.*;
108
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.2 and is related to the 2.5 Java Servlet specification. JSR
245 is the official document containing the current specification of JSP as a maintenance release..
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.
The implementation of this method is generated by the web container never by the developer.
Even if we start with a very benign java server page, like the listed hello world example below, the
generated servlet is still pretty complex.
First, the original index.jsp file.
<%--
Document : index
Created on : 08.11.2010, 08:17:39
109
11 - JSP
Author : sm
--%>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-
8">
<title>JSP Page</title>
</head>
<body>
<h1>Hello World!</h1>
</body>
</html>
package org.apache.jsp;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
110
11 - JSP
try {
response.setContentType("text/html;charset=UTF-8");
response.setHeader("X-Powered-By", "JSP/2.1");
pageContext = _jspxFactory.getPageContext(this, request, response,
null, true, 8192, true);
_jspx_page_context = pageContext;
application = pageContext.getServletContext();
config = pageContext.getServletConfig();
session = pageContext.getSession();
out = pageContext.getOut();
_jspx_out = out;
_jspx_resourceInjector = (org.glassfish.jsp.api.ResourceInjector)
application.getAttribute("com.sun.appserv.jsp.resource.injector");
out.write("\n");
out.write("\n");
out.write("\n");
out.write("<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01
Transitional//EN\"\n");
out.write(" \"http://www.w3.org/TR/html4/loose.dtd\">\n");
out.write("\n");
out.write("<html>\n");
out.write(" <head>\n");
out.write(" <meta http-equiv=\"Content-Type\"
content=\"text/html; charset=UTF-8\">\n");
out.write(" <title>JSP Page</title>\n");
out.write(" </head>\n");
out.write(" <body>\n");
out.write(" <h1>Hello World!</h1>\n");
out.write(" </body>\n");
out.write("</html>\n");
} catch (Throwable t) {
if (!(t instanceof SkipPageException)){
out = _jspx_out;
if (out != null && out.getBufferSize() != 0)
out.clearBuffer();
if (_jspx_page_context != null)
_jspx_page_context.handlePageException(t);
else throw new ServletException(t);
}
} finally {
_jspxFactory.releasePageContext(_jspx_page_context);
}
111
11 - JSP
}
}
A few words about serialization. To serialize an object means to convert its state to a byte stream so that
the byte stream can be reverted back into a copy of the object. A Java object is serializable if its class or any of
its superclasses implements either the java.io.Serializable interface or its
subinterface,java.io.Externalizable. Deserialization is the process of converting the serialized form of
an object back into a copy of the object.
/*
* NewBean.java
*/
import java.beans.*;
import java.io.Serializable;
public NewBean() {
propertySupport = new PropertyChangeSupport(this);
}
112
11 - JSP
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. For more information, check
http://beginnersbook.com/2013/05/jsp-tutorial-directives/
113
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" %>
11.7.1 declarations
Basicly, a bloc of java code used to define class-wide variables and methods in the generated
servlet.
11.7.2 scriptlets
Block of java code which is executed during request processing. In Tomcat, this code goes to inside
the service() method.
11.7.3 expressions
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.
114
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.
<jsp:useBean>
Used to instantiate a Java bean or locate a bean instance. Assigns it to available name or id.
To clarify the distinction between class and beaName, read the remarks below.
class="package.class" type="package.class"
Instantiates a bean from the class named in class and assigns the bean the data type you specify
in type. The value of type can be the same as class, a superclass of class, or an interface
implemented by class.
The class you specify in class must not be abstract and must have a public, no-argument
constructor. The package and class names you use with both class and type are case sensitive.
beanName="{package.class | <%= expression %>}" type="package.class"
Instantiates a bean from a class, a serialized template, or an expression that evaluates to a class
or serialized template. When you use beanName, the bean is instantiated by the
java.beans.Beans.instantiate method. The Beans.instantiate method checks
whether the package and class you specify represents a class or a serialized template. If they
represent a serialized template, Beans.instantiate reads the serialized form (which has a
name like package.class.ser) using a class loader.
The value of type can be the same as beanName, a superclass of beanName, or an interface
implemented by beanName. The package and class names you use with both beanName and
type are case sensitive.
115
11 - JSP
<jsp:setProperty>
Used in conjunction with the <jsp:useBean> action to set the value of the bean properties.
Attributes description:
name - the name of a bean instance, already defined in a <jsp:useBean>
property specifies the relationship between request parameters and corresponding bean
properties
property="*" - stores all of the values in the request object parameters (called request
parameters) in matching Bean properties. The property names in the Bean must match the
request parameters
property="propertyName" [ param="parameterName" ] - Sets one Bean property to the
value of one request parameter. The request parameter can have a different name than the
Bean property, and if so, you must specify param.
property="propertyName" value="{ string | <%= expression %> }" - Sets one Bean
property to a specific value. The value can be a String or an Expression
<jsp:getProperty>
Used to access the properties of a bean, converts them to string and displays the output to the
client.
Attributes description:
name - the name of a bean instance whose property is to be retrieved
property - name of the property to be retrieved
<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.
116
11 - JSP
<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.
Attributes description:
page - the URL of the page, same format as the <%@include> directive.
flush - only the "true" value is supported.
<jsp:forward>
Used to forward the the request to another JSP, servlet or to a static resource..
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.
<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.
117
11 - JSP
</jsp:plugin>
Attributes description:
name - the name of a bean instance, already defined in a <jsp:useBean>
type="bean|applet" - the type of object the plugin will execute. You must specify either bean
or applet, as this attribute has no default value.
code="classFileName" - the name of the Java class file that the plugin will execute. You
must include the .class extension in the name following code. The filename is relative to the
directory named in the codebase attribute.
codebase="classFileDirectoryName" - the absolute or relative path to the directory that
contains the applet's code. If you do not supply a value, the path of the JSP file that calls
<jsp:plugin> is used.
name="instanceName" - a name for the Bean or applet instance, which makes it possible for
applets or Beans called by the same JSP file to communicate with each other.
archive="URIToArchive, ..." - a comma-separated list of paths that locate archive files to be
preloaded with a class loader located in the directory named in codebase.
align="bottom|top|middle|left|right" - the positioning of the image displayed by the
applet or Bean relative to the line in the JSP result page that corresponds to the line in the
JSP file containing the <jsp:plugin> tag.
height="displayPixels" width="displayPixels" - the initial height and width, in pixels, of the
image the applet or Bean displays, not counting any windows or dialog boxes the applet or
Bean brings up.
hspace="leftRightPixels" vspace="topBottomPixels" - the amount of space, in pixels, to
the left and right (or top and bottom) of the image the applet or Bean displays. Must be a small
nonzero number.
jreversion="JREVersionNumber|1.1" - the version of the Java Runtime Environment (JRE)
the applet or Bean requires. The default value is 1.1.
nspluginurl="URLToPlugin" - the URL where the user can download the JRE plugin for
Netscape Navigator. The value is a full URL, with a protocol name, optional port number, and
domain name.
iepluginurl="URLToPlugin"
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 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
118
11 - JSP
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.10 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
<% enrollBean.init();
if (enrollBean.invalidAcct())
{ %>
<jsp:forward page="retry.jsp">
<jsp:param name="resolution" value="invalidAcct"/>
</jsp:forward>
<% }
else if (enrollBean.registeredAcct())
{ %>
<jsp:forward page="response.jsp">
<jsp:param name="resolution" value="registeredAcct"/>
</jsp:forward>
119
11 - JSP
<% }
else if (enrollBean.userExists())
{ %>
<jsp:forward page="retry.jsp">
<jsp:param name="resolution" value="userExists"/>
</jsp:forward>
<% }
else
{
enrollBean.register(); %>
<jsp:forward page="response.jsp">
<jsp:param name="resolution" value="userEnrolled"/>
</jsp:forward>
<% }
%>
// Simple bean
// No-arg constructor
public SimpleBean() {
}
120
11 - JSP
return this.string;
}
121
11 - JSP
122
11 - JSP
// Simple sub-bean
public class SimpleSubBean implements java.io.Serializable {
private String string;
private float number;
// No-arg constructor
public SimpleSubBean() {
}
123
11 - JSP
SimpleForm.html:
<HTML>
<HEAD><TITLE>Simple form</TITLE></HEAD>
<BODY>
<H3>Simple Example</H3>
<FORM METHOD="POST">
<P> String <BR>
<INPUT TYPE="TEXT" NAME="string" SIZE="20">
124
11 - JSP
<P>
<INPUT TYPE="SUBMIT" VALUE="Submit">
<INPUT TYPE="RESET" VALUE="Reset">
</FORM>
</BODY>
</HTML>
125
11 - JSP
new String[] {
"optional"
}
},
{
"[PROCESSING_ORDER]",
new String[] {
"string",
"number",
"integer",
"flag",
"colors",
"list",
"optional",
"subBean"
}
},
{ "[FORM_NAME]", "SimpleForm.html" },
{ "[PROC_NAME]", "SimpleProc.jsp" }
};
126
11 - JSP
127
11 - JSP
%>
<%!
public static String toString(String list[]) {
if (list == null || list.length == 0)
return "";
if (list.length == 1 && list[0] != null)
return list[0];
StringBuffer strbuf = new StringBuffer();
strbuf.append("{ ");
for (int i = 0; i < list.length; i++)
if (list[i] != null) {
strbuf.append(list[i]);
strbuf.append(" ");
}
strbuf.append("}");
return strbuf.toString();
}
128
11 - JSP
if (list.length == 1)
return Integer.toString(list[0]);
StringBuffer strbuf = new StringBuffer();
strbuf.append("{ ");
for (int i = 0; i < list.length; i++) {
strbuf.append(list[i]);
strbuf.append(" ");
}
strbuf.append("}");
return strbuf.toString();
}
%>
129
11 - JSP
130
11 - JSP
<%
int list[] = simpleBean.getList();
if (list == null)
list = new int[0];
String listItems[] = { "Item 1", "Item 2", "Item 3" };
for (int i = 0; i < listItems.length; i++) {
int value = i+1;
boolean selected = false;
if (list != null)
for (int j = 0; j < list.length; j++)
if (list[j] == value) {
selected = true;
break;
}
%>
<OPTION VALUE = "<%= value %>"
<%= selected ? "SELECTED" : "" %>> <%= listItems[i] %>
<%
}
%>
</SELECT>
<P>
<INPUT TYPE="SUBMIT" VALUE="Submit">
<INPUT TYPE="RESET" VALUE="Reset">
</FORM>
</BODY>
131
11 - JSP
</HTML>
<%!
String getErrorMessage(java.util.Hashtable errorTable, String property) {
String message = (String) errorTable.get(property);
if (message == null)
message = "";
return message;
}
%>
ComplexHndl.jsp:
<%@ page language="java" %>
<jsp:useBean id="simpleBean" scope="request"
class="com.devsphere.examples.mapping.simple.SimpleBean"/>
<jsp:useBean id="simpleSubBean" scope="page"
class="com.devsphere.examples.mapping.simple.SimpleSubBean"/>
<jsp:useBean id="errorTable" scope="request"
class="java.util.Hashtable"/>
<%
simpleBean.setSubBean(simpleSubBean);
%>
<jsp:setProperty name="simpleBean" property="string"/>
<%
if (simpleBean.getString() == null
|| simpleBean.getString().length() == 0) {
simpleBean.setString("abc");
setErrorMessage(errorTable, "string", "Must be filled");
}
try {
String numberValue = request.getParameter("number");
if (numberValue != null && numberValue.length() != 0)
simpleBean.setNumber(new Float(numberValue).floatValue());
else {
simpleBean.setNumber(0.123f);
setErrorMessage(errorTable, "number", "Must be filled");
}
132
11 - JSP
} catch (NumberFormatException e) {
simpleBean.setNumber(0.123f);
setErrorMessage(errorTable, "number", "Must be a number");
}
%>
<jsp:setProperty name="simpleBean" property="integer"/>
<%
if (simpleBean.getInteger() == 0) {
setErrorMessage(errorTable, "integer", "An option must be selected");
}
%>
<jsp:setProperty name="simpleBean" property="colors"/>
<%
if (simpleBean.getColors() == null
|| simpleBean.getColors().length == 0) {
setErrorMessage(errorTable, "colors",
"One or more colors must be selected");
}
%>
<jsp:setProperty name="simpleBean" property="list"/>
<%
if (simpleBean.getList() == null
|| simpleBean.getList().length == 0) {
simpleBean.setList(new int[] { 2, 3 });
setErrorMessage(errorTable, "list",
"One or more items must be selected");
}
133
11 - JSP
%>
<jsp:setProperty name="simpleBean" property="optional"/>
<%
if (simpleBean.getOptional() == null)
simpleBean.setOptional("");
%>
<jsp:setProperty name="simpleSubBean" property="string"
param="subBean.string"/>
<%
if (simpleSubBean.getString() == null
|| simpleSubBean.getString().length() == 0) {
simpleSubBean.setString("");
setErrorMessage(errorTable, "subBean.string", "Must be filled");
}
try {
String numberValue = request.getParameter("subBean.number");
if (numberValue != null && numberValue.length() != 0)
simpleSubBean.setNumber(new Float(numberValue).floatValue());
else {
setErrorMessage(errorTable, "subBean.number", "Must be filled");
}
} catch (NumberFormatException e) {
setErrorMessage(errorTable, "subBean.number", "Must be a number");
}
} else {
simpleBean.setString("abc");
simpleBean.setNumber(0.123f);
simpleBean.setFlag(true);
simpleBean.setList(new int[] { 2, 3 });
simpleBean.setOptional("");
simpleSubBean.setString("");
}
134
11 - JSP
} else {
%>
<jsp:forward page="ComplexForm.jsp"/>
<%
}
%>
<%!
void setErrorMessage(java.util.Hashtable errorTable,
String property, String message) {
message = "<FONT COLOR=\"#FF0000\">" + message + "</FONT><BR>";
errorTable.put(property, message);
}
%>
SimpleHndl.code=com.devsphere.helpers.mapping.BeanDispatcher
SimpleHndl.initparams=\
BEAN_NAME=com.devsphere.examples.mapping.simple.SimpleBean,\
BEAN_ID=simpleBean,\
BASE_PATH=/simple
or
<servlet>
<servlet-name>SimpleHndl</servlet-name>
<servlet-class>com.devsphere.helpers.mapping.BeanDispatcher</servlet-class>
<init-param>
<param-name>BEAN_NAME</param-name>
<param-value>com.devsphere.examples.mapping.simple.SimpleBean</param-value>
</init-param>
<init-param>
<param-name>BEAN_ID</param-name>
<param-value>simpleBean</param-value>
</init-param>
<init-param>
<param-name>BASE_PATH</param-name>
<param-value>/simple</param-value>
</init-param>
</servlet>
GenericHandler and BeanDispatcher were presented in a previous chapter.
135
11 - JSP
The servlet engine associates a servlet to a class in the servlets.properties (or web.xml) file:
ServletName.code=com.company.ClassName
There is nothing that can stop you associating many servlets with the same class. You may use the
same class to declare one servlet for each bean component. A standard servlet engine running on a
single JVM will instantiate the servlet class once for each servlet declaration. All requests to one of the
declared servlets will be serviced by the same instance of the servlet class.
The previous section showed how to declare a BeanDispatcher servlet. If you have another bean-
form pair, you could add a few other lines to servlets.properties:
AnotherHndl.code=com.devsphere.helpers.mapping.BeanDispatcher
AnotherHndl.initparams=\
BEAN_NAME=com.devsphere.examples.mapping.another.AnotherBean,\
BEAN_ID=anotherBean,\
BASE_PATH=/another
The two servlets that share the same code could be invoked with something like this
http://www.host.com/AppName/servlet/SimpleHndl
http://www.host.com/AppName/servlet/AnotherHndl
136
12 - javaserver faces
12 - JAVASERVER FACES
12.1 what are javaServer faces?
JavaServer Faces technology is a server-side user interface component framework for Java based
web applications. This technology includes:
2. A JavaServer Pages (JSP) custom tag library for expressing a JavaServer Faces interface
within a JSP page.
JSF is a request-driven MVC web framework based on component driven UI design model, using
XML files called view templates or Facelets views. Requests are processed by the FacesServlet,
which loads the appropriate view template, builds a component tree, processes events, and renders
the response (typically HTML) to the client.
The latest official version (as of november 2015) of JavaServer Faces technology is Mojarra version
2.2.12, released through the Java Community Process under Java Specification Requests (JSR) 314
and 344.
Version 2.3 is under development and reached Milestone 3 in July 2015.
Version 2.0 is part of the Java Enterprise Edition 6 while versions 2.2.* are part of Java EE 7.
Version 2.0 supersedes version 1.2 and brings in mandatory support for Facelets as the view
technology for JSF pages, built in Ajax support and built in support for bookmarking & page-load.
Version 2.2 introduced new concepts like stateless views, page flow and the ability to create portable
resource contracts.
There are five JSF specific tag libraries defined in this specification, namely
JSF HTML Tag Library
JSF Core Tag Library
JSTL Core Tag Library
JSTL Functions Tag Library
JSF Facelets Tag Library
137
12 - javaserver faces
12.3 facelets
Facelet is a view technology for Java Server Faces (JSF) that allows building composite views
more quickly and easily than with JSP which is the default view technology for JSF. JSP pages are
compiled into servlets but its not the case with Facelets because Facelet pages are XML compliant
and its framework uses a fast SAXbased compiler to build views. Facelets can make changes to
pages immediately so developing JSF applications with Facelets is simply faster.
This tag library contains JavaServer Faces component tags for all UIComponent + HTML RenderKit
Renderer combinations defined in the JavaServer Faces specification. As of version 1.2 of the JFS
specification, there are 25 HTML JSF tags.
138
12 - javaserver faces
outputLink
outputText
panelGrid
pnelGroup
selectBooleanCheckbox
selectManyCheckbox
selectManyListbox
selectManyMenu
selectOneListbox
selectOneMenu
selectOneRadio
In the next paragraphs, we'll have a closer look at some of these tags.
12.4.2 h:dataTable
The dataTable tag renders an HTML 4.01 compliant table element that can be associated with a
backing bean to obtain its data as well as for event handling purposes.
The table can be customized extensively using cascading stylesheet (CSS) classes and definitions
to enhance the appearance of the table's headers, footers, columns and rows. Common formatting
techniques, such as alternating row colors, can be accomplished quite easily with this tag.
The dataTable tag typically contains one or more column tags that define the columns of the table.
A column component is rendered as a single "td" element. For more information about columns, see
the column tag documentation.
A dataTable tag can also contain header and footer facets. These are rendered as a single "th"
element in a row at the top of the table and as a single "td" element in a row at the bottom of the table,
respectively.
Example:
<h:dataTable id="table1" value="#{shoppingCartBean.items}" var="item">
<f:facet name="header">
<h:outputText value="Your Shopping Cart" />
</f:facet>
<h:column>
<f:facet name="header">
<h:outputText value="Item Description" />
</f:facet>
<h:outputText value="#{item.description}" />
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Price" />
</f:facet>
<h:outputText value="#{item.price}" />
</h:column>
139
12 - javaserver faces
<f:facet name="footer">
<h:outputText value="Total: #{shoppingCartBean.total}" />
</f:facet>
</h:dataTable>
HTML Output
<table id="table1">
<thead>
<tr><th scope="colgroup" colspan="2">Your Shopping Cart</th></tr>
<tr><th>Item Description</th><th>Price</th></tr>
</thead>
<tbody>
<tr><td>Delicious Apple</td><td>$5.00</td></tr>
<tr><td>Juicy Orange</td><td>$5.00</td></tr>
<tr><td>Tasty Melon</td><td>$5.00</td></tr>
</tbody>
<tfoot>
<tr><td colspan="2">Total: $15.00</td></tr>
</tfoot>
</table>
12.4.3 h:form
The form tag renders an HTML form element. JSF forms use the "post-back" technique to submit
form data back to the page that contains the form. The use of the POST method is also required and it
is not possible to use the GET method for forms generated by this tag.
If your application requires the use of the GET method for form submission, your options include
using plain HTML forms, binding request parameters to backing bean properties, and using the
outputLink tag to generate dynamic hyperlinks.
Example:
<h:form id="form1"></h:form>
HTML Output
<form id="form1" name="form1" method="post" action="/demo/form.jsp" enctype="application/x-
www-form-urlencoded"></form>
12.4.4 h:commandButton
The commandButton tag renders an HTML submit button that can be associated with a backing
bean or ActionListener class for event handling purposes. The display value of the button can also be
obtained from a message bundle to support internationalization (I18N).
Example:
<h:commandButton id="button1" value="#{bundle.checkoutLabel}"
action="#{shoppingCartBean.checkout}" />
HTML Output
<input id="form:button1" name="form:button1" type="submit" value="Check Out"
onclick="someEvent();" />
140
12 - javaserver faces
12.4.5 h:inputText
The inputText tag renders an HTML input element of the type "text".
Example:
<h:inputText id="username" value="#{userBean.user.username}" />
HTML Output
<input id="form:username" name="form:username" type="text" />
HTML Output
<input type="text" id="form:username" name="form:username" value=""/>
<span style="color:red">"username": Value is required.</span>
The core JavaServer Faces tags define custom actions that are independent of any particular
RenderKit.
141
12 - javaserver faces
validateLength
validateLongRange
validator
valueChangeListener
verbatim
view
Some of these tags will be detailed in the next paragraphs.
12.5.2 f:facet
A facet represents a named section within a container component
The JSF facets specify the requirements and constraints that apply to a JSF project.
The Facet tag registers a named facet on the component associated with the enclosing tag. For
example, you can create a header and a footer facet for a dataTable component.
Example:
<h:dataTable id="reportTable" value="#{reportBean.dailyReport}"
var="item">
<h:column>
<f:facet name="header">
<h:outputText value="Daily Report" />
</f:facet>
<h:outputText value="#{item}" />
</h:column>
</h:dataTable>
HTML Output
<table id="reportTable">
<thead>
<tr><th>Daily Report</th></tr>
</thead>
<tbody>
<tr><td>Item 1</td></tr>
<tr><td>Item 2</td></tr>
<tr><td>Item 3</td></tr>
</tbody>
</table>
12.5.3 f:validator
The Validator tag registers a named Validator instance on the component associated with the
enclosing tag. The JavaServer Faces framework includes three standard validators (see the
validateDoubleRange, validateLength, and validateLongRange tags) but the Validator interface can be
implemented by classes that provide custom validation for your application. This tag accepts one value
matching the validator ID you assigned to your validator class in your Faces configuration file. The
body content of this tag must be empty.
Example:
<h:inputText id="emailAddress"
142
12 - javaserver faces
value="#{customerBean.customer.emailAddress}">
<f:validator validatorId="emailAddressValidator" />
</h:inputText>
<h:message for="emailAddress" />
HTML Output
<input id="form:emailAddress" name="form:emailAddress" type="text"
value="fake@email"/>
Invalid email address.
12.5.4 f:valueChangeListener
The ValueChangeListener tag registers a ValueChangeListener instance on the component
associated with the enclosing tag. The ValueChangeListener interface should be implemented by
classes that you want to register with components that publish value change events.
Any component that receives user input, such as one of the HTML select or text input components,
can publish value change events. A component fires a value change event when its input changes, but
only if the new input is validated successfully.
You can register several ValueChangeListeners with a component and they will be invoked in the
order that they are registered. An alternative to this tag is to use a method-binding expression pointing
at a value change listener method of a backing bean on the component tag itself.
Notice in the example below the use of the JavaScript onchange() event to trigger form submission
when the list selection changes. Without this JavaScript event, the user must manually submit the
form to invoke the ValueChangeListener.
Example:
<h:selectOneMenu id="optionMenu" value="#{optionBean.selectedOption}"
onchange="submit()">
<f:selectItems value="#{optionBean.optionList}" />
<f:valueChangeListener
type="com.mycompany.MyValueChangeListenerImpl" />
</h:selectOneMenu>
HTML Output
<select name="form:optionMenu" size="1" onchange="submit()">
<option value="1">Option 1</option>
<option value="2">Option 2</option>
<option value="3">Option 3</option>
</select>
12.5.5 f:view
The View tag is the container for all JavaServer Faces component tags used on a page. You can
wrap the root element of the structured markup language used in your document with this tag to
ensure that all child tags are part of the same view.
This tag is useful for internationalization (I18N) purposes. It provides you with several options for
presenting your user with localized views of your application. By default the JSF framework will attempt
to select the best view for your user based on the Accept-Language header sent to the server from the
user's browser as part of the HTTP request for your page.
If the locale requested by the user is not supported by your application, the JSF framework will use
the default locale specified in your Faces configuration file. If you have not specified a default locale,
JSF will use the default locale for the Java Virtual Machine serving your application.
If your application supports the locale requested by the user, JSF will set that locale for the view and
143
12 - javaserver faces
will display the messages for that locale defined in the locale's message bundle.
You can also specify the locale for which the view is to be rendered by explicitly setting the locale
attribute of the view tag. This allows you to design localized versions of each page, including images
and styles, for each locale you wish to support.
Another option is to obtain the locale dynamically through user interaction. This information could
later be stored in a cookie and/or a database to identify which locale is preferred by your user. The
locale attribute accepts a value-binding expression that could resolve to the desired locale.
Example:
welcome_en.jsp (English)
<f:view locale="en">
<f:loadBundle basename="com.mycompany.MessageBundle" var="bundle" />
<h:outputText value="#{bundle.welcomeMessage}" />
</f:view>
welcome_fr.jsp (French)
<f:view locale="fr">
<f:loadBundle basename="com.mycompany.MessageBundle" var="bundle" />
<h:outputText value="#{bundle.welcomeMessage}" />
</f:view>
HTML Output
welcome_en.jsp (English)
Welcome to our site!
welcome_fr.jsp (French)
Bienvenue notre site!
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
144
12 - javaserver faces
12.7.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
145
12 - javaserver faces
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.7.3.1 PersonBean.java
Put this code in the file:
package myJFSapp;
146
12 - javaserver faces
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.
<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.7.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>
</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>
147
12 - javaserver faces
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.7.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.7.5.1 inputname.jsp
Put the following coding into this file:
<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>
<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
148
12 - javaserver faces
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.
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"/>
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>
12.7.5.2 greeting.jsp
Put this coding inside the second JSP file:
<html>
<head>
<title>greeting page</title>
149
12 - javaserver faces
</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!
http://localhost:8080/myJFSapp/
<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.7.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
150
12 - javaserver faces
12.7.8 Deploying
Before you can run this application within the servlet container, we need to deploy it. We will use 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.7.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.8.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.
151
12 - javaserver faces
// LoginManager.java
152
12 - javaserver faces
package login;
if ( _uid.equalsIgnoreCase("foo") &&
_pwd.equalsIgnoreCase("bar") )
action = "loginPass";
else
action = "loginFail";
return action;
}
}
153
12 - javaserver faces
<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:
3. Create error.jsp: create this file similarly to index.jsp, but in webroot/pages. Enter
the following code:
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.
154
12 - javaserver faces
</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 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:
155
12 - javaserver faces
156
12 - javaserver faces
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:
157
12 - javaserver faces
158
12 - javaserver faces
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.
159
12 - javaserver faces
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
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
160
12 - javaserver faces
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
implementation class to use.
If none of the above steps yield a match, the JavaServer Faces implementation specific class
is used.
161
12 - javaserver faces
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 interface 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
manipulate this component; it is for display purposes only.
UIInput - a UIComponent that represents a component that both displays output to the user
162
12 - javaserver faces
(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.
163
12 - javaserver faces
164
12 - javaserver faces
ExternalContext - allows the Faces API to be unaware of the nature of its containing
application environment. In particular, this class allows JavaServer Faces based applications
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.
165
12 - javaserver faces
Contains classes and interfaces for evaluating and processing reference expressions.
Classes:
Exceptions:
Contains interfaces describing events and event listeners, and event implementation classes.
Interfaces:
Classes:
166
12 - javaserver faces
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.
Contains the interface DataModelListener and several classes providing standard model data beans
for JavaServer Faces. Classes:
167
12 - javaserver faces
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.
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.
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.
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
168
12 - javaserver faces
Regardless of whether you are using JSF with JSP pages, servlets, or some other web technology,
each request/response flow that involves JSF follows a certain life cycle. Several kinds of
request/response cycles can occur in a JSF-enabled application. You can have a request that comes
from a previously rendered JSF page (a JSF request) and a request that comes from a non-JSF page
(a non-JSF request). Likewise, you can have a JSF response or a non-JSF response. We are
concerned with these three request/response pairs:
Non-JSF request generates JSF response
JSF request generates JSF response
JSF request generates non-JSF response
Of course, you can also have a non-JSF request that generates a non-JSF response. Because this
does not involve JSF in any way, the JSF life cycle does not apply.
JSP pages have a relatively simple life cycle. A JSP page source is compiled into a page
implementation class. When a web server receives a request, that request is passed to the container,
which passes the request to the page class. The page class processes the request and then writes the
response back to the client. When other pages are included or the request is forwarded, or when an
exception occurs, the process includes a few more components or pages, but basically, a small set of
classes processes a request and sends back a response.
When using JSF, the life cycle is more complicated. This is because the core of JSF is the MVC
pattern, which has several implications. User actions in JSF-generated views take place in a client that
does not have a permanent connection to the server. The delivery of user actions or page events is
delayed until a new connection is established. The JSF life cycle must handle this delay between event
and event processing. Also, the JSF life cycle must ensure that the view is correct before rendering
the view. To ensure that the business state is never invalid, the JSF system includes a phase for
validating inputs and another for updating the model only after all inputs pass validation.
In MVC, the presentation of data (the view) is separate from its representation in the system (the
model). When the model is updated, the controller sends a message to the view, telling the view to
update its presentation. When the user takes some action with the presentation, the controller sends a
message to the model, telling the model to update its data. In JSF, the model is composed of business
objects that are usually implemented as JavaBeans, the controller is the JSF implementation, and the
UI components are the view.
The JSF life cycle has six phases as defined by the JSF specification:
Restore View: In this phase, the JSF implementation restores the objects and data structures that
represent the view of the request. If this is the clients first visit to a page, the JSF implementation
must create the view. When a JSF implementation creates and renders a JSF-enabled page, it
creates UI objects for each view component. The components are stored in a component tree, and the
state of the UI view is saved for subsequent requests. If this is a subsequent request, the saved UI
view is retrieved for the processing of the current request.
Apply Request Values: Any data that was sent as part of the request is passed to the
169
12 - javaserver faces
appropriate UI objects that compose the view. These objects update their state with the data values.
Data can come from input fields in a web form, from cookies sent as part of the request, or from
request headers. Data for some components, such as components that create HTML input fields, is
validated at this time. Note that this does not yet update the business objects that compose the model.
It updates only the UI components with the new data.
Process Validations: The data that was submitted with the form is validated (if it was not
validated in the previous phase). As with the previous phase, this does not yet update the business
objects in the application. This is because if the JSF implementation began to update the business
objects as data was validated, and a piece of data failed validation, the model would be partially
updated and in an invalid state.
Update Model Values: After all validations are complete, the business objects that make up the
application are updated with the validated data from the request. In addition, if any of the data needs to
be converted to a different format to update the model (for example, converting a String to a Date
object), the conversion occurs in this phase. Conversion is needed when the data type of a property is
not a String or a Java primitive.
Invoke Application: During this phase, the action method of any command button or link that was
activated is called. In addition, any events that were generated during previous phases and that have
not yet been handled are passed to the web application so that it can complete any other processing
of the request that is required.
Render Response: The response UI components are rendered, and the response is sent to the
client. The state of the UI components is saved so that the component tree can be restored when the
client sends another request. For a JSF-enabled application, the thread of execution for a
request/response cycle can flow through each phase, in the order listed here and as shown in the
figure below. However, depending on the request, and what happens during the processing and
response, not every request will flow through all six phases.
In the above figure, you can see a number of optional paths through the life cycle. For example, if
errors occur during any of the phases, the flow of execution transfers immediately to the Render
Response phase, skipping any remaining phases. One way this might occur is if input data is incorrect
or invalid. If data fails validation in either the Apply Request Values or Process Validations phase,
information about the error is saved and processing proceeds directly to the Render Response phase.
Also, if at any point in the life cycle the request processing is complete and a non-JSF response is to
be sent to the client, the flow of execution can exit the life cycle without completing further phases.
170
13 - WebSocket
13 - WEBSOCKET
13.1 the WebSocket API
In a WebSocket application, the server publishes a WebSocket endpoint and the client uses the
endpoints URI to connect to the server. The WebSocket protocol is symmetrical after the connection
has been established: the client and the server can send messages to each other at any time while the
connection is open, and they can close the connection at any time. Clients usually connect only to one
server, and servers accept connections from multiple clients.
The WebSocket protocol has two parts: handshake and data transfer. The client initiates the
handshake by sending a request to a WebSocket endpoint using its URI. The handshake is
compatible with existing HTTP-based infrastructure: web servers interpret it as an HTTP connection
upgrade request. An example handshake from a client looks like this:
An example handshake from the server in response to the client looks like this:
The server applies a known operation to the value of the Sec-WebSocket-Key header to generate
the value of the Sec-WebSocket-Accept header. The client applies the same operation to the value
171
13 - WebSocket
of the Sec-WebSocket-Key header, and the connection is established successfully if the result
matches the value received from the server. The client and the server can send messages to each
other after a successful handshake.
WebSocket supports text messages (encoded as UTF-8) and binary messages. The control
frames in WebSocket are close, ping, and pong (a response to a ping frame). Ping and pong frames
may also contain application data. WebSocket endpoints are represented by URIs that have the
following form:
ws://host:port/path?query
wss://host:port/path?query
The ws scheme represents an unencrypted WebSocket connection, and the wss scheme
represents an encrypted connection. The port component is optional; the default port number is 80 for
unencrypted connections and 443 for encrypted connections. The path component indicates the
location of an endpoint within a server. The query component is optional.
Modern web browsers implement the WebSocket protocol and provide a JavaScript API to connect
to endpoints, send messages, and assign callback methods for WebSocket events (such as opened
connections, received messages, and closed connections).
The Java EE platform includes the Java API for WebSocket (JSR-356), which enables you to
create, configure, and deploy WebSocket endpoints in web applications. The WebSocket client API
specified in JSR-356 also enables you to access remote WebSocket endpoints from any Java
application.
The Java API for WebSocket consists of the following packages:
The javax.websocket.server package contains annotations, classes, and interfaces to
create and configure server endpoints.
The javax.websocket package contains annotations, classes, interfaces, and exceptions
that are common to client and server endpoints.
WebSocket endpoints are instances of the javax.websocket.Endpoint class. The Java API for
WebSocket enables you to create two kinds of endpoints: programmatic endpoints and annotated
endpoints. To create a programmatic endpoint, you extend the Endpoint class and override its
lifecycle methods. To create an annotated endpoint, you decorate a Java class and some of its
methods with the annotations provided by the packages above. After you have created an endpoint,
you deploy it to a specific URI in the application so remote clients can connect to it.
The process for creating and deploying a WebSocket endpoint is the following:
1. Create an endpoint class.
2. Implement the lifecycle methods of the endpoint.
3. Add your business logic to the endpoint.
4. Deploy the endpoint inside a web application.
The process is slightly different for programmatic endpoints and annotated endpoints, and it is
covered in detail in the following sections.
The following example shows how to create an endpoint by extending the Endpoint class:
172
13 - WebSocket
This endpoint echoes every message received. The Endpoint class defines three lifecycle
methods: onOpen, onClose, and onError. The EchoEndpoint class implements the onOpen
method, which is the only abstract method in the Endpoint class.
The Session parameter represents a conversation between this endpoint and the remote endpoint.
The addMessageHandler method registers message handlers, and the getBasicRemote method
returns an object that represents the remote endpoint. The Session interface is covered in detail in
the rest of this chapter.
The message handler is implemented as an anonymous inner class. The onMessage method of
the message handler is invoked when the endpoint receives a text message.
To deploy this programmatic endpoint, use the following code in your Java EE application:
ServerEndpointConfig.Builder.create(EchoEndpoint.class,
"/echo").build();
for example,
ws://localhost:8080/echoapp/echo.
The following example shows how to create the same endpoint from Programmatic Endpoints using
annotations instead:
@ServerEndpoint("/echo")
public class EchoEndpoint {
@OnMessage
public void onMessage(Session session, String msg) {
try {
session.getBasicRemote().sendText(msg);
173
13 - WebSocket
The annotated endpoint is simpler than the equivalent programmatic endpoint, and it is deployed
automatically with the application to the relative path defined in the ServerEndpoint annotation.
Instead of having to create an additional class for the message handler, this example uses the
OnMessage annotation to designate the method invoked to handle messages.
The table below lists the annotations available in the javax.websocket package to designate the
methods that handle lifecycle events. The examples in the table show the most common parameters
for these methods. See the API reference for details on what combinations of parameters are allowed
in each case.
WebSocket endpoints can send and receive text and binary messages. In addition, they can also
send ping frames and receive pong frames. This section describes how to use the Session and
RemoteEndpoint interfaces to send messages to the connected peer and how to use the
OnMessage annotation to receive messages from it.
174
13 - WebSocket
@ServerEndpoint("/echoall")
public class EchoAllEndpoint {
@OnMessage
public void onMessage(Session session, String msg) {
try {
for (Session sess : session.getOpenSessions()) {
if (sess.isOpen()) sess.getBasicRemote().sendText(msg);
}
} catch (IOException e) { ... }
}
}
@ServerEndpoint("/receive")
public class ReceiveEndpoint {
@OnMessage
public void textMessage(Session session, String msg) {
System.out.println("Text message: " + msg);
175
13 - WebSocket
}
@OnMessage
public void binaryMessage(Session session, ByteBuffer msg) {
System.out.println("Binary message: " + msg.toString());
}
@OnMessage
public void pongMessage(Session session, PongMessage msg) {
System.out.println("Pong message: " +
msg.getApplicationData().toString());
}
}
The Java API for WebSocket provides support for converting between WebSocket messages and
custom Java types using encoders and decoders. An encoder takes a Java object and produces a
representation that can be transmitted as a WebSocket message; for example, encoders typically
produce JSON, XML, or binary representations. A decoder performs the reverse function: it reads a
WebSocket message and creates a Java object.
This mechanism simplifies WebSocket applications, because it decouples the business logic from
the serialization and deserialization of objects.
176
13 - WebSocket
}
}
And similarly for Encoder.Text<MessageB>. Then, add the encoders parameter to the
ServerEndpoint annotation as follows:
@ServerEndpoint(
value = "/myendpoint",
encoders = { MessageATextEncoder.class, MessageBTextEncoder.class }
)
public class EncEndpoint { ... }
Now you can send MessageA and MessageB objects as WebSocket messages using the
sendObject method as follows:
As in this example, you can have more than one encoder for text messages and more than one
encoder for binary messages. Like endpoints, encoder instances are associated with one and only one
WebSocket connection and peer, so there is only one thread executing the code of an encoder
instance at any given time.
177
13 - WebSocket
if ( /* message is an A message */ )
return new MessageA(...);
else if ( /* message is a B message */ )
return new MessageB(...);
}
@Override
public boolean willDecode(String string) {
// Determine if the message can be converted into either a
// MessageA object or a MessageB object...
return canDecode;
}
}
@ServerEndpoint(
value = "/myendpoint",
encoders = { MessageATextEncoder.class, MessageBTextEncoder.class },
decoders = { MessageTextDecoder.class }
)
public class EncDecEndpoint { ... }
Now define a method in the endpoint class that receives MessageA and MessageB objects as
follows:
@OnMessage
public void message(Session session, Message msg) {
if (msg instanceof MessageA) {
// We received a MessageA object...
else if (msg instanceof MessageB) {
// We received a MessageB object...
}
}
Like endpoints, decoder instances are associated with one and only one WebSocket connection
and peer, so there is only one thread executing the code of a decoder instance at any given time.
178
13 - WebSocket
@ServerEndpoint("/dukeetf")
public class ETFEndpoint {
private static final Logger logger = Logger.getLogger("ETFEndpoint");
The lifecycle methods of the endpoint add and remove sessions to and from the queue:
@ServerEndpoint("/dukeetf")
public class ETFEndpoint {
...
@OnOpen
public void openConnection(Session session) {
/* Register this connection in the queue */
queue.add(session);
logger.log(Level.INFO, "Connection opened.");
}
@OnClose
public void closedConnection(Session session) {
/* Remove this connection from the queue */
queue.remove(session);
179
13 - WebSocket
}
@OnError
public void error(Session session, Throwable t) {
/* Remove this connection from the queue */
queue.remove(session);
logger.log(Level.INFO, "Connection error.");
}
}
@Startup
@Singleton
public class PriceVolumeBean {
/* Use the container's timer service */
@Resource TimerService tservice;
private Random random;
private volatile double price = 100.0;
private volatile int volume = 300000;
private static final Logger logger =
Logger.getLogger("PriceVolumeBean");
@PostConstruct
public void init() {
/* Intialize the EJB and create a timer */
logger.log(Level.INFO, "Initializing EJB.");
random = new Random();
tservice.createIntervalTimer(1000, 1000, new TimerConfig());
}
@Timeout
public void timeout() {
/* Adjust price and volume and send updates */
price += 1.0*(random.nextInt(100)-50)/100.0;
volume += random.nextInt(5000) - 2500;
ETFEndpoint.send(price, volume);
}
}
The enterprise bean calls the send method of the ETFEndpoint class in the timeout method.
<html xmlns="http://www.w3.org/1999/xhtml">
<head>...</head>
180
13 - WebSocket
<body onload="makeAjaxRequest();">
<table>
...
<td id="price">--.--</td>
...
<td id="volume">--</td>
...
</table>
</body>
</html>
The JavaScript code uses the WebSocket API to connect to the server endpoint and to designate a
callback method for incoming messages. The callback method updates the page with the new
information.
var wsocket;
function connect() {
wsocket = new WebSocket("ws://localhost:8080/dukeetf2/dukeetf");
wsocket.onmessage = onMessage;
}
function onMessage(evt) {
var arraypv = evt.data.split(",");
document.getElementById("price").innerHTML = arraypv[0];
document.getElementById("volume").innerHTML = arraypv[1];
}
window.addEventListener("load", connect, false);
The WebSocket API is supported by most modern browsers, and it is widely used in HTML5 web
client development.
Open the same URL on a different web browser tab or window to see how both pages get price and
volume updates simultaneously.
181
14 - JSON processing
14 - JSON PROCESSING
14.1 JSON
JSON is a text-based data exchange format derived from JavaScript that is used in web services
and other connected applications. The following sections provide an introduction to JSON syntax, an
overview of JSON uses, and a description of the most common approaches to generate and parse
JSON.
{
"firstName": "Duke",
"lastName": "Java",
"age": 18,
"streetAddress": "100 Internet Dr",
"city": "JavaTown",
"state": "JA",
"postalCode": "12345",
"phoneNumbers": [
{ "Mobile": "111-111-1111" },
{ "Home": "222-222-2222" }
]
}
182
14 - JSON processing
Content-Type: application/json
JSON representations are usually more compact than XML representations because JSON does
not have closing tags. Unlike XML, JSON does not have a widely accepted schema for defining and
validating the structure of JSON data.
There are two programming models for generating and parsing JSON data: the object model and
the streaming model, which are similar to those used for XML documents.
The object model creates a tree that represents the JSON data in memory. The tree can then be
navigated, analyzed, or modified. This approach is the most flexible and allows for processing that
requires access to the complete contents of the tree. However, it is often slower than the streaming
model and requires more memory. The object model generates JSON output by navigating the entire
tree at once.
The streaming model uses an event-based parser that reads JSON data one element at a time. The
parser generates events and stops for processing when an object or an array begins or ends, when it
finds a key, or when it finds a value. Each element can be processed or discarded by the application
code, then the parser proceeds to the next event. This approach is adequate for local processing,
where the processing of an element does not require information from the rest of the data. The
streaming model generates JSON output to a given stream by making a function call with one element
at a time.
There are many JSON generators and parsers available for different programming languages and
environments. JSON Processing in Java EE describes the functionality provided by the Java API for
JSON Processing (JSR-353).
Java EE includes support for JSR-353, which provides an API to parse, transform, and query JSON
data using the object model or the streaming model described in Generating and Parsing JSON Data.
The Java API for JSON Processing contains the following packages:
The javax.json package contains a reader interface, a writer interface, and a model builder
interface for the object model. This package also contains other utility classes and Java types
for JSON elements.
The javax.json.stream package contains a parser interface and a generator interface for the
streaming model.
183
14 - JSON processing
, , , and
are subtypes of .
This section describes four use cases of the object model API: creating an object model from JSON
data, creating an object model from application code, navigating an object model, and writing an object
model to a stream.
import java.io.FileReader;
import javax.json.Json;
import javax.json.JsonReader;
import javax.json.JsonStructure;
...
JsonReader reader = Json.createReader(new FileReader("jsondata.txt"));
JsonStructure jsonst = reader.read();
The object reference jsonst can either be of type JsonObject or JsonArray depending on the
contents of the file. JsonObject and JsonArray are subtypes of JsonStructure. This reference
represents the top of the tree and can be used to navigate the tree or to write it to a stream as JSON
data.
184
14 - JSON processing
import javax.json.Json;
import javax.json.JsonObject;
...
JsonObject model = Json.createObjectBuilder()
.add("firstName", "Duke")
.add("lastName", "Java")
.add("age", 18)
.add("streetAddress", "100 Internet Dr")
.add("city", "JavaTown")
.add("state", "JA")
.add("postalCode", "12345")
.add("phoneNumbers", Json.createArrayBuilder()
.add(Json.createObjectBuilder()
.add("type", "mobile")
.add("number", "111-111-1111"))
.add(Json.createObjectBuilder()
.add("type", "home")
.add("number", "222-222-2222")))
.build();
The object reference represents the top of the tree, which is created by nesting calls to the
methods and built by calling the method. The class contains the
following methods:
The class contains similar methods that do not have a name (key)
parameter. You can nest arrays and objects by passing a new object or a new
object to the corresponding method as shown in this example.
The resulting tree represents the JSON data from JSON Syntax.
185
14 - JSON processing
import javax.json.JsonValue;
import javax.json.JsonObject;
import javax.json.JsonArray;
import javax.json.JsonNumber;
import javax.json.JsonString;
...
public static void navigateTree(JsonValue tree, String key) {
if (key != null)
System.out.print("Key " + key + ": ");
switch(tree.getValueType()) {
case OBJECT:
System.out.println("OBJECT");
JsonObject object = (JsonObject) tree;
for (String name : object.keySet())
navigateTree(object.get(name), name);
break;
case ARRAY:
System.out.println("ARRAY");
JsonArray array = (JsonArray) tree;
for (JsonValue val : array)
navigateTree(val, null);
break;
case STRING:
JsonString st = (JsonString) tree;
System.out.println("STRING " + st.getString());
break;
case NUMBER:
JsonNumber num = (JsonNumber) tree;
System.out.println("NUMBER " + num.toString());
break;
case TRUE:
case FALSE:
case NULL:
System.out.println(tree.getValueType().toString());
break;
}
}
The method can be used with the models built in Creating an Object Model
from JSON Data and Creating an Object Model from Application Code as follows:
navigateTree(model, null);
The navigateTree() method takes two arguments: a JSON element and a key. The key is only
used to help print the key-value pairs inside objects. Elements in a tree are represented by the
JsonValue type. If the element is an object or an array, a new call to this method is made for every
element contained in the object or array. If the element is a value, it is printed to the standard output.
The JsonValue.getValueType() method identifies the element as an object, an array, or a
186
14 - JSON processing
value. For objects, the JsonObject.keySet() method returns a set of strings that contains the keys
in the object, and the JsonObject.get(String name) method returns the value of the element
whose key is name. For arrays, JsonArray implements the List<JsonValue> interface. You can
use enhanced for loops with the Set<String> instance returned by JsonObject.keySet() and
with instances of JsonArray as shown in this example.
The output of the navigateTree method for the model built in Creating an Object Model from
Application Code is the following:
OBJECT
Key firstName: STRING Duke
Key lastName: STRING Java
Key age: NUMBER 18
Key streetAddress: STRING 100 Internet Dr
Key city: STRING JavaTown
Key state: STRING JA
Key postalCode: STRING 12345
Key phoneNumbers: ARRAY
OBJECT
Key type: STRING mobile
Key number: STRING 111-111-1111
OBJECT
Key type: STRING home
Key number: STRING 222-222-2222
import java.io.StringWriter;
import javax.json.JsonWriter;
...
StringWriter stWriter = new StringWriter();
JsonWriter jsonWriter = Json.createWriter(stWriter);
jsonWriter.writeObject(model);
jsonWriter.close();
String jsonData = stWriter.toString();
System.out.println(jsonData);
187
14 - JSON processing
System.out.println(jsonData);
This section describes two use cases of the streaming API: reading JSON data using a parser and
writing JSON data using a generator.
import javax.json.Json;
import javax.json.stream.JsonParser;
...
JsonParser parser = Json.createParser(new StringReader(jsonData));
while (parser.hasNext()) {
JsonParser.Event event = parser.next();
switch(event) {
case START_ARRAY:
case END_ARRAY:
case START_OBJECT:
case END_OBJECT:
case VALUE_FALSE:
case VALUE_NULL:
case VALUE_TRUE:
System.out.println(event.toString());
break;
case KEY_NAME:
System.out.print(event.toString() + " " +
parser.getString() + " - ");
break;
case VALUE_STRING:
case VALUE_NUMBER:
System.out.println(event.toString() + " " +
parser.getString());
break;
}
}
188
14 - JSON processing
you can obtain the content of the element by calling the method . For
events, you can also use the methods ,
, , and
. See the JSR-353 API reference for more information.
The output of this example is the following:
START_OBJECT
KEY_NAME firstName - VALUE_STRING Duke
KEY_NAME lastName - VALUE_STRING Java
KEY_NAME age - VALUE_NUMBER 18
KEY_NAME streetAddress - VALUE_STRING 100 Internet Dr
KEY_NAME city - VALUE_STRING JavaTown
KEY_NAME state - VALUE_STRING JA
KEY_NAME postalCode - VALUE_STRING 12345
KEY_NAME phoneNumbers - START_ARRAY
START_OBJECT
KEY_NAME type - VALUE_STRING mobile
KEY_NAME number - VALUE_STRING 111-111-1111
END_OBJECT
START_OBJECT
KEY_NAME type - VALUE_STRING home
KEY_NAME number - VALUE_STRING 222-222-2222
END_OBJECT
END_ARRAY
END_OBJECT
189
14 - JSON processing
.writeEnd()
.writeEnd()
.writeEnd();
gen.close();
This section explains how the Java API for JSON Processing is related to other Java EE packages
that provide JSON support for RESTful web services.
Jersey, the reference implementation for JAX-RS (JSR-311) (java API for RESTful Services)
included in GlassFish Server, provides support for binding JSON data from RESTful resource
methods to Java objects using JAXB (Java Architecture for XML Binding), as described in Using JAX-
RS With JAXB, "JAX-RS: Advanced Topics and Example". However, JSON support is not part of JAX-
RS (JSR-311) or JAX-B (JSR-222), so that procedure may not work for Java EE implementations
other than GlassFish Server.
The Java API for JSON Processing (JSR-353) does not explicitly support JSON binding in Java. A
future JSR (JSON Binding) that is similar to JAXB for XML is under consideration for a future release
of Java EE.
You can still use the Java API for JSON Processing with JAX-RS resource methods. For more
information, see the sample code for JSON Processing included with the Java EE 7 SDK.
This section describes how to build and run the example application. This example is
a web application that demonstrates how to create an object model from form data, how to parse
JSON data, and how write JSON data using the object model API.
The example application is in the tut-install
directory.
190
14 - JSON processing
output from the model is similar to the example in Writing an Object Model to a Stream. The code to
navigate the object model tree is similar to the example in Navigating an Object Model.
http://localhost:8080/jsonpmodel/faces/index.xhtml
This section describes how to build and run the example application. This
example is a web application that demonstrates how to create JSON data from form data, how to
parse JSON data, and how write JSON output using the streaming API.
The example application is in the tut-
install directory.
191
14 - JSON processing
http://localhost:8080/jsonpstreaming/faces/index.xhtml
192
15 - JNDI
15 - JNDI
15.1 what is JNDI?
JNDI is an API specified in Java technology that provides naming and directory functionality to
applications written in the Java programming language. It is designed especially for the Java platform
using Java's object model. Using JNDI, applications based on Java technology can store and retrieve
named Java objects of any type. In addition, JNDI provides methods for performing standard directory
operations, such as associating attributes with objects and searching for objects using their attributes.
JNDI has been part of Java2EE starting with version 1.2 of Java EE.
JNDI is also defined independent of any specific naming or directory service implementation. It
enables applications to access different, possibly multiple, naming and directory services using a
common API. Different naming and directory service providers can be plugged in seamlessly behind
this common API. This enables Java technology-based applications to take advantage of information
in a variety of existing naming and directory services, such as LDAP, NDS, DNS, and NIS(YP)
(Network Information Service), as well as enabling the applications to coexist with legacy software and
systems.
A fundamental facility in any computing system is the naming service -the means by which names
are associated with objects and objects are found based on their names. When using almost any
computer program or system, you are always naming one object or another. For example, when you
use an electronic mail system, you must provide the name of the recipient to whom you want to send
mail. To access a file in the computer, you must supply its name. A naming service allows you to look
up an object given its name.
A naming service's primary function is to map people-friendly names to objects, such as
addresses, identifiers, or objects typically used by computer programs. For example, the Internet
Domain Name System (DNS) maps machine names (such as www.sun.com) to IP addresses (such
as 192.9.48.5). A file system maps a filename (for example, c:\bin\autoexec.bat) to a file
handle that a program can use to access the contents of the file. These two examples also illustrate
the wide range of scale at which naming services exist--from naming an object on the Internet to
naming a file on the local file system.
15.2.1 names
To look up an object in a naming system, you supply it the name of the object. The naming system
determines the syntax that the name must follow. This syntax is sometimes called the naming
system's naming convention.
For example, the UNIXTM file system's naming convention is that a file is named from its path
relative to the root of the file system, with each component in the path separated from left to right using
the forward slash character ("/"). The UNIX pathname, /usr/hello, for example, names a file
hello in the file directory usr, which is located in the root of the file system.
The DNS naming convention calls for components in the DNS name to be ordered from right to left
and delimited by the dot character ("."). Thus the DNS name sales.Wiz.COM names a DNS entry
with the name sales, relative to the DNS entry Wiz.COM. The DNS entry Wiz.COM, in turn, names an
entry with the name Wiz in the COM entry.
193
15 - JNDI
The Lightweight Directory Access Protocol (LDAP) naming convention orders components from
right to left, delimited by the comma character (","). Thus the LDAP name cn=Rosanna Lee,
o=Sun, c=US names an LDAP entry cn=Rosanna Lee, relative to the entry o=Sun, which in turn, is
relative to c=us. The LDAP has the further rule that each component of the name must be a
name/value pair with the name and value separated by an equals character ("=").
15.2.2 bindings
The association of a name with an object is called a binding. For example, a file name is bound to
a file.
The DNS contains bindings that map machine names to IP addresses. An LDAP name is bound to
an LDAP entry.
15.2.4 context
A context is a set of name-to-object bindings. Every context has an associated naming convention.
A context provides a lookup (resolution) operation that returns the object and may provide operations
such as those for binding names, unbinding names, and listing bound names. A name in one context
object can be bound to another context object (called a subcontext) that has the same naming
convention.
For example, a file directory, such as /usr, in the UNIX file system is a context. A file directory
named relative to another file directory is a subcontext (some UNIX users refer to this as a
subdirectory). That is, in a file directory /usr/bin, the directory bin is a subcontext of usr. In
another example, a DNS domain, such as COM, is a context. A DNS domain named relative to another
DNS domain is a subcontext. For example, in the DNS domain Sun.COM, the DNS domain Sun is a
subcontext of COM.
Finally, an LDAP entry, such as c=us, is a context. An LDAP entry named relative to another LDAP
entry is a subcontext. For example, in the an LDAP entry o=sun,c=us, the entry o=sun is a
subcontext of c=us.
If we imagine all the resources available for us as a collection of rooted trees, one context can be
viewed, in a first and raw approximation as a node in one of these trees. And it kind of makes sense,
194
15 - JNDI
because we can, to some extent, identify a web application with its root directory (a node in the file
system directory tree).
Many naming services are extended with a directory service. A directory service associates
names with objects and also allows such objects to have attributes. Thus, you not only can look up an
object by its name but also get the object's attributes or search for the object based on its attributes.
An example is the telephone company's directory service. It maps a subscriber's name to his
address and phone number. A computer's directory service is very much like a telephone company's
directory service in that both can be used to store information such as telephone numbers and
addresses. The computer's directory service is much more powerful, however, because it is available
online and can be used to store a variety of information that can be utilized by users, programs, and
even the computer itself and other computers.
A directory object represents an object in a computing environment. A directory object can be
used, for example, to represent a printer, a person, a computer, or a network. A directory object
contains attributes that describe the object that it represents.
15.3.1 attributes
A directory object can have attributes. For example, a printer might be represented by a directory
object that has as attributes its speed, resolution, and color. A user might be represented by a
directory object that has as attributes the user's e-mail address, various telephone numbers, postal
mail address, and computer account information.
An attribute has an attribute identifier and a set of attribute values. An attribute identifier is a token
that identifies an attribute independent of its values. For example, two different computer accounts
might have a "mail" attribute; "mail" is the attribute identifier. An attribute value is the contents of
the attribute. The email address, for example, might have an attribute identifier of "mail" and the
attribute value of "john.smith@somewhere.com".
195
15 - JNDI
Many examples of directory services are possible. The Novell Directory Service (NDS) is a directory
service from Novell that provides information about many networking services, such as the file and
print services. Network Information Service (NIS) is a directory service available on the Solaris
operating system for storing system-related information, such as that relating to machines, networks,
printers, and users. The SunONE Directory Server is a general-purpose directory service based on the
Internet standard LDAP.
Directory service is a vital component of network computing. By using a directory service, you can
simplify applications and their administration by centralizing the storage of shared information. As the
use of the Java programming language to write practical applications in a network environment
increases, the ability to access directory services will become essential.
196
15 - JNDI
The Java Naming and Directory Interface (JNDI) is an application programming interface (API) that
provides naming and directory functionality to applications written using the Java programming
language. It is defined to be independent of any specific directory service implementation. Thus a
variety of directories--new, emerging, and already deployed--can be accessed in a common way.
15.5.1 architecture
The JNDI architecture consists of an API and a service provider interface (SPI). Java applications
use the JNDI API to access a variety of naming and directory services. The SPI enables a variety of
naming and directory services to be plugged in transparently, thereby allowing the Java application
using the JNDI API to access their services.
15.5.2 packaging
The JNDI is included in the Java 2 SDK, v1.3 and later releases. It extends the v1.1 and v1.2
platforms to provide naming and directory functionality.
To use the JNDI, you must have the JNDI classes and one or more service providers. The Java 2
SDK, v1.3 includes three service providers for the following naming/directory services:
Lightweight Directory Access Protocol (LDAP)
Common Object Request Broker Architecture (CORBA) Common Object Services (COS)
name service
Java Remote Method Invocation (RMI) Registry
Other service providers can be downloaded from the JNDI Web site or obtained from other vendors.
When using the JNDI as a Standard Extension on the JDK 1.1 and Java 2 SDK, v1.2, you must first
download the JNDI classes and one or more service providers.
The JNDI is divided into five packages:
javax.naming
javax.naming.directory
javax.naming.event
javax.naming.ldap
javax.naming.spi
The javax.naming package contains classes and interfaces for accessing naming services.
15.6.1 context
The javax.naming package defines a Context interface, which is the core interface for looking
up, binding/unbinding, renaming objects and creating and destroying subcontexts.
The most commonly used operation is lookup(). You supply lookup() the name of the object
you want to look up, and it returns the object bound to that name. For example, the following code
fragment looks up a printer and sends a document to the printer object to be printed.
197
15 - JNDI
printer.print(report);
15.6.2 names
Every naming method in the Context interface has two overloads: one that accepts a Name
argument and one that accepts a java.lang.String name. Name is an interface that represents a
generic name-an ordered sequence of zero or more components. For the methods in the Context
interface, a Name argument that is an instance of CompositeName represents a composite name, so
you can name an object using a name that spans multiple namespaces. A Name argument of any
other type represents a compound name. The overloads that accept Name are useful for applications
that need to manipulate names, that is, composing them, comparing components, and so on.
A java.lang.String name argument represents a composite name. The overloads that accept
java.lang.String names are likely to be more useful for simple applications, such as those that
simply read in a name and look up the corresponding object.
15.6.3 bindings
listBindings() returns an enumeration of name-to-object bindings. Each binding is represented
by an instance of the Binding class. A binding is a tuple containing the name of the bound object, the
name of the object's class, and the object itself.
list() is similar to listBindings(), except that it returns an enumeration of NameClassPair.
NameClassPair contains an object's name and the name of the object's class. list() is useful for
applications such as browsers that want to discover information about the objects bound within a
context but that don't need all of the actual objects. Although listBindings() provides all of the
same information, it is potentially a much more expensive operation.
15.6.4 references
Objects are stored in naming and directory services in different ways. A service that supports storing
Java objects might support storing an object in its serialized form. However, some naming and
directory services do not support the storing of Java objects. Furthermore, for some objects in the
directory, Java programs are but one group of applications that access them. In this case, a serialized
Java object might not be the most appropriate representation. A reference might be a very compact
representation of an object, whereas its serialized form might contain a lot more state.
The JNDI defines the Reference class to represent a reference. A reference contains information
on how to construct a copy of the object. The JNDI will attempt to turn references looked up from the
directory into the Java objects that they represent so that JNDI clients have the illusion that what is
stored in the directory are Java objects.
15.6.6 exceptions
The JNDI defines a class hierarchy for exceptions that can be thrown in the course of performing
naming and directory operations. The root of this class hierarchy is NamingException. Programs
interested in dealing with a particular exception can catch the corresponding subclass of the
exception. Otherwise, they should catch NamingException.
198
15 - JNDI
15.7.2 searches
DirContext contains methods for performing content-based searching of the directory. In the
simplest and most common form of usage, the application specifies a set of attributes--possibly with
specific values--to match and submits this attribute set to the search() method. Other overloaded
forms of search() support more sophisticated search filters.
The javax.naming.event package contains classes and interfaces for supporting event
notification in naming and directory services.
Events
A NamingEvent represents an event that is generated by a naming/directory service. The event
contains a type that identifies the type of event. For example, event types are categorized into those
that affect the namespace, such as "object added," and those that do not, such as "object changed." A
NamingEvent also contains other information about the change, such as information about the object
before and after the change.
Listeners
A NamingListener is an object that listens for NamingEvents. Each category of event type has a
corresponding type of NamingListener. For example, a NamespaceChangeListener represents
a listener interested in namespace change events and an ObjectChangeListener represents a
listener interested in object change events.
To receive event notifications, a listener must be registered with either an EventContext or an
EventDirContext. Once registered, the listener will receive event notifications when the
corresponding changes occur in the naming/directory service.
The javax.naming.ldap package contains classes and interfaces for using features that are
199
15 - JNDI
specific to the LDAP v3 that are not already covered by the more generic
javax.naming.directory package. In fact, most JNDI applications that use the LDAP will find the
javax.naming.directory package sufficient and will not need to use the javax.naming.ldap
package at all. This package is primarily for those applications that need to use "extended" operations,
controls, or unsolicited notifications.
15.9.2 controls
The LDAP v3 allows any request or response to be augmented by yet-to-be defined modifiers,
called controls. A control sent with a request is a request control and a control sent with a response is
a response control. A control may be defined by a standards organization such as the IETF or by a
vendor. Request controls and response controls are not necessarily paired, that is, there need not be
a response control for each request control sent, and viceversa.
200
15 - JNDI
This example shows you how to write a program that looks up an object whose name is passed in
as a command-line argument. It uses a service provider for the file system. Therefore the name that
you supply to the program must be a filename. You do not need to understand details about the
service provider at this point.
// Look up an object
Object obj = ctx.lookup(name);
// Print it
System.out.println(name + " is bound to: " + obj);
201
15 - JNDI
} catch (NamingException e) {
System.err.println("Problem looking up " + name + ":" + e);
}
Or as follows:
# java Lookup \autoexec.bat
If you supply a file directory, then you will see something like the following.
# java Lookup /tmp
/tmp is bound to: com.sun.jndi.fscontext.RefFSContext@1dae083f
If the name that you supplied is a file, then you will see something like this:
/tmp/f is bound to: //tmp/f
This example shows you how to write a program that retrieves attributes from a directory object. It
uses an LDAP service provider to access an LDAP service.
202
15 - JNDI
Similar to the naming example, you indicate that you're using the LDAP service provider by setting
the Hashtable parameter to the InitialDirContext constructor appropriately. For now, the only
thing to understand is that the program by default identifies an LDAP server on the local machine. If
your LDAP server is located on another machine or is using another port, then you need to edit the
LDAP URL ("ldap://localhost:389/o=JNDITutorial") accordingly.
} catch (NamingException e) {
System.err.println("Problem getting attribute:" + e);
}
203
15 - JNDI
If the compilation succeeds, then the compiler creates a file named Getattr.class in the same
directory (folder) as the Java source file (Getattr.java). If the compilation fails, then make sure that
you typed in and named the program exactly as shown here, using the capitalization shown.
Recall that the program was configured with the following property.
env.put(Context.PROVIDER_URL,
"ldap://localhost:389/o=JNDITutorial");
With this configuration, this command queries the LDAP server on machine localhost that is
listening on port 389, serving the "o=JNDITutorial" namespace. It asks for the attributes of the
entry "cn=Ted Geisel, ou=People". Once it has the attributes, it extracts the surname attribute
("sn").
204
16 - JAVA MESSAGE SERVICE
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.
205
16 - JAVA MESSAGE SERVICE
In a J2EE application, JMS administered objects are normally placed in the jms naming subcontext.
206
16 - JAVA MESSAGE SERVICE
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.
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");
207
16 - JAVA MESSAGE SERVICE
Message m = consumer.receive();
connection.start();
Message m = consumer.receive(1000); // time out after a second
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.
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);
208
16 - JAVA MESSAGE SERVICE
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
}
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.
209
17 - ENTERPRISE 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. Entity beans have been
superseded by the Java Persistence API in EJB 3.0.
The 2.0 EJB specification adds another bean type:
message-driven beans
The current EJB specification is 3.2 and is the object of JSR 345, whose final release dates back to
May 2013. Novelties in the major 3.x specification try to make the development of EJBs easier. It
provides annotations for every type of metadata previously addressed by deployment descriptors, so
no XML descriptor is needed and beans deployment can be done just through a plain .jar file into the
application server.
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
210
17 - ENTERPRISE JAVA BEANS
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:
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
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:
package myBeans;
import.javax.ejb.*;
import java.rmi.RemoteException;
public interface MyBeanHome extends EJBHome
{
MyBeanObject create() throws CreateException,
RemoteException;
211
17 - ENTERPRISE JAVA BEANS
The remote interface of a bean is a standard Java interface that extends the EJBObject and
Remote interfaces 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:
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;
}
The client is able to create an EJB through an object implementing the EJBHome interface. 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.
authentication
212
17 - ENTERPRISE JAVA BEANS
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) through SSL.
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:
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);
}
for a client executing inside the container, the code may look like:
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:
To make sure that the client works with the underlying communication protocol, the client should
use the narrow() method of javax.rmi.PortableRemoteObject:
Why do we have to use the narrow() method? Usually, when we perform a lookup() on a Context
object, the method will return you an Object that needs to be casted to the home interface we've asked
for. Problem is, this cannot be done using the normal/explicit casting:
213
17 - ENTERPRISE JAVA BEANS
The reason has to do with CORBA. Why? For EJB, the communication between the server and the
client is based on RMI (both remote and local interfaces, in fact, do implements the java.rmi.Remote
interface).
The underlying protocol that it is used for the communication is IIOP (Internet Inter ORB Protocol),
that is part of CORBA standards. It is normally used to describe this communication system using the
Java RMI over IIOP.
IIOP has not been designed for Java, but for generic languages, and this means that there are
some limitations. Some languages, in fact, do not have the concept of casting. Java RMI-IIOP
provides a mechanism to narrow the the Object you have received from your lookup, to the
appropriate type. This is done through the javax.rmi.PortableRemoteObject class and, more
specifically, using the narrow() method.
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:
myObject.remove();
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, entity or message driven).
Assuming that our bean (called MyBean) is a session bean, the code implementing this class may
look like this:
package com.bank11.ccards.ejbeans;
import javax.ejb.SessionContext;
public class MyBean implements javax.ejb.SessionBean
{
public void processEntry(String firstName, String lastName, int
custId)
{
// method implementation
214
17 - ENTERPRISE JAVA BEANS
...
}
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 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
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>
215
17 - ENTERPRISE JAVA BEANS
<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>
<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>
216
17 - ENTERPRISE JAVA BEANS
</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>
217
18 - session beans
18 - 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.
There are 5 mandatory callbacks for classes implementing the SessionBean interface.
The first two methods will never be called for stateless session beans, because the container will
never activate a stateless session bean.
Figure 18.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.
218
18 - session beans
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 18.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.
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 18.2 illustrates the stages of a stateless
session bean.
219
19 - entity beans
19 - ENTITY BEANS
Entity beans represent actual data (usually, stored in a Database).
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>
220
19 - entity beans
Besides the CRUD callbacks which are discusses later in this section, an entity bean must
implement (although this implementation may be left empty) the following methods:
CRUD translates through Create, Read, Update and Delete. These methods are mandatory for
entity beans.
19.3 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.
19.4 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
221
19 - entity beans
19.5 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
19.6 delete
Figure 17.1 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.
222
19 - entity beans
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();
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.
223
20 - JAVA PERSISTENCE ENTITIES
Prior to the introduction of EJB 3.0 specification, many enterprise Java developers used lightweight
persistent objects, provided by either persistence frameworks (for example Hibernate) or data access
objects instead of entity beans. This is due to the fact that entity beans, in previous EJB specifications,
called for too much complicated code and heavy resource footprint, and they could be used only in
Java EE application servers because of interconnections and dependencies in the source code
between beans and DAO objects or persistence framework.
Thus, many of the features originally presented in third-party persistence frameworks were
incorporated into the Java Persistence API, and, as of 2006, projects like Hibernate (version 3.2) and
TopLink Essentials have become themselves implementations of the Java Persistence API
specification.
There are four main areas which are covered beneath the generic term of Java persistence:
1. Java persistence Entities
2. The Java Persistence API.
3. The Java Persistence Query Language
4. The Java Persistence Criteria API
An entity is a lightweight Java class. Typically, an entity represents a table in a relational database,
and each entity instance corresponds to a row in that table. The primary programming artifact of an
entity is the entity class, although entities can use helper classes.
Entities typically have relationships with other entities, and these relationships are expressed
through object/relational metadata.
The persistent state of an entity is represented through either persistent fields or persistent
properties. These fields or properties use object/relational mapping annotations to map the entities
and entity relationships to the relational data in the underlying data store.
The Java Persistence API (JPA) is a Java programming language application programming
interface specification that describes the management of relational data in applications using Java
Platform, Standard Edition and Java Platform, Enterprise Edition.
The Java Persistence API originated as part of the work of the JSR 220 Expert Group of the Java
Community Process. The final release of the JPA 1.0 specification dates back to May 2006.
JPA 2.0 was the work of the JSR 317 Expert Group and was released in Dec. 2009. The current
specification is JPA 2.1 and was released in April 2013 as JSR 338.
224
20 - JAVA PERSISTENCE ENTITIES
The Java Persistence API was developed in part to unify the Java Data Objects API, and the EJB
2.0 Container Managed Persistence (CMP) API. As of 2009 most products supporting each of those
APIs support the Java Persistence API.
The Java Persistence API specifies persistence only for relational database management systems.
That is, JPA focuses onobject-relational mapping (ORM) (note that there are JPA providers who
support other database models besides relational database, but this is outside the scope of what JPA
was designed for). Refer to JPA 2 spec section 1 introduction for clarification of the role of JPA, which
states very clearly "The technical objective of this work is to provide an object/relational mapping
facility for the Java application developer using a Java domain model to manage a relational
database."
The Java Data Objects specification supports ORM, as well as persistence to other types of
database models, for example flat file databases and NoSQL databases, including document
databases, graph databases, as well as literally any other conceivable datastore.
225
20 - JAVA PERSISTENCE ENTITIES
226
20 - JAVA PERSISTENCE ENTITIES
The properties of the primary key class must be public or protected if property-based access
is used.
The class must have a public default constructor.
The class must implement the hashCode() and equals(Object other) methods.
The class must be serializable.
A composite primary key must be represented and mapped to multiple fields or properties of
the entity class or must be represented and mapped as an embeddable class.
If the class is mapped to multiple fields or properties of the entity class, the names and types
of the primary key fields or properties in the primary key class must match those of the entity
class.
The following primary key class is a composite key, and the orderId and itemId fields together
uniquely identify an entity:
public LineItemKey() {}
227
20 - JAVA PERSISTENCE ENTITIES
228
20 - JAVA PERSISTENCE ENTITIES
@PersistenceContext
EntityManager em;
@PersistenceUnit
EntityManagerFactory emf;
EntityManager em = emf.createEntityManager();
Application-managed entity managers dont automatically propagate the JTA transaction context.
Such applications need to manually gain access to the JTA transaction manager and add transaction
demarcation information when performing entity operations. The
javax.transaction.UserTransaction interface defines methods to begin, commit, and roll
back transactions. Inject an instance of UserTransaction by creating an instance variable
annotated with @Resource:
@Resource
229
20 - JAVA PERSISTENCE ENTITIES
UserTransaction utx;
To begin a transaction, call the UserTransaction.begin method. When all the entity operations are
complete, call the UserTransaction.commit method to commit the transaction. The
UserTransaction.rollback method is used to roll back the current transaction.
The following example shows how to manage transactions in an application that uses an
application-managed entity manager:
@PersistenceContext
EntityManagerFactory emf;
EntityManager em;
@Resource
UserTransaction utx;
...
em = emf.createEntityManager();
try {
utx.begin();
em.persist(SomeEntity);
em.merge(AnotherEntity);
em.remove(ThirdEntity);
utx.commit();
} catch (Exception e) {
utx.rollback();
}
@PersistenceContext
EntityManager em;
public void enterOrder(int custID, Order newOrder) {
Customer cust = em.find(Customer.class, custID);
cust.getOrders().add(newOrder);
newOrder.setCustomer(cust);
}
230
20 - JAVA PERSISTENCE ENTITIES
The Java Persistence API provides the following methods for querying entities.
The Java Persistence query language (JPQL) is a simple, string-based language similar to
SQL used to query entities and their relationships.
The Criteria API is used to create typesafe queries using Java programming language APIs to
query for entities and their relationships.
Both JPQL and the Criteria API have advantages and disadvantages.
Just a few lines long, JPQL queries are typically more concise and more readable than Criteria
queries. Developers familiar with SQL will find it easy to learn the syntax of JPQL. JPQL named
queries can be defined in the entity class using a Java programming language annotation or in the
applications deployment descriptor. JPQL queries are not typesafe, however, and require a cast when
retrieving the query result from the entity manager. This means that type-casting errors may not be
caught at compile time. JPQL queries dont support open-ended parameters.
Criteria queries allow you to define the query in the business tier of the application. Although this is
also possible using JPQL dynamic queries, Criteria queries provide better performance because JPQL
dynamic queries must be parsed each time they are called. Criteria queries are typesafe and therefore
dont require casting, as JPQL queries do. The Criteria API is just another Java programming
language API and doesnt require developers to learn the syntax of another query language. Criteria
queries are typically more verbose than JPQL queries and require the developer to create several
objects and perform operations on those objects before submitting the query to the entity manager.
20.8 an example
231
21 - message-driven beans
21 - MESSAGE-DRIVEN BEANS
21.1 what are the 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.
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.
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.
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
232
21 - 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 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.
When a JMS Queue or Topic receives a message, 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.
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.
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
// include an application exception. onMessage() must not be
233
21 - message-driven beans
The EJB 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 the EJB
container 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).
The message-driven bean's onMessage() method performs all of the business logic for the EJB.
The EJB container 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().
234
21 - message-driven beans
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.
As with other EJB types, message-driven beans can demarcate transaction boundaries either on
their own (using bean-managed transactions), or by having the The EJB container 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. The EJB container 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 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>
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, the EJB container
includes the message receipt as part of the bean's transaction only if the bean's transaction attribute is
set to Required.
For message-driven beans that use container-managed transaction demarcation, the EJB container
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. The EJB container automatically acknowledges messages for EJBs with
bean-managed transactions, but the deployer can configure acknowledgment semantics using the
jms-acknowledge-mode deployment parameter.
235
21 - message-driven beans
To deploy a message-driven bean on the EJB container, you edit the XML file to create the
deployment descriptors that associate the EJB with a configured JMS destination.
The deployment descriptor for a message-driven bean also specifies:
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
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 may have two 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
the EJB container.
Figure 15.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.
236
21 - message-driven beans
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.
237