Bauke Scholtz, Arjan Tijms The Definitive Guide To JSF In Java EE 8 Apress (2018)

User Manual:

Open the PDF directly: View PDF PDF.
Page Count: 516

DownloadBauke Scholtz, Arjan Tijms - The Definitive Guide To JSF In Java EE 8-Apress (2018)
Open PDF In BrowserView PDF
The Definitive
Guide to JSF in
Java EE 8
Building Web Applications with
JavaServer Faces
—
Bauke Scholtz
Arjan Tijms

The Definitive Guide to
JSF in Java EE 8
Building Web Applications with
JavaServer Faces

Bauke Scholtz
Arjan Tijms

The Definitive Guide to JSF in Java EE 8: Building Web Applications with
JavaServer Faces
Bauke Scholtz
Willemstad, Curaçao
ISBN-13 (pbk): 978-1-4842-3386-3			
https://doi.org/10.1007/978-1-4842-3387-0

Arjan Tijms
Amsterdam, Noord-Holland, The Netherlands
ISBN-13 (electronic): 978-1-4842-3387-0

Library of Congress Control Number: 2018942178

Copyright © 2018 by Bauke Scholtz, Arjan Tijms
This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the
material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation,
broadcasting, reproduction on microfilms or in any other physical way, and transmission or information
storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now
known or hereafter developed.
Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with
every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an
editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the
trademark.
The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not
identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to
proprietary rights.
While the advice and information in this book are believed to be true and accurate at the date of publication,
neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or
omissions that may be made. The publisher makes no warranty, express or implied, with respect to the
material contained herein.
Managing Director, Apress Media LLC: Welmoed Spahr
Acquisitions Editor: Steve Anglin
Development Editor: Matthew Moodie
Coordinating Editor: Mark Powers
Cover designed by eStudioCalamar
Cover image designed by Freepik (www.freepik.com)
Distributed to the book trade worldwide by Springer Science+Business Media New York, 233 Spring Street,
6th Floor, New York, NY 10013. Phone 1-800-SPRINGER, fax (201) 348-4505, e-mail orders-ny@springersbm.com, or visit www.springeronline.com. Apress Media, LLC is a California LLC and the sole member
(owner) is Springer Science + Business Media Finance Inc (SSBM Finance Inc). SSBM Finance Inc is a
Delaware corporation.
For information on translations, please e-mail editorial@apress.com; for reprint, paperback, or audio rights,
please email bookpermissions@springernature.com.
Apress titles may be purchased in bulk for academic, corporate, or promotional use. eBook versions and
licenses are also available for most titles. For more information, reference our Print and eBook Bulk Sales
web page at http://www.apress.com/bulk-sales.
Any source code or other supplementary material referenced by the author in this book is available to
readers on GitHub via the book’s product page, located at www.apress.com/9781484233863. For more
detailed information, please visit http://www.apress.com/source-code.
Printed on acid-free paper

To caffeine and our (not so) patient wives.

Table of Contents
About the Authors�������������������������������������������������������������������������������������������������� xiii
About the Technical Reviewer���������������������������������������������������������������������������������xv
Chapter 1: History����������������������������������������������������������������������������������������������������� 1
In the Beginning . . .���������������������������������������������������������������������������������������������������������������������� 1
The Adolescent Years�������������������������������������������������������������������������������������������������������������������� 4
On to Maturity������������������������������������������������������������������������������������������������������������������������������� 7
Rejuvenation������������������������������������������������������������������������������������������������������������������������������� 11

Chapter 2: From Zero to Hello World���������������������������������������������������������������������� 13
Installing Java SE JDK���������������������������������������������������������������������������������������������������������������� 13
What About Java EE?������������������������������������������������������������������������������������������������������������� 13
Installing Payara������������������������������������������������������������������������������������������������������������������������� 14
How About Other Servers?���������������������������������������������������������������������������������������������������� 14
Installing Eclipse������������������������������������������������������������������������������������������������������������������������� 15
Configuring Eclipse���������������������������������������������������������������������������������������������������������������� 16
Installing JBoss Tools Plug-in������������������������������������������������������������������������������������������������ 17
Integrating New Server in Eclipse����������������������������������������������������������������������������������������� 19
Creating New Project in Eclipse�������������������������������������������������������������������������������������������������� 22
Creating the Backing Bean Class������������������������������������������������������������������������������������������ 35
Creating the Facelets File������������������������������������������������������������������������������������������������������ 38
Deploying the Project������������������������������������������������������������������������������������������������������������ 41
Installing H2�������������������������������������������������������������������������������������������������������������������������������� 46
Configuring DataSource�������������������������������������������������������������������������������������������������������� 46
Configuring JPA��������������������������������������������������������������������������������������������������������������������� 47

v

Table of Contents

Creating the JPA Entity���������������������������������������������������������������������������������������������������������� 48
Creating the EJB Service������������������������������������������������������������������������������������������������������� 50
Adjusting the Hello World������������������������������������������������������������������������������������������������������ 52

Chapter 3: Components������������������������������������������������������������������������������������������ 55
Standard HTML Components������������������������������������������������������������������������������������������������������ 58
Standard Core Tags��������������������������������������������������������������������������������������������������������������������� 62
Life Cycle������������������������������������������������������������������������������������������������������������������������������������ 65
Restore View Phase (First Phase)������������������������������������������������������������������������������������������ 66
Apply Request Values Phase (Second Phase)������������������������������������������������������������������������ 66
Process Validations Phase (Third Phase)������������������������������������������������������������������������������� 67
Update Model Values Phase (Fourth Phase)�������������������������������������������������������������������������� 68
Invoke Application Phase (Fifth Phase)���������������������������������������������������������������������������������� 68
Render Response Phase (Sixth Phase)���������������������������������������������������������������������������������� 68
Ajax Life Cycle����������������������������������������������������������������������������������������������������������������������������� 69
View Build Time�������������������������������������������������������������������������������������������������������������������������� 70
View Render Time����������������������������������������������������������������������������������������������������������������������� 71
View State����������������������������������������������������������������������������������������������������������������������������������� 72
View Scope��������������������������������������������������������������������������������������������������������������������������������� 74
Phase Events������������������������������������������������������������������������������������������������������������������������������� 75
Component System Events��������������������������������������������������������������������������������������������������������� 76
Custom Component System Events�������������������������������������������������������������������������������������������� 82
JSTL Core Tags���������������������������������������������������������������������������������������������������������������������������� 83
Manipulating the Component Tree���������������������������������������������������������������������������������������������� 89

Chapter 4: Form Components��������������������������������������������������������������������������������� 95
Input, Select, and Command Components���������������������������������������������������������������������������������� 95
Text-Based Input Components���������������������������������������������������������������������������������������������������� 96
File-Based Input Component����������������������������������������������������������������������������������������������������� 103
Selection Components�������������������������������������������������������������������������������������������������������������� 105
SelectItem Tags������������������������������������������������������������������������������������������������������������������������� 114
SelectItemGroup����������������������������������������������������������������������������������������������������������������������� 118
vi

Table of Contents

Label and Message Components���������������������������������������������������������������������������������������������� 120
Command Components������������������������������������������������������������������������������������������������������������� 123
Navigation��������������������������������������������������������������������������������������������������������������������������������� 133
Ajaxifying Components������������������������������������������������������������������������������������������������������������� 136
Navigation in Ajax��������������������������������������������������������������������������������������������������������������������� 143
GET forms��������������������������������������������������������������������������������������������������������������������������������� 144
Stateless Forms������������������������������������������������������������������������������������������������������������������������ 147

Chapter 5: Conversion and Validation������������������������������������������������������������������ 149
Standard Converters����������������������������������������������������������������������������������������������������������������� 150
������������������������������������������������������������������������������������������������������������� 153
���������������������������������������������������������������������������������������������������������� 156
Standard Validators������������������������������������������������������������������������������������������������������������������� 160
/������������������������������������������������������������� 162
/������������������������������������������������������������������������������� 163
���������������������������������������������������������������������������������������������������������� 164
/�������������������������������������������������������������������������� 165
Immediate Attribute������������������������������������������������������������������������������������������������������������������ 171
Custom Converters�������������������������������������������������������������������������������������������������������������������� 172
Custom Validators��������������������������������������������������������������������������������������������������������������������� 183
Custom Constraints������������������������������������������������������������������������������������������������������������������� 186
Custom Messages��������������������������������������������������������������������������������������������������������������������� 187

Chapter 6: Output Components����������������������������������������������������������������������������� 191
Document-Based Output Components�������������������������������������������������������������������������������������� 191
Text-Based Output Components����������������������������������������������������������������������������������������������� 193
Navigation-Based Output Components������������������������������������������������������������������������������������� 198
Panel-Based Output Components��������������������������������������������������������������������������������������������� 199
Data Iteration Component��������������������������������������������������������������������������������������������������������� 204
Editable ������������������������������������������������������������������������������������������������������� 210
Add/Remove Rows in ���������������������������������������������������������������������������������� 215

vii

Table of Contents

Select Rows in �������������������������������������������������������������������������������������������� 218
Dynamic Columns in ����������������������������������������������������������������������������������� 220
Resource Components�������������������������������������������������������������������������������������������������������������� 221
Pass-Through Elements������������������������������������������������������������������������������������������������������������ 230

Chapter 7: Facelets Templating���������������������������������������������������������������������������� 235
XHTML��������������������������������������������������������������������������������������������������������������������������������������� 237
Template Compositions������������������������������������������������������������������������������������������������������������� 238
Single Page Application������������������������������������������������������������������������������������������������������������ 242
Template Decorations��������������������������������������������������������������������������������������������������������������� 246
Tag Files������������������������������������������������������������������������������������������������������������������������������������ 248
Composite Components������������������������������������������������������������������������������������������������������������ 256
Recursive Composite Component���������������������������������������������������������������������������������������� 266
Implicit EL Objects�������������������������������������������������������������������������������������������������������������������� 270

Chapter 8: Backing Beans������������������������������������������������������������������������������������ 275
Model, View, or Controller?������������������������������������������������������������������������������������������������������� 275
Managed Beans������������������������������������������������������������������������������������������������������������������������ 279
Scopes�������������������������������������������������������������������������������������������������������������������������������������� 281
@ApplicationScoped����������������������������������������������������������������������������������������������������������� 282
@SessionScoped����������������������������������������������������������������������������������������������������������������� 284
@ConversationScoped�������������������������������������������������������������������������������������������������������� 286
@FlowScoped���������������������������������������������������������������������������������������������������������������������� 289
@ViewScoped��������������������������������������������������������������������������������������������������������������������� 293
@RequestScoped���������������������������������������������������������������������������������������������������������������� 300
@Dependent������������������������������������������������������������������������������������������������������������������������ 303
Which scope to choose?����������������������������������������������������������������������������������������������������������� 304
Where Is @FlashScoped?��������������������������������������������������������������������������������������������������������� 305
Managed bean initialization and destruction���������������������������������������������������������������������������� 308
Injecting JSF vended types������������������������������������������������������������������������������������������������������� 309
Eager Initialization�������������������������������������������������������������������������������������������������������������������� 311

viii

Table of Contents

Layers��������������������������������������������������������������������������������������������������������������������������������������� 314
Naming Conventions����������������������������������������������������������������������������������������������������������������� 316

Chapter 9: Exception Handling����������������������������������������������������������������������������� 319
Custom Error Pages������������������������������������������������������������������������������������������������������������������ 320
Ajax Exception Handling����������������������������������������������������������������������������������������������������������� 322
ViewExpiredException Handling������������������������������������������������������������������������������������������������ 328
IOException Handling���������������������������������������������������������������������������������������������������������������� 332
EJBException Handling������������������������������������������������������������������������������������������������������������� 333

Chapter 10: WebSocket Push�������������������������������������������������������������������������������� 341
Configuration���������������������������������������������������������������������������������������������������������������������������� 341
Usage���������������������������������������������������������������������������������������������������������������������������������������� 343
Scopes and Users��������������������������������������������������������������������������������������������������������������������� 344
Channel Design Hints���������������������������������������������������������������������������������������������������������������� 346
One-Time Push�������������������������������������������������������������������������������������������������������������������������� 347
Stateful UI Updates������������������������������������������������������������������������������������������������������������������� 349
Site-Wide Push Notifications���������������������������������������������������������������������������������������������������� 351
Keeping Track of Active Sockets����������������������������������������������������������������������������������������������� 353
Detecting Session and View Expiration������������������������������������������������������������������������������������� 355
Breaking Down Mojarra’s f:websocket Implementation����������������������������������������������������������� 356

Chapter 11: Custom Components������������������������������������������������������������������������� 359
Component Type, Family, and Renderer Type���������������������������������������������������������������������������� 359
Creating New Component and Renderer����������������������������������������������������������������������������������� 367
Extending Existing Component������������������������������������������������������������������������������������������������� 375
Extending Existing Renderer����������������������������������������������������������������������������������������������������� 381
Custom Tag Handlers���������������������������������������������������������������������������������������������������������������� 385
Packaging in a Distributable JAR���������������������������������������������������������������������������������������������� 389
Resource Dependencies����������������������������������������������������������������������������������������������������������� 392

ix

Table of Contents

Chapter 12: Search Expressions��������������������������������������������������������������������������� 393
Relative Local IDs���������������������������������������������������������������������������������������������������������������������� 394
Absolute Hierarchical IDs���������������������������������������������������������������������������������������������������������� 396
Standard Search Keywords������������������������������������������������������������������������������������������������������� 400
Custom Search Keywords��������������������������������������������������������������������������������������������������������� 403

Chapter 13: Security��������������������������������������������������������������������������������������������� 409
Java EE Security Overview and History������������������������������������������������������������������������������������ 409
Protect Access to Resources���������������������������������������������������������������������������������������������������� 411
Excluded������������������������������������������������������������������������������������������������������������������������������ 412
Unchecked��������������������������������������������������������������������������������������������������������������������������� 413
By Role�������������������������������������������������������������������������������������������������������������������������������� 413
Setting the Authentication Mechanism������������������������������������������������������������������������������������� 415
Setting the Identity Store���������������������������������������������������������������������������������������������������������� 417
Providing Our Custom JSF Code����������������������������������������������������������������������������������������������� 422
Caller-Initiated Authentication��������������������������������������������������������������������������������������������������� 428
Remember Me�������������������������������������������������������������������������������������������������������������������������� 431
Activating Remember-Me Service��������������������������������������������������������������������������������������� 433
Logging Out������������������������������������������������������������������������������������������������������������������������������� 436
Custom Principals��������������������������������������������������������������������������������������������������������������������� 437
Conditionally Rendering Based on Access�������������������������������������������������������������������������������� 439
Cross-Site Request Forgery Protection������������������������������������������������������������������������������������� 444
Web Parameter Tampering Protection�������������������������������������������������������������������������������������� 448
Cross-Site Scripting Protection������������������������������������������������������������������������������������������������� 450
Source Exposure Protection������������������������������������������������������������������������������������������������������ 453

Chapter 14: Localization��������������������������������������������������������������������������������������� 459
Hello World, Olá mundo, नमस्ते दनु िया������������������������������������������������������������������������������������ 459
Configuration���������������������������������������������������������������������������������������������������������������������������� 461
Referencing Bundle in JSF Page����������������������������������������������������������������������������������������������� 461
Changing the Active Locale������������������������������������������������������������������������������������������������������� 463
Organizing Bundle Keys������������������������������������������������������������������������������������������������������������ 467
x

Table of Contents

Localizing Conversion/Validation Messages����������������������������������������������������������������������������� 471
Obtaining Localized Message in a Custom Converter/Validator����������������������������������������������� 472
Localizing Enums���������������������������������������������������������������������������������������������������������������������� 474
Parameterized Resource Bundle Values����������������������������������������������������������������������������������� 475
Database-Based ResourceBundle��������������������������������������������������������������������������������������������� 475
HTML in ResourceBundle���������������������������������������������������������������������������������������������������������� 480

Chapter 15: Extensions����������������������������������������������������������������������������������������� 481
Extension Types������������������������������������������������������������������������������������������������������������������������ 481
Extending CDI Artifacts������������������������������������������������������������������������������������������������������������� 482
Extending Classical Artifacts����������������������������������������������������������������������������������������������������� 485
Plug-ins������������������������������������������������������������������������������������������������������������������������������������� 488
Dynamic Extensions������������������������������������������������������������������������������������������������������������������ 492
Application Configuration Populator������������������������������������������������������������������������������������ 492
The Application Main Class������������������������������������������������������������������������������������������������� 493
Local Extension and Wrapping�������������������������������������������������������������������������������������������������� 496
Introspection����������������������������������������������������������������������������������������������������������������������������� 498

Index��������������������������������������������������������������������������������������������������������������������� 501

xi

About the Authors
Bauke Scholtz is an Oracle Java Champion, a member
of the JSF 2.3 Expert Group, and the main creator of the
JSF helper library OmniFaces. On the Internet, he is more
commonly known as BalusC, who is among the top users
and contributors on Stack Overflow. Bauke has integrated
several OmniFaces solutions into JSF 2.3. He is a web
application specialist and consults or has consulted for
Mercury1 Limited, MyTutor, Nava Finance, LinkPizza, ZEEF,
M4N/Zanox, ITCA, RDC, and more clients from fintech,
affiliate marketing, social media, and more as part of his 17
years of experience. This book offers Bauke the opportunity
to go into depth to answer most frequently asked questions and correctly solve most
commonly encountered problems while using JSF.
Arjan Tijms works for Payara Services Ltd and is a JSF (JSR
372) and Security API (JSR 375) Expert Group member. He
is the co-creator of the popular OmniFaces library for JSF,
which was a 2015 Duke’s Choice Award winner, and is the
main creator of a set of tests for the Java EE authentication SPI
(JASPIC) used by various Java EE vendors. Arjan holds an MSc
degree in Computer Science from the University of Leiden,
The Netherlands. Writing about this topic was a natural
choice for Arjan; He has already written much about it on his
blog and wanted to expand that by contributing to a book.

xiii

About the Technical Reviewer
Chád (“Shod”) Darby is an author, instructor, and speaker
in the Java development world. As a recognized authority
on Java applications and architectures, he has presented
technical sessions at software development conferences
worldwide (in the United States, UK, India, Russia, and
Australia). In his 15 years as a professional software architect,
he’s had the opportunity to work for Blue Cross/Blue Shield,
Merck, Boeing, Red Hat, and a handful of startup companies.
Chád is a contributing author to several Java books,
including Professional Java E-Commerce (Wrox Press),
Beginning Java Networking (Wrox Press), and XML and
Web Services Unleashed (Sams Publishing). Chád has Java certifications from Sun
Microsystems and IBM. He holds a BS in computer science from Carnegie Mellon
University. You can visit Chád’s blog at www.luv2code.com to view his free video tutorials
on Java. You can also follow him on Twitter at ­@darbyluvs2code.

xv

CHAPTER 1

History
This chapter describes the history of JSF, starting from its early conception and ending
where we are today at the moment of writing. We’ll discuss how the JSF API (application
programming interface) itself evolved, which important events took place during that
evolution, and who some of the people were that were involved in all of this.
This is in no way a complete description of the history and the reader should
take notice of the fact that many more events took place and many more people were
involved than we were able to mention here.

In the Beginning . . .
JSF goes back a long time. Its initial JSR, JSR 127, started in 2001. At that time the
Struts web framework was wildly popular, although it wasn’t that long ago that it was
released itself (around 2000). Despite Struts’ popularity, a large number of other web
frameworks were in use in the Java space, and new ones were popping up all the time.
JavaServer Faces (JSF) was conceived as an attempt to bring a standardized MVC
(model-view-controller) web framework base into the overall Java EE platform.
Controversies are quite common in the web framework space, and JSF is no
exception here. Right at the start of its inception there was a big controversy where
Apache opposed the creation of JSF on the bases that Apache Struts already existed and
a closed source alternative would have little value. Apache therefore voted against the
creation of JSF with the following comment:

This JSR conflicts with the Apache open source project Struts. Considering
Sun’s current position that JSRs may not be independently implemented
under an open source license, we see little value in recreating a technology
in a closed environment that is already available in an open environment.

© Bauke Scholtz, Arjan Tijms 2018
B. Scholtz and A. Tijms, The Definitive Guide to JSF in Java EE 8, https://doi.org/10.1007/978-1-4842-3387-0_1

1

Chapter 1

History

To the extent that this JSR extends beyond Struts today, we would encourage
the Sun developers proposing this JSR to join the Sun developers already
leading Struts to create an open solution at Apache, something which when
finished would be assured of being able to be implemented as open source.
Eventually the conflict was resolved when after about a year into the process spec
lead Amy Fowler (from Swing fame) was replaced by Craig McClanahan, the very
father of the Struts project that JSF was said to be competing with. The open source
restriction was lifted as well, and the open source JSF implementation, called MyFaces,
was developed in parallel with the (then nameless) RI and hence the specification itself.
MyFaces initially started as an LGPL licensed project at sourceforge.net in December
2002 and had an initial 0.1 release conforming to what was then called an “Early Access
Specification” in January 2003.
Open source implementations are the most common implementations in Java
EE 8, and there’s barely any EE specification at the time of this writing (2018) that’s still
implemented as closed source. In 2001, however, this was not just uncommon; it was
actually not allowed for new JSRs. Allowing for an open source implementation was
therefore quite a change, and the honor fell to JSF to be the first of its kind for which this
was allowed.
Despite the open source implementation being allowed, the actual development of
the spec was still done in secret and behind closed doors. There was no public mailing
list, and no tracker (e.g., a JIRA instance) for the public to create issues or express wishes.
Occasionally interviews were being done, and in the fall of 2002 by then former spec lead
Amy Fowler did reveal quite a few details about JSF, but largely the project was shrouded
in mystery for the general public.
The team behind JSF was, however, hard at work. The first e-mail to the internal
JSR-127 list was sent on August 17, 2001. As with most projects, the team spent the initial
months on gathering requirements and looking at the existing competing products. A
package name was chosen as well. The initial placeholder package, which was "javax.
servlet.ui", now "javax.faces", was chosen as the package to use. The very first
technical architecture to be considered was the component model. For a component-­
based MVC framework this is obviously one of the most important aspects. During the
last month of 2001 and the first two months of 2002 the team looked at what is now known
as the Managed Bean (called “Object Manager” then). Managed beans with their scopes,
names, and dependency injection are clearly another cornerstone of the JSF framework.
Events and the model behind it were being looked at as well during that time frame.
2

Chapter 1

History

In the second quarter of 2002 two other cornerstones of JSF were discussed: the
Expression Language (inspired by JSTL), which is instrumental for the so-called bindings
of beans from a template to backing code, and the factory finder, which allowed key
parts of JSF to be replaced and although perhaps not fully realized at the time may have
contributed greatly to JSF still being relevant some 16 years later.
It was in this same quarter that Craig McClanahan took over as spec lead, father of
Struts and architect of Tomcat’s Servlet container, took over. Not long after the discussion
about using JSP started, a discussion, perhaps unbeknownst to the team at the time, that
would, unfortunately, have a rather negative impact on JSF later on. Around the end
of the year 2002, Ed Burns, who like McClanahan had also worked on Tomcat before,
joined the team as co-spec lead. Burns is the person who would eventually become the
main spec lead of JSF for well over a decade.
While the team continued to work on things like the aforementioned managed
beans and the so-called value binding, which is the Java representation of the also
aforementioned expression language binding, the first dark cloud appeared when in the
spring of 2003 team member Hans Bergsten realized that there were very real and major
issues with using JSP as the templating language for JSF. He brought these concerns to
the team, but ultimately they weren’t addressed and instead the following months were
spent, among other things, on a variant of the value binding; it later on became clear that
the method binding and the state saving mechanism were another of JSF’s less than ideal
implementations.
JSF 1.0 and its still nameless RI were eventually released on March 11, 2004—
coincidentally, a mere two weeks before the release of another framework that’s still
strong today, Spring 1.0. MyFaces released its 1.0.0 alpha version only days later, on
March 19. It’s perhaps an interesting observation that JSF went final with a full-fledged
XML-based dependency injection (DI) framework just before Spring, which is largely
known for its DI, went final.
JSF 1.0 was generally well received; despite a rather crowded market with
competitors such as Tapestry, WebObjects, Velocity, and Cocoon operating, not less than
three books from writers such as Horst Caymann and Hans Bergsten appeared in the
months after, and the eXo platform (a Digital Collaboration Platform) started using JSF
right away.
Hans Bergsten’s earlier concerns, however, become painfully clear almost just
as quickly; the JSP technology is based on processing a template from start to end,
immediately writing to the response as tags are encountered. JSF, however, requires
a phased approach where components need to be able to inspect and act on the
3

Chapter 1

History

component tree, which is built from the tags on the page, before starting to write
anything to the response. This mismatch led to many strange issues, such as content
disappearing or being rendered out of order.
Only three months after the introduction of JSF, Hans Bergsten made a strong case
of dropping JSP in his legendary article “Improving JSF by Dumping JSP.” There Bergsten
explains how ill-suited JSP is for use a template language in JSF, but he also presents
a glimmer of hope; because of JSF’s great support for extendibility, it’s relatively easy
to introduce alternative templating simply by replacing the so-called view handler,
something which JSF explicitly allows. It would, however, take five long years until JSF
would indeed ship with a more suitable view templating language, and even though JSP
had been essentially deprecated at that point it’s still present in JSF at the time of writing.

The Adolescent Years
Back in 2004 another first befell JSF; on June 28 Ed Burns announced that the source
of the RI was released by Sun. This represented a major milestone as before that date
most technology in active use by Sun was closed source. Initially the source was licensed
under the somewhat exotic JRL, but later this would be changed to dual licenses, GPL
with classpath exception and CDDL. At the same time as this announcement, the
tradition was established that every new feature or bug fix should be accompanied by a
test, and that all existing tests should be executed before committing the change. Some
14 years later there’s a largely different set of people working on the RI source, and
the project structure and code conventions have changed as well, but the test-driven
tradition is still being uphold in its original form.
At that point Ed Burns decided to focus more on the specification aspects of JSF as
the JSF 1.2 spec work had started right away, and Jayashri Visvanathan, one of the early
team members, took on the lead role concerning the implementation aspects, with Ryan
Lubke, working as the TCK (testing) engineer.
Still only a few months old, a variety of component libraries for JSF had already
started to pop up, although all of them commercial. Among those was the one from
Oracle, ADF Faces. ADF Faces was put on Oracle’s roadmap well before JSF 1.0 went final,
and the first early access release was presented on August 17, 2004. Its lead was Adam
Winer, who represented Oracle in the team that created JSF 1.0. ADF Faces primarily
contained a set of rich components, but also a dialog framework, and remarkably
already featured partial page rendering (PPR), quite a bit ahead of the later crop of AJAX
4

Chapter 1

History

solutions. ADF Faces also contained a “for each” tag (af:forEach) that actually worked.
Adam Winer explained in these early days that such tag is not quite trivial to build but
promised that Oracle would contribute the knowledge back to JSF itself.
The ADF Faces components originated mostly from the earlier User Interface XML
(UIX) framework, of which Adam Winer was the lead architect as well. Earlier versions
of UIX used the names “Cabo,” “Baja,” and “Marlin.” UIX was a rich client framework
for use in the browser. With JSF sharing more than a few similarities to UIX, and with its
lead, Adam Winer, being part of the original JSF team, it’s perhaps not unreasonable to
surmise that UIX influenced JSF. Such similarities include the concept of components
with separate renderers, JSP tag handlers and declarative options to compose a page,
and the ability to instantiate those same components programmatically in Java. There
was even a conceptually similar data binding, although with a less elegant syntax.
Instead of, say, value="#{user.age}", UIX would use data:value="age@user" but also
required a kind of producer to be defined on each page to declare where “user” comes
from, and then nest the page’s content within that declaration. By contrast, JSF and EL
have always used global definitions and left it up to the user to avoid name clashes.
One of the first, if not the first open source component library in 2004 was
Matthias Unverzagt’s OurFaces. As JSF did not had its own resource API (application
programming interface) at the time to serve up things like images, OurFaces required a
Servlet to be added to web.xml, the so-called SkinServlet (ourfaces.common.webapp.
SkinServlet). The significance of this is that it became a rather common thing for JSF
libraries in those days to ask their users: add something manually to web.xml before the
component library can be used.
Most of the last months of 2004 and early months of 2005 were spent by the
JSF 1.2 expert group (EG) working on various JSP and EL issues, such as the JSTL
 support and the generation of IDs in JSP, as well as on the dreaded “content
interweaving” issue, which refers to the aforementioned content that appears at wrong
places in the response when rendering.
While OurFaces may have been one of the first component libraries, it didn’t last
and few will remember it or have even heard about it today. This is not quite the same
for another framework that has its roots in early 2005, namely, Alexander Smirnov’s
Telamon framework, later renamed Ajax4jsf. This framework was one of the first of its
kind that combined JSF and the then new and fresh AJAX technology. The beauty of
Ajax4Jsf was that it could add AJAX support to existing components, which weren’t built
with AJAX support in mind at all by enclosing them among others in the 
5

Chapter 1

History

tag. This technology was incorporated in the Exadel Visual Component Platform, which
was released in March 2006 and would later be renamed RichFaces, and would become
one of the most memorable JSF component libraries.
At around the same time Alexander Smirnov started work on what eventually would
become RichFaces, a company called ICEsoft started working on a JSF component
library. ICEsoft had been in business for a couple of years and had been working on
a product called ICEbrowser, a Java-based browser, and a product called ICEbrowser
beans, which were “lightweight, configurable Javabean components that can be rapidly
integrated into Java client applications.” During JavaOne 2005 of that year, on 27 June,
ICEsoft announced their its component library for JSF—ICEfaces. This was based
on AJAX as well but incorporated AJAX directly into the components. ICEsoft called
its specific technique “patent pending Direct-to-DOM™,” which basically meant that
changes coming from the server were directly injected into the DOM tree structure of a
web page. A final version wasn’t available right away though, but an early access release
was provided. This was closed source but cost-free.
Meanwhile, JSF EG member Jacob Hookom, inspired by Hans Bergsten’s concerns
about the unsuitability of JSP, grabbed the bull by the horns and started working himself
on that alternative templating language envisioned by Bergsten. In August 2005 this
work had progressed into a usable initial version. The name of this templating language?
Facelets! It immediately took the JSF world by storm. Kito Mann published the first part
of a series of articles about it on JSFCentral the very first month, and Richard Hightower
published the famous article “Facelets fits JSF like a glove” several months later.
Oracle had not been sitting still either in 2005, and after about 16(!) early access releases
it announced in late 2005 at the JavaPolis conference in Antwerpen (nowadays called
Devoxx) that ADF Faces would be donated to MyFaces and thus become open source.
In the first month of 2006, Jacob Hookom and Adam Winer contemplated the terrible
implementation of JSF’s state save mechanism. This worked by first creating a component
tree from a template and then, near the end of the request, blindly serializing the entire
tree with all data that may have been put there during the request. During a postback the
tree is restored from this serialized form (hence the name of the phase “restore view”).
This is a tremendous waste, as the majority of this information is already available in the
template. Especially when doing AJAX requests with client-side state saving this poses
a very big burden, but it is also a problem when storing this state on the server as it
massively increases JSF’s memory usage. One of the main reasons for doing state saving
in such terrible way again has to do with that one decision: to support JSP. With JSF 1.2
about to go final, there was unfortunately no time left to fix this for version 1.2.
6

Chapter 1

History

Even though it was clear at this point that Facelets was the future of JSF, when
JSF 1.2 was eventually released in May 2006 it still contained only JSP. Not all was bad
though. Thanks to a cooperation between the JSF and JSP EGs, a revision of JSP was
released, JSP 2.1, which was much better aligned with the demands of JSF. On top of
that, JSP’s expression language and JSF’s expression language were merged. The result
was UEL (Unified Expression Language). A very practical advantage of UEL is that JSF
components no longer have to convert Strings manually into expressions but directly
receive a ValueExpression from the templating language. Both JSP 2.1 and JSF 1.2
became part of Java EE 5, which was released at the same time.
On June 13, 2006, the MyFaces community announced that the donated project
would have its name changed to Trinidad. ADF Faces kept existing at Oracle, though,
but was based on Trinidad with some extra features (such as support for Portals, JSR 227,
etc.). Just two weeks prior to that, on May 31, 2006, ICEsoft announced its free, although
still closed source, community edition. A few months later, on November 14, 2006,
ICEsoft would fully open source ICEfaces under the MPL license. RichFaces, still closed
source at that point and being sold by Exadel, would not stay behind for long though,
and some four months later, on March 29, 2007, Exadel announced a partnership with
Red Hat that made RichFaces available under an open source license and available and
supported via its JBoss group.

On to Maturity
On May 22, 2007, the specification work for JSF 2.0 began. The scope was hugely
ambitious and promised not only to fix many of the issues that people had been
complaining about but also to introduce quite a bunch of new features. Mentioned
among the many goals in the JSR was a particularly interesting one when looking at the
bigger picture—extracting the managed bean facility from JSF and making it available for
the entire platform.
During the fall of 2007 the community was polled for a name for the JSF RI. Four
names rose to the top, but as is often the case none of these names could be approved by
Sun’s legal department. Eventually Mojarra was proposed, and perhaps to the surprise
of some this one did pass legal’s scrutiny. Ryan Lubke, one of the main JSF committers
then, made the official announcement on December 5, 2007.
A little under a year later, on October 29, 2008, Çağatay Çivici started a new library,
PrimeFaces. The name derives from Çağatay’s nickname, which is Optimus Prime, the
7

Chapter 1

History

courageous leader of the heroic autobots in the fictional Transformers universe. Çağatay
had been involved with JSF development for a long time and had worked on the YUI4JSF
JSF component library before. PrimeFaces was initially based on JSF 1.x, but with JSF 2.x
looming and the project still young it would soon after switch to JSF 2.x.
On July 1, 2009, the long-awaited JSF 2.0 finally arrived. JSF 2.0 indeed fixed nearly
every problem that the industry had with JSF; finally, Facelets was included as the
default view templating language. JSP was effectively deprecated. The state saving
concerns that Hookom and Winer brought forward more than three years earlier were
addressed as well; from then on JSF only saved delta state (state changes), and in restore
view the component tree was reloaded from the template, instead of actually restored.
Another big concern brought forward by the JSF community over the years, JSF’s
over-the-top emphasis on postbacks, was addressed too; GET requests became a first-­
class citizen in JSF 2.0. A well-known usability problem with JSF, sometimes called “The
Trap,” was that for a number of operations the data involved needed to be the same
during both the original request and the postback. This is not entirely trivial to guarantee
in JSF 1.x. JSF 2.0 introduced the so-called view scope for this, which elegantly solved the
problem. The creation of custom components, yet another problem area of JSF 1.x, was
made much simpler as well. JSF 2.0 also introduced core support for AJAX, modeled after
the way Ajax4Jsf worked, a resource API, system events, and quite a few other things.
One of JSF 2.0’s goals, making its managed bean facility usable outside JSF, was
implicitly reached by the CDI spec, which was introduced together with JSF 2.0 in Java EE 6.
The CDI spec itself has a long history too, but one of its defining characteristics is that CDI
Beans are strongly based on JSF Managed Beans and are essentially a super set of those.
Altogether the impact of all those fixes and new features was such that it split the
community essentially in two; those who had used JSF 1.x and never looked at it again
and those who switched to JSF 2.x or, specifically, the ones who started using JSF with 2.0
and never saw 1.x. This often led to heated debates, with the 1.x side arguing that JSF
is horrible, and the 2.x side not understanding at all why that would be the case. Even
at the time of this writing, which is almost nine years after JSF 2.0 was released, and a
longer period than JSF 1.x ever existed, these sentiments still remain to some degree.
Despite the many things that JSF 2.0 did right, there was one missed opportunity;
even though CDI was now available and superseded JSF’s Managed Beans, JSF chose
not to deprecate its managed bean facility right away. Even worse, it introduced an
annotation-based alternative to the XML-based system JSF 1.x used to define managed
beans. With CDI already out there having annotations like javax.enterprise.context.
RequestScoped, simultaneously introducing a javax.faces.bean.RequestScoped
8

Chapter 1

History

annotation that did exactly the same thing seems debatable as best. The EG seemed to
be aware of this conflict, as a warning was put in place that these new annotations would
possibly be superseded by platform functionality before long.
On December 23, Cay Horstmann raised his concerns about this very unwanted
situation in an article titled “Is @javax.faces.bean.ManagedBean Dead on Arrival?” The
response was quite clear; people, including Java EE book writer Antonio Goncalves, asked for
this huge mistake that JSF 2.0 had made to be corrected as soon as possible and to deprecate
javax.faces.bean.ManagedBean right away in the upcoming JSF 2.1 maintenance release
which was called for, among other things, to rectify another mistake (namely, the problem
JSF 2.0 introduced that in addition to a custom ResourceResolver it was also necessary to
provide a custom ExternalContext, which was very unclear). Why javax.faces.bean.
ManagedBean indeed wasn’t deprecated in the JSF 2.1 MR remains a mystery to this day.
While applications written against the JSF 1.x APIs would mostly run unchanged
on JSF 2.0, or only needed a few small changes, the component libraries had a much
harder time. Specifically, the platform-provided AJAX support meant that the existing
component libraries would have to forego their own AJAX implementations and
rebase on the standard APIs. Clearly that was no small feat, and it took a long time for
component libraries to migrate, with some never really making the switch at all.
Here PrimeFaces was clearly at an advantage. Being a relatively new library without
much legacy, it made the switch relative easy. Be it a coincidence or not, PrimeFaces’
ascension in popularity seemed to start right after JSF 2.0 was released, which was also
the exact same time that both ICEfaces and RichFaces seemed to become less popular.
Although it must be noted that hard statistics are difficult to obtain and contain many
facets (downloads, deployments, book, questions asked, available jobs, taking different
industries into account, etc.), somewhere around 2012 PrimeFaces had seemingly
become the more popular JSF component library.
In the beginning of that same year, February 19, 2012, Arjan Tijms and Bauke Scholtz
(by coincidence also the authors of this book) started the OmniFaces library for JSF. The
goal of OmniFaces was to be a utility library for JSF, essentially what Apache Commons
and Google Guava are to Java SE. Tijms and Scholtz had worked on a JSF-based web site
together and found that they both had a collection of private JSF utilities that they reused
for different projects, and also that a great number of similar utilities were essentially
rewritten again and again for many JSF projects and were partially floating around in
places like forum messages and blog posts. OmniFaces was set up in particular not to not
compete component libraries like PrimeFaces but to work together with those. Hence,
visual-oriented components were largely out of scope for OmniFaces.
9

Chapter 1

History

In 2012 the specification process for JSF 2.2 was also in full swing. JSF 2.2 was
eventually released on the May 21, the next year. JSF 2.2 specifically came up with a
formal version of the alternative mode in which Facelets could operate; instead of
putting component tags on a view, plain HTML was put on it, with a special ID linking
the tag to a component. Such a mode is generally speaking somewhat less interesting
to JSF developers but appeals specifically to web designers who can more easily use
plain HTML tools for such views. JSF 2.2 also introduced a CDI compatible @ViewScoped
annotation, which removed one of the last reasons to still use the JSF managed bean
facility in JSF 2.1, namely, that in that version @ViewScoped only worked on those beans.
JSF 2.2 also introduced two new big features, Faces Flow and Resource Contracts, but
these seem to have seen little uptake in practice.
Just prior to the start of JSF 2.3, on July 20, 2014, RichFaces lead Brian Leathem
announced on his blog that RichFaces 5, the next-generation version of RichFaces,
would be canceled. Instead, RichFaces would “pursue a path of stability over
innovation,” which means that JBoss will make RichFaces 4.x compatible with JSF 2.2
and port back a few things that were in development for RichFaces 5. While the post was
somewhat optimistic, it strongly looked like the writing was on the wall for RichFaces.
On August 26, 2014, the specification work for JSF 2.3 started. A new co-spec lead
was introduced—Manfred Riem, who up to then had been working mostly on the
implementation side of Mojarra, doing such things as migrating hundreds of the tests
for which JSF is famous away from the ancient and retired Cactus framework to a more
modern Maven-based one, and making sure the gazillions of open Mojarra issues
were reduced to a manageable number. JSF 2.3 started off with a perhaps somewhat
remarkable message that Oracle had only a few resources available. During the
specification process those few resources dropped to a number that few would have
expected—absolutely zero. Basically, after JavaOne 2015, nearly all of the spec leads
just vanished and most specs as a result abruptly ground to a halt. Josh Juneau reported
about this in his famous study, “Java EE 8, What Is the Current Status: Case Study for
Completed Work Since Late 2015,” which undeniable makes it clear by showing graphs
of e-mails, commits, and issues resolved that Oracle had just walked away.
The openness of the JSF and its RI Mojarra were fortunately such that the
specification work and implementation thereof in Mojarra can largely be carried on by
the other EG members, which indeed happens.

10

Chapter 1

History

Meanwhile on February 12, 2016, Red Hat announced that RichFaces would be
end of lived (EOL) later that year, namely, in June 2016. One of the most popular JSF
component libraries at some point, often named something like “One of the big three,”
effectively was no more. On June 20, 2016, the last real commit to the project was done,
“RF-14279: update JSDoc.” Two days later Red Hat released RichFaces 4.5.17 and the
GitHub repos were put into archived (read only) mode. Brian Leathem, who is still a
JSF 2.3 EG member, announced a few days later on February 18 that he would no longer
be doing any JSF-related work.

Rejuvenation
In late 2016 the JSF spec leads briefly returned, but with the message that the spec must
be completed in only a few weeks, so the (somewhat) lengthy finalization process could
start. On March 28, 2017, JSF 2.3 was then eventually released, bringing with it the start
of replacing JSF native artifacts with CDI versions, and finally something which should
have happened years ago: the deprecation of the JSF managed bean facility in favor of
using CDI beans. Other features are support for WebSocket using the Java EE WebSocket
APIs donated by OmniFaces, the introspection of available view resources in the system,
and a search expression framework donated by PrimeFaces.
Following the somewhat turbulent development of the JSF 2.3 spec is the even more
turbulent announcement by Oracle in 2017 that Java EE, thus including JSF, would be
transferred to the Eclipse foundation. Oracle would stop leading the specs it owned
before, which again includes JSF. This would mean that Mojarra would be re-licensed,
and JSF would be evolved by a new process with likely different leads. At the time of
writing, this transfer is in full swing.

11

CHAPTER 2

From Zero to Hello World
In this chapter you will learn how to set up a JSF (JavaServer Faces) development
environment with the Eclipse IDE (integrated development environment), the Payara
application server, and H2 database from scratch.

Installing Java SE JDK
You probably already know that Java SE is available as JRE for end users and as JDK
for software developers. Eclipse itself does not strictly require a JDK as it has its own
compiler. JSF being a software library does not require a JDK to run either. Payara,
however, does require a JDK to run, primarily in order to be able to compile JSP files,
even though JSP has been deprecated as JSF view technology since JSF 2.0.
Therefore, you need to make sure that you already have a JDK installed as per
Oracle’s instructions. The current Java SE version is 9, but as Java EE 8 was designed
for Java SE 8 which is currently more mature, JDK 8 is recommended: https://docs.
oracle.com/javase/8/docs/technotes/guides/install/install_overview.html.
The most important parts are that the PATH environment variable covers the /bin
folder containing the Java executables (e.g., "/path/to/jdk/bin"), and that the JAVA_HOME
environment variable is set to the JDK root folder (e.g., "/path/to/jdk"). This is not strictly
required by JSF, but Eclipse and Payara need this. Eclipse will need the PATH in order to
find the Java executables. Payara will need the JAVA_HOME in order to find the JDK tools.

What About Java EE?
Note that you do not need to download and install Java EE from Oracle.com even though
JSF itself is part of Java EE. Java EE is basically an abstract specification of which the
so-­called application servers represent the concrete implementations. Examples of
those application servers are Payara, WildFly, TomEE, GlassFish, and Liberty. It is exactly
those application servers that actually provide among others JSF (JavaServer Faces),
© Bauke Scholtz, Arjan Tijms 2018
B. Scholtz and A. Tijms, The Definitive Guide to JSF in Java EE 8, https://doi.org/10.1007/978-1-4842-3387-0_2

13

Chapter 2

From Zero to Hello World

EL (Expression Language), CDI (Contexts and Dependency Injection), EJB (Enterprise
JavaBeans), JPA (Java Persistence API), Servlet, WebSocket, and JSON-P (JavaScript
Object Notation Processing), APIs (application programming interfaces) out of the box.
There also exist so-called servlet containers which provide basically only the Servlet,
JASPIC (Java Authentication Service Provider Interface for Containers), JSP (JavaServer
Pages), EL, and WebSocket APIs out of the box, such as Tomcat and Jetty. However, it
would require some work to manually install and configure, among others, JSF, JSTL
(JSP Standard Tag Library), CDI, EJB, and JPA on such a servlet container. It is not even
trivial in the case of EJB as it requires modifying the servlet container’s internals. That is,
by the way, exactly why TomEE exists. It’s a Java EE application server built on top of the
barebones Tomcat servlet container engine.
Coming back to the Java EE download at Oracle.com, it would give you basically the
GlassFish server, along with a bunch of documentation and optionally the Netbeans
IDE. We do not need it as we are already using Payara as the Java EE application server,
and are targeting Eclipse as IDE. Therefore, the Java SE JDK is sufficient.

I nstalling Payara
Payara is an open source Java EE application server which is in 2014 forked from
GlassFish. It is basically a response to Oracle’s announcement to stop its commercial
support for GlassFish, so companies previously using GlassFish commercially could
effortlessly switch to Payara and continue enjoying commercial support. Thanks to
commercial support for business customers previously using GlassFish, the Payara
application server software can continuously be bug-fixed and improved.
The first Payara version with JSF 2.3 integrated is 5. You can download it from https://
payara.fish. Make sure you choose either the “Payara Server Full” or “Payara Server Web
Profile” download and not, for example, the “Payara Micro” or “Payara Embedded,” as they
have other purposes. Installing is basically a matter of unzipping the downloaded file and
putting it somewhere in your home folder. We’ll leave it there until we have Eclipse up and
running, so that we can then integrate Payara in Eclipse and let it manage the server.

How About Other Servers?
The choice for Payara in this book is primarily because it is at time of this writing
one of the very few available Java EE application servers with JSF 2.3 integrated.
The other one is GlassFish, but we would rather not advocate it as it would basically
14

Chapter 2

From Zero to Hello World

offer no commercial support or bug fixes. GlassFish must be seen as a true reference
implementation for other application server vendors so they can, if necessary, build their
application server implementation by example.
WildFly, TomEE, and Liberty did not, at the time of writing, have a version available
with JSF 2.3 integrated.

I nstalling Eclipse
Eclipse is an open source IDE written in Java. It is basically like notepad but with
thousands if not millions of extra features, such as automatically compiling class files,
building a WAR file with them, and deploying it to an application server without the
need to manually fiddle around with javac in a command console.
Eclipse is available in a lot of flavors. As we’re going to develop with Java EE, we need
the one saying “Eclipse IDE for Java EE developers.” It’s usually the top-ranked download
link at http://eclipse.org/downloads/eclipse-packages/. Also here, installing is
basically a matter of unzipping the downloaded file and putting it somewhere in your
home folder.
In Windows and Linux you’ll find the eclipse.ini configuration file in the unzipped
folder. In Mac OS this configuration file is located in Eclipse.app/Contents/Eclipse.
Open this file for editing. We want to increase the allocated memory for Eclipse. At the
bottom of eclipse.ini, you’ll find the following lines:
-Xms256m
-Xmx1024m
This sets, respectively, the initial and maximum memory size pool which Eclipse
may use. This is a bit too low when you want to develop a bit of a decent Java EE
application. Let’s at least double both the values.
-Xms512m
-Xmx2g
Watch out that you don’t declare more than the available physical memory. When
the actual memory usage exceeds the available physical memory, it will continue into
virtual memory, usually in a swap file on disk. This will greatly decrease performance
and result in major hiccups and slowdowns.

15

Chapter 2

From Zero to Hello World

Now you can start Eclipse by executing the eclipse executable in the unzipped
folder. You will be asked to select a directory as workspace. This is the directory where
Eclipse will save all workspace projects and metadata.
After that, Eclipse will show a welcome screen. This is not interesting for now. You
can click the Workbench button on the right top to close the welcome screen. Untick if
necessary “Always show Welcome at start up” on the bottom right. After that, you will
enter the workbench. By default, it looks like the screenshot in Figure 2-1.

Figure 2-1. Eclipse workbench

C
 onfiguring Eclipse
Before we can start writing code, we would like to fine-tune Eclipse a bit so that we don’t
eventually end up in trouble or with annoyances. Eclipse has an enormous amount of
settings, and some of its default values should not have been the default values. You can
verify and configure the settings via Window ➤ Preferences.
16

Chapter 2

From Zero to Hello World

•

General ➤ Workspace ➤ Text file encoding must be set to UTF-­8.
Particularly in Windows this might otherwise default to the proprietary
encoding CP-1252 which does not support any characters beyond the
Latin range. When reading and saving Unicode files with CP-1252, you
risk seeing unintelligible sequences of characters. This is also called
“mojibake.”.1

•

General ➤ Workspace ➤ New text file line delimiter must be set to
Unix. It works just fine on Windows as well. This will particularly
keep version control systems happy. Otherwise, developers pulling
code on different operating systems might face confusing conflicts or
diffs caused by different line endings.

•

General ➤ Editors ➤ Text editors ➤ Spelling should preferably
be disabled. This will save you from a potentially big annoyance,
because it unnecessarily also spellchecks XML configuration files
such as faces-config.xml and web.xml, causing confusing errors and
warnings in those files.

•

Java ➤ Compiler ➤ Compiler compliance level must be set to 1.8. This
is the minimum required Java version for Java EE 8.

•

Java ➤ Installed JREs must be set to the JDK, not to the JRE. This
setting will normally also be used to execute the integrated
application server which usually requires the JDK.

Installing JBoss Tools Plug-in
Standard Eclipse for Java EE in its current version does not support any CDI tools. It
has no wizards to create CDI managed beans, or autocompletion and hyperlinking for
CDI managed beans in JSF pages. The JBoss Tools plug-in is an extensive plug-in which
offers among others the CDI tools.2 This is very useful when developing a Java EE web
application.

h ttps://en.wikipedia.org/wiki/Mojibake.
http://tools.jboss.org/features/cdi.html.

1
2

17

Chapter 2

From Zero to Hello World

In order to install it, go to Help ➤ Eclipse Marketplace. Enter in the search field “JBoss
Tools” and click Go. Scroll a bit through the results until you see JBoss Tools Final and
then click Install (see Figure 2-2).

Figure 2-2. JBoss Tools in the Eclipse Marketplace
In the next step, you’ll see a fairly large list of all JBoss Tools’ offerings. We don’t need
all of them. The list indeed also includes some JSF-related tools, but they are not terribly
useful. The Visual Page Editor is not at all useful. Dragging and dropping together a JSF
page doesn’t make you a good JSF developer. That can only be achieved by just writing
code yourself. Moreover, having too many unused features installed and even implicitly
enabled may make Eclipse terribly slow. The fewer features you select, the less chance
that you will be surprised about changes in the IDE behavior. So, untick the top check
box and then tick only the check box which says “Context and Dependency Injection
Tools” (see Figure 2-3).

18

Chapter 2

From Zero to Hello World

Figure 2-3. Select only the CDI tools for now
Next, accept the terms of the license agreement and complete the wizard until
Eclipse is restarted.

Integrating New Server in Eclipse
We need to familarize Eclipse with any installed application servers so that Eclipse can
seamlessly link its Java EE API libraries in the project’s build path (read: the compile time
classpath of the project). This is mandatory in order to be able to import classes from
the Java EE API in your project. You know, the application server itself represents the
concrete implementation of the abstract Java EE API.
In order to integrate a new application server in Eclipse, first check the bottom
section of the workbench with several tabs representing several Views (you can add
new ones via Window ➤ Show View). Click the Servers tab to open the servers view
(see Figure 2-4). Click the link which says “No servers are available. Click this link to
create a new server. . . .”

19

Chapter 2

From Zero to Hello World

Figure 2-4. Servers view of Eclipse Workbench
From the list of available server tools, select Oracle ➤ GlassFish Tools (see Figure 2-5).

Figure 2-5. Selecting GlassFish Tools in New Server wizard
After clicking Next for the first time, it will download the plug-in in the background
and request you to accept the license agreement before installing the plug-in. This
plug-in is mandatory in order to manage any GlassFish-based server from inside the
workbench—among others, adding and removing Eclipse projects to the deployments
folder, starting and stopping the server, and running the server in debug mode. Once it’s
finished installing, it will request you to restart Eclipse. Take action accordingly.
20

Chapter 2

From Zero to Hello World

Once returned into the workspace, click the same link in the Servers view again.
You’ll now see a GlassFish ➤ GlassFish option. Select this and set the Server name field to
“Payara” (see Figure 2-6).

Figure 2-6. Selecting GlassFish server in New Server wizard and naming it Payara
Advance to the next step. Here, you should point the GlassFish location field to the
glassfish subfolder of the Payara installation, there where you have unzipped it after
downloading (see Figure 2-7).

21

Chapter 2

From Zero to Hello World

Figure 2-7. Specifying GlassFish location in New Server wizard
Complete the remainder of the New Server wizard with default settings. You don’t
need to edit any other fields. The newly added server will now appear in the Servers view
(see Figure 2-8).

Figure 2-8. The Payara server in Servers view

Creating New Project in Eclipse
We're now ready to create a new project for our JSF application in Eclipse. This can
be done via the left section of the workbench which by default shows only one tab
representing the Project Explorer view (also here, you can add new views via Window ➤
Show View). Right-click anywhere in this view and select New ➤ Project. It’ll show the
New Project wizard which may have a bit too many options.

22

Chapter 2

From Zero to Hello World

Eclipse, being an IDE for many different project tasks, offers a bewildering amount
of different project types from which to choose. For a Java EE-based application which is
going to be deployed as a simple WAR file, there are basically two project types that we
could choose from: Web ➤ Dynamic Web Project and Maven ➤ Maven Project.
The difference is that the first is an Eclipse native project that really only works on
Eclipse, while the latter is a universal type of project that can be built by any IDE, as well
as easily on the command line and by various CI servers such as Travis and Jenkins. For
this reason, the Maven project type is really the only viable choice (see Figure 2-9).

Figure 2-9. Selecting Maven Project in New Project wizard (note the Dynamic
Web Project as another but non-viable option)
In the next step, make sure that the option Create a simple project (skip archetype
selection) is checked (see Figure 2-10). This will let us start with a really empty Maven
project so that we can configure and populate it ourselves. Of course, you could also
choose from an archetype, which is basically a template project with several already
prepared files and configurations. But we don’t need any for now.

23

Chapter 2

From Zero to Hello World

Figure 2-10. Checking “Create a simple project” in New Maven Project wizard
In the next step, we can specify our own Maven coordinates of the project. The
Maven coordinates consist of, among others, Group Id, Artifact Id, and Version, also
known as GAV in the Maven world. The Group Id usually matches the root package name
you’re going to use, such as com.example. The Artifact Id usually represents the project
name you’re going to use. For simplicity and in order to be consistent in the rest of the
book, we’ll use project. The Version can be kept default at 0.0.1-SNAPSHOT. Finally the
Packaging should be set to war.
Complete the remainder of the New Maven Project wizard (see Figure 2-11). You
don’t need to edit any other fields. Once you’ve finished the wizard, you’ll get to see the
project structure in the Project Explorer view (see Figure 2-12).

24

Chapter 2

From Zero to Hello World

Figure 2-11. Filling out the Maven GAV in new Maven Project wizard

Figure 2-12. The newly created Maven project in Eclipse

25

Chapter 2

From Zero to Hello World

Unfortunately, the Eclipse-generated pom.xml, which is the main indicator of the
project being a Maven project and containing its configuration, is less than ideal. It’s not
current any more, even when generated by the latest Eclipse, the Oxygen 2 (December
2017). You can already see that by the pom.xml file which is marked with an alarming
red cross and an error message in the Markers view. Any project that has at least one
such red cross cannot be built and won’t be deployable. The error message literally says
“web.xml is missing and  is set to true.” In other words, Maven
somehow thinks that it’s still a pre-Java EE 6 project, when this was indeed disallowed.
In order to solve this problem and to catch up the Eclipse-generated pom.xml with
the current standards, we need to open pom.xml for editing and adjust it as shown in the
following code:

    4.0.0
    com.example
    project
    0.0.1-SNAPSHOT
    war
    
        
            UTF-8
        
        
            UTF-8
        
        1.8
        1.8
        false
    

26

Chapter 2

From Zero to Hello World

    
        
            javax
            javaee-api
            8.0
            provided
        
    

Once you save this file, Eclipse will automatically sort it out by itself and clear out
the alarming red cross. Now that looks much better. We'll briefly go through the most
important settings here.
•

Packaging war—indicates the project is a “web” project, and that the
project’s contents will be assembled into a web archive.

•

Encoding UTF-8—sets the encoding that the source files are in and
with which the (reporting) output files should be generated. This
makes the build repeatable, as it otherwise would default to the
system default encoding (again, a rather bad default).

•

Compiler 1.8—sets both the version of Java used in the .java source
files as well as the byte code output in the .class files. Without
setting this, Maven defaults to the oldest version possible, and
sometimes even a lower version than that.

•

failOnMissingWebXml false—older versions of Java EE required
the /WEB-INF/web.xml to be present. Even though this has not been
required any more since Java EE 6, which was released in 2009,
Maven still checks for this file to be present. Setting this to false
prevents this unnecessary check.

•

Dependency javax:javaee-api:8.0 provided—this declares a
dependency on the Java EE 8 API, and makes sure all the Java EE
types like @Named are known to the compiler. This dependency
is set to provided" since those types are already provided by the
target runtime, which is in our case Payara. They will then only be
used to compile the source code against and won’t be included
27

Chapter 2

From Zero to Hello World

in the generated .war. You need to make absolutely sure that any
compile time dependency which is already provided by the target
runtime is set to provided; otherwise it will eventually end up in the
generated .war and you may run into class loading trouble wherein
duplicate different versioned libraries are conflicting with each other.
In case you’re actually not targeting a full-fledged Java EE server
but a barebones servlet container, you would need to adjust the
dependencies as instructed in the README of Mojarra,3 one of the
available JSF implementations and actually the one used under the
cover of Payara.
Now, in Eclipse’s Markers view, there’s only one warning left which says “Build path
specifies execution environment J2SE-1.5. There are no JREs installed in the workspace
that are strictly compatible with this environment.” Well, that basically means that
Eclipse recognizes this Maven project as a Java 1.5-only project while we don’t actually
have Java SE 5 installed, and in spite of the compiler version in pom.xml being set to 1.8.
In order to tell Eclipse that this is really a Java 1.8 project, we need to right-click
the project in Project Explorer view and choose Properties. In the Project Facets section
you should change the version of the Java facet from 1.5 to 1.8 (or 9 if you have JDK 9
installed) (see Figure 2-13). While at it, we also need to update the Servlet API version
and add the CDI, JSF, and JPA facets. The Servlet API is represented by the “Dynamic
Web Module” entry. This needs to be set to version 4.0, which matches Java EE 8.
Further the “CDI,” “JavaServer Faces,” and “JPA” entries need to be selected. The “CDI”
facet is, by the way, only available after having installed the JBoss Tools as instructed in
the section “Installing JBoss Tools Plug-in.”

https://github.com/javaserverfaces/mojarra/blob/master/README.md.

3

28

Chapter 2

From Zero to Hello World

Figure 2-13. The Project Facets section of the project properties (note that the
Servlet API version is represented by “Dynamic Web Module”)
Unfortunately, in the latest available Eclipse version, Oxygen 2 from December
2017, there isn’t a JSF 2.3 or JPA 2.2 version available yet in the dropdown. The highest
available versions are JSF 2.2 and JPA 2.1. This is not a big problem. Its only influence
is on the available code generators and wizards. We can always adjust the Eclipse-­
generated faces-config.xml and persistence.xml files afterward to match the Java EE
8 compatible versions.
As you can see in the yellow warning bar, only Eclipse requires further configuration.
This concerns the newly selected JSF and JPA facets. When clicking the link, we get to see
the Modify Faceted Project wizard (see Figure 2-14).

29

Chapter 2

From Zero to Hello World

Figure 2-14. The JPA Facet configuration

30

Chapter 2

From Zero to Hello World

The first step of the Modify Faceted Project wizard allows us to configure the JPA
facet. We need to make sure that Eclipse is being instructed that the JPA implementation
is already provided by the target runtime and thus Eclipse doesn’t need to include any
libraries. This can be achieved by choosing the “Disable Library Configuration” option
in the JPA implementation field. As we’re going to use the Payara-provided Hibernate as
the actual JPA implementation, which automatically supports discovering of @Entity
annotated classes, we’d like to instruct Eclipse to do the same; otherwise it would
automatically add entities to the persistence.xml when going through the entity code
generation wizard, or show warnings when we create one manually and don’t add it to
the persistence.xml.
Note that configuring a database connection is not necessary for now as we’re going
to use an embedded database.
In the next step of the Modify Faceted Project wizard, we can configure the JSF
capabilities (see Figure 2-15). Also here, we need to make sure that Eclipse is being
instructed that the JSF implementation is already provided by the target runtime and
thus Eclipse doesn’t need to include any libraries. This can be achieved by choosing the
“Disable Library Configuration” option in the JSF Implementation Library field. Further,
we need to rename the servlet name of the FacesServlet to match the fictive instance
variable name: facesServlet. Last but not least, we need to change the URL mapping
pattern from the Jurassic /faces/* to the modern *.xhtml.

31

Chapter 2

From Zero to Hello World

Figure 2-15. The JSF Capabilities configuration
Actually, the entire registration of the FacesServlet in web.xml is, since JSF 2.2,
not strictly necessary any more; you could even uncheck the Configure JSF servlet in
deployment descriptor option and rely on the default auto-registered mappings of /
faces/*, *.faces, *.jsf and *.xhtml. However, as this allows end users and even search
bots to open the very same JSF page by different URLs, and thus causes confusion among
end users and duplicate content penalties among search bots, we’d better restrict to only
one explicitly configured URL pattern.
Now, finish and apply all the wizards and dialogs. The JPA plug-in only puts the
generated persistence.xml at the wrong place. You need to manually move it into src/
main/resources/META-INF. Figure 2-16 shows us how the workbench looks now.

32

Chapter 2

From Zero to Hello World

Figure 2-16. Correctly configured Java EE 8 Maven project in Eclipse
We only need to adjust all the deployment descriptors to catch up to the actually used
Servlet, JSF, JPA, and CDI versions. This is normally done by adjusting the root element of
the deployment descriptor XML file to set the desired XML schemas and the version.
You can find all Java EE 8 schemas at http://xmlns.jcp.org/xml/ns/javaee, which
is an actual web page which currently redirects to some landing page at Oracle.com. This
may change in the future given that Java EE 8 is currently in the process of being transferred
from Oracle to Eclipse. You can open the deployment descriptor XML file for editing by
double-clicking it and then selecting the Source tab in the editor. The correct root element
declarations for Java EE 8 compatible deployment descriptors are thus as follows:
src/main/webapp/WEB-INF/web.xml for Servlet 4.0:


    

src/main/webapp/WEB-INF/faces-config.xml for JSF 2.3:


    

src/main/resources/META-INF/persistence.xml for JPA 2.2:


    

Only the currently available JPA plug-in of Eclipse will show an error on this. You
could ignore this by disabling the JPA validator in the project’s properties, but you can
also just step back to a JPA 2.1 compatible persistence.xml for the time being.
Finally, for sake of completeness we need to create one more deployment descriptor
file, the one for CDI 2.0. This isn’t automatically generated as it’s not required. CDI
is by default always enabled in any Java EE 8 compatible web application. It’s even
34

Chapter 2

From Zero to Hello World

mandatory for the functioning of JSF. Among others the new  relies fully
on CDI. Right-click the /WEB-INF folder of the project and choose New ➤ beans.xml File.
The New beans.xml File wizard which appears now is part of the JBoss Tools plug-in. Just
keep all options default and finish the wizard. It’ll generate the file as follows:
src/main/webapp/WEB-INF/beans.xml for CDI 2.0:


    


Creating the Backing Bean Class
With the project now correctly configured we can start with developing the actual MVC
application. The Controller part of MVC is already configured as FacesServlet in web.xml.
The Model part of MVC is what we’re going to create now. It’s basically just a simple Java
class which is by JSF convention called a Backing Bean since it “backs” a View.
Right-click the src/main/java folder of the project and choose New ➤ Bean.
The New CDI Bean wizard which appears now is also part of the JBoss Tools plug-in
(see Figure 2-17). In this wizard, set the Package to com.example.project.view, set the
Name to HelloWorld, tick the Add @Named chec kbox, and finally set the Scope to
@RequestScoped. The rest of the fields can be kept default or empty.

35

Chapter 2

From Zero to Hello World

Figure 2-17. The JBoss Tools-provided New CDI Bean wizard in Eclipse
The class editor will now open with the newly created backing bean class. We’ll
modify it to get rid of the useless constructor; add two properties, input and output; and
accompany the input property with a getter and setter pair, the output property with only
a getter, and a submit() action method which prepares the output property based on
the input property. As a hint, in Eclipse after entering the properties, you can right-­click

36

Chapter 2

From Zero to Hello World

anywhere in the class editor and choose Source ➤ Generate Getters and Setters to have the
IDE to generate them. In its entirety, the edited backing bean class should look as follows:
package com.example.project.view;
import javax.enterprise.context.RequestScoped;
import javax.inject.Named;
@Named @RequestScoped
public class HelloWorld {
    private String input;
    private String output;
    public void submit() {
        output = "Hello World! You have typed: " + input;
    }
    public String getInput() {
        return input;
    }
    public void setInput(String input) {
        this.input = input;
    }
    public String getOutput() {
        return output;
    }
}

37

Chapter 2

From Zero to Hello World

We'll briefly go through the annotations that are used here.
•

@Named—gives the bean a name, which is primarily used to reference
it via EL. Without any attributes this name defaults to the simple class
name with the first letter in lowercase, thus "helloWorld" here. It will
be available by #{helloWorld} in EL. This can be used in JSF pages.

•

@RequestScoped—gives the bean a scope, which means the same
instance of the bean is used within a given lifespan. In this case that
lifespan is the duration of an HTTP request. When the scope ends,
the bean is automatically destroyed. You can read more about scopes
in Chapter 8.

Creating the Facelets File
Next, we'll create the View part of MVC. It’s basically just a XHTML file which is by JSF
interpreted as a Facelets file or just Facelet. This Facelets file will ultimately generate the
HTML markup that is sent to the browser in response to a request. With help of EL, it can
reference a bean property and invoke a bean action.
Right-click the webapp folder of the project and choose New ➤ XHTML Page
(see Figure 2-18). The New XHTML Page wizard which appears now is also part of the
JBoss Tools plug-in. In this wizard, set the File name to hello.xhtml and finish the wizard.

38

Chapter 2

From Zero to Hello World

Figure 2-18. The JBoss Tools-provided New XHTML Page wizard in Eclipse
The XHTML editor will now open with the newly created Facelets file. You’ll also
notice that the Palette view shows up in bottom box. This is essentially not useful for
JSF-­based web development. So let’s close it. Coming back to the newly created Facelets
file, it’s initially empty. Fill it with the following content:


39

Chapter 2

From Zero to Hello World

    
        Hello World
    
    
        

Hello World

                                                                                                    
We'll briefly go through the JSF-specific XHTML tags that are used here. 40 • —generates the HTML . It gives JSF the opportunity to automatically include any necessary JavaScript files, such as the one containing the necessary logic for . • —generates the HTML . You can also use a plain HTML in this specific Facelet, but then it doesn’t give any other JSF tag the opportunity to automatically include any necessary JavaScript in the end of the HTML . • —generates the HTML
. JSF will automatically include the view state in a hidden input field. • —generates the HTML