Practical Spring Ldap Using Enterprise Java Based Ldap in Spring Data and Spring Framework 6 2Nd Edition Balaji Varanasi All Chapter

Practical Spring LDAP: Using
Enterprise Java-Based LDAP in Spring

Data and Spring Framework 6 2nd
Edition Balaji Varanasi
Visit to download the full and correct content document:
https://ebookmass.com/product/practical-spring-ldap-using-enterprise-java-based-lda
p-in-spring-data-and-spring-framework-6-2nd-edition-balaji-varanasi/
Balaji Varanasi and Andres Sacco
Practical Spring LDAP

Using Enterprise Java-Based LDAP in Spring Data
and Spring Framework 6
2nd ed.
Balaji Varanasi
Salt Lake City, UT, USA
Andres Sacco
Buenos Aires, Buenos Aires, Argentina
ISBN 979-8-8688-0001-6 e-ISBN 979-8-8688-0002-3

https://doi.org/10.1007/979-8-8688-0002-3
© Balaji Varanasi and Andres Sacco 2013, 2023
This work is subject to copyright. All rights are solely and exclusively
licensed 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.
The use of general descriptive names, registered names, trademarks,

service marks, etc. in this publication does not imply, even in the
absence of a specific statement, that such names are exempt from the
relevant protective laws and regulations and therefore free for general
use.
The publisher, the authors, and the editors are safe to assume that the
advice and information in this book are believed to be true and accurate
at the date of publication. Neither the publisher nor the authors or the
editors give a warranty, expressed or implied, with respect to the
material contained herein or for any errors or omissions that may have
been made. The publisher remains neutral with regard to jurisdictional
claims in published maps and institutional affiliations.
This Apress imprint is published by the registered company APress
Media, LLC, part of Springer Nature.
The registered company address is: 1 New York Plaza, New York, NY
10004, U.S.A.
To my grandparents who taught me the importance of learning new
things all the time.
To my wife and children for supporting me while writing this book.
Introduction
Practical Spring LDAP provides complete coverage of Spring LDAP, a
framework designed to take the pain out of LDAP programming. This
book starts by explaining the fundamental concepts of LDAP and
showing the reader how to set up the development environment. It
then dives into Spring LDAP, analyzing the problems it is designed to
solve. After that, the book focuses on the practical aspects of unit
testing and integration testing with LDAP. An in-depth treatment of
LDAP controls and Spring LDAP features, such as Object-Directory
Mapping and LDIF (LDAP Data Interchange Format) parsing, follows
this. Finally, it concludes with discussions on LDAP authentication and
connection pooling.
What the Book Covers
Chapter 1 starts with an overview of directory servers. It then discusses
the basics of LDAP and introduces the four LDAP information models. It
finishes with an introduction to the LDIF format used for representing
LDAP data.
Chapter 2 focuses on the Java Naming and Directory Interface
(JNDI). In this chapter, you look at creating applications that interact
with LDAP using plain JNDI.
Chapter 3 explains Spring LDAP and why it is an important option in
an enterprise developer’s repertoire. In this chapter, you set up the
development environment to create Spring LDAP applications and
other important tools, such as Maven and a test LDAP server. Finally,
you implement a basic but complete Spring LDAP application using
annotations.
Chapter 4 covers the fundamentals of unit and integration testing.
You then look at setting up an embedded LDAP server for unit testing
your application code; alternatively, you will see how to use
Testcontainers to run LDAP using a docker image. You also review
available tools for generating test data. Finally, you use the Mockito
library to mock test LDAP code.
Chapter 5 introduces the basics of JNDI object factories and uses
these factories for creating objects that are more meaningful to the
application. You then examine a complete Data Access Object (DAO)
layer implementation using Spring LDAP and object factories.
Chapter 6 covers LDAP search. This chapter begins with the
underlying ideas of LDAP search. I then introduce various Spring LDAP
filters that make LDAP searching easier. Finally, you look at creating a
custom search filter to address situations where the current set is
insufficient.
Chapter 7 provides an in-depth overview of LDAP controls that can
be used for extending LDAP server functionality. Then it moves on to
sorting and paging LDAP results using sort and page controls.
Chapter 8 deals with Object-Directory Mapping (ODM), a feature in
Spring LDAP. In this chapter, you look at bridging the gap between the
domain model and the directory server. You then re-implement the DAO
using ODM concepts.
Chapter 9 introduces the important ideas of transactions and
transactional integrity before analyzing the transaction abstractions
provided by Spring Framework. Finally, it takes a look at Spring LDAP’s
compensating transaction support.
Chapter 10 starts with implementing authentication, the most
common operation against LDAP. It then deals with parsing LDIF files
using another feature introduced in Spring. I end the chapter by looking
at the connection pooling support provided by Spring LDAP.
Target Audience
Practical Spring LDAP is intended for developers interested in building
Java/JEE applications using LDAP. It also teaches techniques for
creating unit/integration tests for LDAP applications. The book
assumes basic familiarity with Spring Framework; prior exposure to
LDAP is helpful but optional. Developers already familiar with Spring
LDAP will find best practices and examples to help them get the most
out of the framework.
Prerequisites
You should install Java JDK1 21 or higher on your machine, Maven2 3.8.0
or higher, and some IDE. Some options for the IDE could be Eclipse,3
IntelliJ IDEA,4 Visual Studio Code,5 and others, but you can choose
which is the best for you.
To reduce the complexity of installing all LDAP vendors on your
machine, I recommend you install Docker6 and use it to run each LDAP.
The use and installation of Docker are outside the scope of this book,
but there are some tutorials7 or cheatsheet8 with the most common
commands.
Note If you don’t have it installed on your machine, you can check
Appendixes A, B, and C, which have information about installing the
different tools and loading the information on LDAP.
After installing all the tools, you must check if they are correctly
installed before reading the different chapters.
In the case of Java, you need to run the following command:
% java -version
openjdk 21 2023-09-19
OpenJDK Runtime Environment (build 21+35-2513)
OpenJDK 64-Bit Server VM (build 21+35-2513, mixed
mode, sharing)
After that, you need to check if the version of Maven is correct using
this command:
% mvn --version
Apache Maven 3.9.1
Maven home: /usr/share/maven
Last, if you want to check whether Docker runs correctly on your

machine, you can do that using the following command:
% docker --version
Docker version 24.0.2, build cb74dfc
Remember that I mentioned that Docker is optional. It’s only

recommended for reducing the complexity of installing LDAP vendors
on your machine.
Downloading Source Code

The source code for the examples in this book can be downloaded from
www.apress.com. For detailed information about locating this book’s
source code, visit www.apress.com/gp/services/source-
code. The code is organized by chapter and can be built using Maven.
Questions?
If you have any questions or suggestions, contact the author at
sacco.andres@gmail.com.
Any source code or other supplementary material referenced by the
author in this book is available to readers on GitHub
(https://github.com/Apress). For more detailed information, please
visit https://www.apress.com/gp/services/source-code.
Acknowledgments
I would like to thank my family members and friends for their
encouragement and support during the writing of this book:
My wife, Gisela, who was always patient when I spent long hours at
my computer desk working on this book
My little daughter, Francesca, who helped me relax while writing
each chapter
My baby, Allegra, who is the new family member and my inspiration
to write this book
My friends, German Canale and Julian Delley, who always trusted me
to write a book and supported me during tough times
Specially mentioning Manuel Jordan for guiding me in improving
the quality of the book.
My sincere thanks to the beautiful team at Apress for their support
during the publication of this book. Thanks to Shonmirin P.A. for
providing excellent support. Finally, thanks to Mark Powers and Melissa
Duffy for suggesting and allowing me to write a book. Also, I want to
mention the great job that Balaji Varanasi did with the first edition of
this book which gave the base to write the second edition.
Table of Contents
Chapter 1:Introduction to LDAP
LDAP Overview
Directory vs.Database
Information Model
Object Classes
Directory Schema
Naming Model
Functional Model
Security Model
LDIF Format
LDAP History
LDAP Vendors
Sample Application
Summary
Chapter 2:Java Support for LDAP
LDAP Using JNDI
Connect to LDAP
LDAP Operations
Closing Resources
Creating a New Entry
Updating an Entry
Removing an Entry
Searching Entries
Check How the Operations Work
JNDI Drawbacks
Summary
Chapter 3:Introducing Spring LDAP
Motivation
Documentation and Source Code Spring LDAP
Spring LDAP Packaging
Installing Spring LDAP Using Maven
Spring LDAP Archetypes
Creating Projects Using IntelliJ
Spring LDAP Hello World
Spring ApplicationContext
Spring-Powered Search Client
Spring LdapTemplate Operations
Add Operation
Modify Operation
Deleting Operation
Summary
Chapter 4:Testing LDAP Code
Concepts About Testing
Unit Testing
Mock Testing
Integration Testing
Libraries to Do Tests
JUnit
Mockito
Testcontainers
Creating the Tests
Mocking the Templates
Testing Using Embedded Server
Moving to Tests with Testcontainers
Summary
Chapter 5:Advanced Spring LDAP
JNDI Object Factories
Spring and Object Factories
DAO Implementation Using Object Factory
Implementing Finder Methods
Create Method
Update Method
Delete Method
Summary
Chapter 6:Searching LDAP
LDAP Search Criteria
Base Parameter
Scope Parameter
Filter Parameter
Optional Parameters
LDAP Injection
Spring LDAP Filters
EqualsFilter
LikeFilter
PresentFilter
NotPresentFilter
Not Filter
GreaterThanOrEqualsFilter
LessThanOrEqualsFilter
AndFilter
OrFilter
HardcodedFilter
WhitespaceWildcardsFilter
Handling Special Characters
LDAP Query Builder Parameters
Summary
Chapter 7:Sorting and Paging Results
LDAP Controls
Identifying Supported Controls
JNDI and Controls
Spring LDAP and Controls
Sort Control
Implementing Custom DirContextProcessor
Paged Search Controls
Summary
Chapter 8:Object-Directory Mapping
Spring ODM Basics
ODM Metadata
ODM Service Class
Creating Custom Converter
Summary
Chapter 9:LDAP Transactions
Transaction Basics
Local vs.Global Transactions
Programmatic vs.Declarative Transactions
Programmatically
Declaratively
Spring Transaction Abstraction
Declarative Transactions Using Spring
LDAP Transaction Support
Spring LDAP Transaction Support
Compensating Transactions
Summary
Chapter 10:Odds and Ends
Authentication Using Spring LDAP
Handling Authentication Exceptions
Parsing LDIF Data
LDAP Connection Pooling
Built-In Connection Pooling
Spring LDAP Connection Pooling
Pool Validation
Summary
Appendix A:Setting Up Environment Tools
Appendix B:Recommended and Alternative Tools
Appendix C:Set Up LDAP Server
Appendix D:Opening a Project
Appendix E:Further Reading
Index
About the Authors
Balaji Varanasi
is a software development manager and technology entrepreneur. He
has over 13 years of experience architecting and developing Java/.NET
applications and, more recently, iPhone apps. During this period, he has
worked in the areas of security, web accessibility, search, and
enterprise portals. He has a master’s degree in computer science and
serves as adjunct faculty, teaching programming and information
system courses. When not programming, he enjoys spending time with
his lovely wife in Salt Lake City, Utah.
Andres Sacco
has been working as a developer since
2007 in different languages, including
Java, PHP, Node.js, Scala, and Kotlin. His
background is mostly in Java and the
libraries or frameworks associated with
this language. At most of the companies
he worked for, he researched new
technologies to improve the
performance, stability, and quality of the
applications of each company. In 2017,
he started to find new ways to optimize
the transference of data between
applications to reduce the cost of
infrastructure. He suggested some
actions, some applicable in all of the manual microservices and others
in just a few. All of this work includes creating a series of theoretic-
practical projects (available on Manning.com). Recently, he coauthored
an Apress book titled Beginning Scala 3. He also published a set of
theoretic-practical projects about uncommon ways of testing, such as
architecture tests and chaos engineering.
About the Technical Reviewer
Manuel Jordan
is an autodidactic developer and researcher who enjoys learning new
technologies for his own experiments about creating new integrations
among them.
Manuel won the 2010 Springy Award – Community Champion and
Spring Champion 2013. In his little free time, he reads the Bible and
composes music on his bass and guitar.
You can reach him through his Twitter account, @dr_pompeii.
© The Author(s), under exclusive license to APress Media, LLC, part of Springer Nature 2023
B. Varanasi, A. Sacco, Practical Spring LDAP
https://doi.org/10.1007/979-8-8688-0002-3_1
1. Introduction to LDAP
Balaji Varanasi1 and Andres Sacco2
(1) Salt Lake City, UT, USA
(2) Buenos Aires, Buenos Aires, Argentina
We all deal with directories daily. We use a telephone directory to look up phone numbers. When visiting a
library, we use the library catalog to look up the books we want to read. We use the file system directory
with computers to store our files and documents. Simply put, a directory is a repository of information. The
information is usually organized so that it can be retrieved easily.
Directories on a network are typically accessed using the client/server communication model.
Applications wanting to read or write data to a directory communicate with specialized servers. The
directory server performs a read or write operation on the actual directory. Figure 1-1 shows this
client/server interaction.
Figure 1-1 Directory server and client interaction
The communication between the directory server and client applications is usually accomplished using
standardized protocols. The Lightweight Directory Access Protocol (LDAP) provides a standard protocol for
communicating with a directory. The directory servers that implement the LDAP protocol are usually called
LDAP servers. The LDAP protocol is based on an earlier X.5001 standard but is significantly simpler
(lightweight) and easily extensible. Over the years, the LDAP protocol went through iterations and is
currently at version 3.0.
LDAP Overview
LDAP defines a message protocol used by directory clients and directory servers. LDAP can be better
understood by considering the following four models it is based on:
The Information model determines the structure of information stored in the directory.
The Naming model defines how information is organized and identified in the directory.
The Functional model defines the operations performed on the directory.
The Security model defines how to protect information from unauthorized access.
We will look at each of these models in the following sections.
Directory vs. Database

Beginners often need clarification and picture an LDAP directory as a relational database. Like a database,
an LDAP directory stores information. However, several key characteristics set a directory apart from
relational databases.
LDAP directories typically store data that is relatively static. For example, employee information stored
in LDAP, such as their phone number or name, does not change daily. However, users and applications look
up this information very frequently. Since the data in a directory is accessed more often than updated, LDAP
directories follow the WORM principle2, 3 and are heavily optimized for read performance. Placing data that
change quite often in LDAP does not make sense.
Relational databases employ referential integrity and locking techniques to ensure data consistency. The
type of data stored in LDAP usually does not warrant such strict consistency requirements. Hence, most of
these features need to be present on LDAP servers. Also, transactional semantics to roll back transactions
are not defined under LDAP specification.
Relational databases follow normalization principles to avoid data duplication and redundancy. On the
other hand, LDAP directories are organized in a hierarchical, object-oriented way. This organization violates
some of the normalization principles. Also, there needs to be a concept of table joins in LDAP.
Even though directories lack several of the RDBMS4 features mentioned earlier, many modern LDAP
directories are built on top of relational databases such as DB2,5 MySQL,6 and PostgreSQL.7
At some point, LDAP has similar characteristics to nonrelational databases like Cassandra,8 MongoDB,9
and many others where the performance of the write/read, high availability, and scalability are more
relevant than the consistency.
Information Model
The basic unit of information stored in LDAP is an entry. Entries hold information about real-world objects
such as employees, servers, printers, and organizations. Each entry in an LDAP directory comprises zero or
more attributes. Attributes are key-value pairs that hold information about the object the entry represents.
The key portion of an attribute is also called the attribute type and describes the information that can be
stored in the attribute. The value portion of the attribute contains the actual information. Table 1-1 shows a
portion of an entry representing an employee. The left column in the entry contains the attribute types, and
the right column holds the attribute values.
Table 1-1 Employee LDAP Entry
Employee Entry
objectClass inetOrgPerson
givenName John
surname Smith
mail john@inflix.com
jsmith@inflix.com
mobile +1 801 100 1000
Note Attribute names, by default, are case-insensitive. However, it is recommended to use camel case
format in LDAP operations.
You will notice that the mail attribute has two values. Attributes that are allowed to hold multiple values are
called multivalued attributes. Single-valued attributes, on the other hand, can only hold a single value. The
LDAP specification does not guarantee the order of the values in a multivalued attribute.
Each attribute type is associated with a syntax that dictates the format of the data stored as an attribute
value. For example, the mobile attribute type has a telephoneNumber syntax. This forces the attribute to
hold a string value with a length between 1 and 32.
Additionally, the syntax also defines the attribute value behavior during search operations. For example,
the givenName attribute has the syntax DirectoryString. This syntax enforces that only alphanumeric
characters are allowed as values. Table 1-2 lists some common attributes and their associated syntax
description.
Table 1-2 Common Entry Attributes
Attribute Type Syntax Description

commonName DirectoryString Stores the common name of a person.
company DirectoryString Stores the company’s name.
employeeNumber DirectoryString Stores the employee’s identification number in the organization.
givenName DirectoryString Stores the user’s first name.
jpegPhoto Binary Stores one or more images of the person.
mail IA5 String Stores a person’s SMTP mail address.
mobile TelephoneNumber Stores a person’s mobile number.
postalAddress Postal Address Stores the user’s ZIP or postal code.
postalCode DirectoryString Stores the user’s ZIP or postal code.
st DirectoryString Stores the state or province name.
street DirectoryString Stores the street address.
surname DirectoryString Stores the last name of the person.
telephoneNumber TelephoneNumber Stores the person’s primary telephone number.
uid DirectoryString Stores the user id.

title DirectoryString Stores the name of the position or the company’s function.
wwwhomepage DirectoryString Stores the official web page of the company.
The attributes in Table 1-2 are the most used for the developers and tools. Still, there is a big list of other
attributes depending on whether your vendor or the tool supports it or not; for example, on the official web
page10 of Microsoft, all the attributes are supported for the Active Directory.
Object Classes
In object-oriented languages, such as Java, we create a class and use it as a blueprint for creating objects. The
class defines the attributes/data (and behavior/methods) that these instances can have. Similarly, object
classes in LDAP determine the attributes an LDAP entry can have. These object classes also define which
attributes are mandatory and which are optional. Every LDAP entry has a special attribute aptly named
objectClass that holds the object class it belongs to. Looking at the objectClass value in the employee
entry in Table 1-1, we can conclude that the entry belongs to the inetOrgPerson class. Table 1-3 shows
the required and optional attributes in a standard LDAP person object class. The cn attribute holds the
person’s common name, whereas the sn attribute holds the person’s family name or surname.
Table 1-3 Person Object Class
Required Attributes Optional Attributes

sn description
telephoneNumber
cn userPassword
objectClass seeAlso
As in Java, an object class can extend other object classes. This inheritance will allow the child object
class to inherit parent class attributes. For example, the person object class defines attributes such as
common name and surname. The object class inetOrgPerson extends the person class and thus inherits
all the person’s attributes.
Additionally, inetOrgPerson defines attributes required for a person working in an organization, such
as departmentNumber and employeeNumber. One special object class, namely, top, does not have any
parents. All other object classes are decedents of top and inherit all the attributes declared in it. The top
object class includes the mandatory objectClass attribute. Figure 1-2 shows the object inheritance.
Figure 1-2 LDAP object inheritance
Most LDAP implementations come with standard object classes that can be used out of the box. Table 1-4
lists some of these LDAP object classes and their commonly used attributes.
Table 1-4 Common LDAP Object Classes
Object Class Attributes Description

top objectClass Defines the root object class. All other object classes must
extend this class.
organization o Represents a company or an organization.
The o attribute typically holds the name of the organization.
organizationalUnit ou Represents a department or similar entity inside an
organization.
person sn Represents a person in the directory and requires the sn
cn (surname) and cn (common name) attributes.
telephoneNumber
userPassword
organizationalPerson registeredAddress Subclasses that represent a person in an organization.

postalAddress postalCode
inetOrgPerson uid departmentNumber It provides additional attributes and can be used to represent a
employeeNumber givenName person working in today’s Internet- and intranet-based
manager organization. The uid attribute holds the person’s username or
user id.
On Oracle’s official website,11 you can find the list of LDAP object classes with information about the
Request for Comments (RFC), which added each object class.
Note In this book, you will see many references to RFCs. Request for Comments (RFC) is a series of
technical documents produced by the Internet Engineering Task Force (IETF)12 that specify certain
standards.
Each RFC has a number as part of the name and a series of sections with the specification. An RFC
could become obsolete to many other RFCs because a new specification about certain technology
appears, for example, a new version of LDAP.
On the RFC Editor web page,13 you can find information about RFCs and the publication process of the
new one.
Directory Schema
The LDAP directory schema is a set of rules determining the type of information stored in a directory.
Schemas can be considered packaging units and contain attribute type definitions and object class
definitions. The schema rules are verified before an entry can be stored in LDAP. This schema checking
ensures that the entry has all the required attributes and contains no attributes not part of the schema.
Figure 1-3 represents a generic LDAP schema.
Figure 1-3 LDAP generic schema
Like databases, directory schemas must be well designed to address issues like data redundancy. Before
implementing your schema, it is worth looking at publicly available standard schemas. These standard
schemas often contain all definitions to store the required data and, more importantly, ensure
interoperability across other directories.
Naming Model
The LDAP Naming model defines how entries are organized in a directory. It also determines how a
particular entry can be uniquely identified. The Naming model recommends that entries be stored logically
in a hierarchical fashion. This entry tree is often called a directory information tree (DIT). Figure 1-4
provides an example of a generic directory tree.
Figure 1-4 Generic DIT
The tree’s root is usually referred to as the base or suffix of the directory. This entry represents the
organization that owns the directory. The format of suffixes can vary from implementation to
implementation, but generally, there are three recommended approaches, as listed in Figure 1-5.
Figure 1-5 Directory suffix naming conventions
Note DC stands for domain component.
The first recommended technique is to use the organization’s domain name as the suffix. For example, if the
organization’s domain name is example.com, the directory suffix will be o=example.com. The second
technique also uses the domain name, but each name component is prepended with “dc=” and joined by
commas. So the domain name example.com would result in a suffix dc=example, dc=com. This technique
is proposed in RFC 224714 and is popular with Microsoft Active Directory. The third technique uses the
X.500 model and creates a suffix in the format o=organization name, c=country code. In the United States,
the suffix for the organization example would be o=example, c=us.
The naming model also defines naming and uniquely identifying entries in a directory. Entries with a
common immediate parent are uniquely identified via their relative distinguished name (RDN), also called
distinguished name (DN). The RDN is computed using one or more attribute/value pairs of the entry. In its
simplest case, RDN is usually of the form attribute-name = attribute value. Figure 1-6 provides a simplified
representation of an organization directory. Each person entry under ou=employees has a unique uid. So the
RDN for the first person entry would be uid=emp1, where emp1 is the employee’s user id.
Figure 1-6 Example of an organization directory
Note The distinguished name is not an actual attribute in the entry. It is a logical name associated with
the entry.
It is important to remember that RDN cannot be used to uniquely identify the entry in the entire tree.
However, this can be easily done by combining the RDNs of all the entries in the path from the top of the tree
to the entry. The result of this combination is referred to as distinguished name (DN). In Figure 1-6, the DN
for person 1 would be uid=emp1, ou=employees, dc=example, dc=com. Since the DN is made by combining
RDNs, if an entry’s RDN changes, the DNs of that entry and all its child entries also change.
There can be situations where a set of entries does not have a unique attribute. In those scenarios, one
option is to combine multiple attributes to create uniqueness. For example, we can use the consumer’s
common name and email address in the previous directory as an RDN. Multivalued RDNs are represented by
separating each attribute pair with a +, like so:
cn = Balaji Varanasi + mail=balaji@inflinx.com
Some special characters on the RDN must be escaped to prevent different problems. The special
characters are + (plus), = (equals), < (less than), > (greater than), ; (semicolon), , (comma), \ (backslash), #
(number sign), and ”.
There are different approaches to escape the characters, like adding the backslash (“\” ASCII 92) before
the special character; this approach is the most commonly used. The other replaces the special characters
with a backslash and hexadecimal digit, and the last one surrounds the attribute’s value with quotation
marks (“”).
Note Multivalued RDNs are usually discouraged. Creating a unique sequence attribute is recommended
in those scenarios to ensure uniqueness.
Functional Model
The LDAP Functional model describes the access and modification operations that can be performed on the
directory using the LDAP protocol. These operations fall into three categories: query, update, and
authentication.
The query operations are used to search and retrieve information from a directory. So whenever some
information needs to be read, a search query must be constructed and executed against LDAP. The search
operation takes a starting point within DIT, the search depth, and the attributes an entry must have for a
match. In Chapter 6, you’ll delve deep into searching and look at all the available options.
The update operations add, modify, delete, and rename directory entries. As the name suggests, the add
operation adds a new entry to the directory. This operation requires the DN of the entry to be created and a
set of attributes that constitute the entry. The delete operation takes a fully qualified DN of the entry and
deletes it from the directory. The LDAP protocol allows only the leaf entries to be deleted. The modified
operation updates an existing entry. This operation takes the entry’s DN and a set of modifications, such as
adding a new attribute, updating a new one, or removing an existing one. The rename operation can rename
or move entries in a directory.
The authentication operations are used for connecting and ending sessions between the client and the
LDAP server. A bind operation initiates an LDAP session between the client and server. Typically, this would
result in an anonymous session. The client can provide a DN and credentials to authenticate and create an
authenticated session. On the other hand, the unbind operation can be used to terminate an existing session
and disconnect from the server.
LDAP V3 introduced a framework for extending existing operations and adding new ones without
changing the protocol. You will take a look at these operations in Chapter 7.
Security Model
The LDAP Security model protects LDAP directory information from unauthorized access. The model
specifies which clients can access which parts of the directory and what kinds of operations (search vs.
update) are allowed.
The LDAP Security model is based on the client authenticating to the server. As discussed earlier, this
authentication process or bind operation involves the client supplying a DN identifying itself and a
password. An anonymous session is established if the client does not provide a DN and password. RFC
282915 defines a set of authentication methods that LDAP V3 servers must support. After successful
authentication, the access control models are consulted to determine whether the client has sufficient
privileges to do what is requested. Unfortunately, no standards exist for access control models, and each
vendor provides their implementations.
LDIF Format
The LDAP Data Interchange Format (LDIF) is a standard text-based format for representing directory
content and update requests. The LDIF format is defined in RFC 2849.16 LDIF files are typically used to
export data from one directory server and import it into another. It is also popular for archiving directory
data and applying bulk updates to a directory. You will use LDIF files to store your test data and refresh the
directory server between unit tests.
The basic format of an entry represented in LDIF is as follows:
#comment
dn: <distinguished name>
objectClass: <object class>
objectClass: <object class>
...
...
<attribute type>: <attribute value>
<attribute type>: <attribute value>
...
Lines in the LDIF file starting with a # character are considered comments. The dn and at least one
objectClass entry definition are considered required. Attributes are represented as name/value pairs
separated by a colon. Multiple attribute values are specified in separate lines and will have the same
attribute type. Since LDIF files are purely text based, binary data needs to be Base64 encoded before it is
stored as part of the LDIF file.
Blank lines separate multiple entries in the same LDIF file. Listing 1-1 shows an LDIF file with three
employee entries. Notice that the cn attribute is multivalued and is represented twice for each employee.
# Barbara’s Entry
dn: cn=Barbara J Jensen, dc=example, dc=com
# multi valued attribute
cn: Barbara J Jensen
cn: Babs Jensen
objectClass: personsn: Jensen
# Bjorn’s Entry
dn: cn=Bjorn J Jensen, dc=example, dc=com
cn: Bjorn J Jensen
cn: Bjorn Jensen
objectClass: person
sn: Jensen
# Base64 encoded JPEG photo
jpegPhoto:: /9j/4AAQSkZJRgABAAAAAQABAAD/2wBDABALD
A4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQ
ERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG
# Jennifer’s Entry
dn: cn=Jennifer J Jensen, dc=example, dc=com
cn: Jennifer J Jensen
cn: Jennifer Jensen
objectClass: person
sn: Jensen
Listing 1-1 LDIF file with three employee entries
LDAP History
LDAP was developed by Tim Howes, Steve Kille, and Wengyik Yeong to create a network protocol to get data
out. In 1993 appeared the first draft of the RFC 1487,17 which contained the specification of LDAP based on
the access of X.500.
The first version acts as a proxy or gateway to X.500 directories, a comprehensive directory service
developed in the 1980s.
Tim Howes, with his colleagues, created the Open Source University of Michigan LDAP Implementation,
which became the reference for all the LDAP servers. The project’s website is active18 and accessible only for
historical reference.
The second version, the first to be operative (LDAPv2), was released in 1993 as an Internet Engineering
Task Force (IETF) Proposed Standard with basic operations like searching and modifying information. This
version offers limited functionality and has some problems related to the security mechanisms.
The third version, the latest available, was released in 1997, including many improvements related to
security, like Transport Layer Security (TLS) and the possibility of supporting referrals. It was based on RFCs
like RFC 225119 and RFC 4519,20 which explain the protocol and the supported data models. This version
became the de facto standard for directory services, and many applications have support to integrate and
use LDAP to obtain certain information.
LDAP Vendors
LDAP gained wide support from various vendors. There has also been a strong open source movement to
produce LDAP servers. Table 1-5 outlines some of the popular directory servers and include the information
about which is the docker image to run each of them with a small configuration.
Table 1-5 LDAP Vendors
Directory Vendor Open URL
Name Source?
Apache DS Apache Yes https://directory.apache.org/apacheds/ https://hub.docke
OpenLDAP OpenLDAP Yes https://www.openldap.org/ https://hub.d
Tivoli IBM No https://www.ibm.com/docs/en/i/7.5?topic=services-tivoli- No existing official i

Directory directory-server-i-ldap
Server
Active Microsoft No https://learn.microsoft.com/en-us/windows/win32/adsi/so- No existing official i
Directory what-is-active-directory?redirectedfrom=MSDN
eDirectory Novell No https://www.microfocus.com/en-us/cyberres/identity- No existing official
access-management/edirectory
Oracle Oracle No https://www.oracle.com/security/identity- No existing official i

Directory (formerly management/technologies/directory-server-enterprise-
Server Sun) edition
Enterprise
Edition
(ODSEE)
Oracle No https://www.oracle.com/middleware/technologies/internet- No existing official i
Internet directory.html
Directory
(OID)
OpenDJ ForgeRock Yes https://github.com/OpenIdentityPlatform/OpenDJ https://hub.docker
ApacheDS and OpenDJ are pure Java implementations of LDAP directories. You will be using these two
servers for unit and integration testing of the code throughout this book.
Sample Application
Throughout this book, you will be working with a directory for a hypothetical book library. I have chosen the
library because the concept is universal and easy to grasp. A library usually stores books and other
multimedia that patrons can borrow. Libraries also employ people to take care of daily library operations. To
keep things manageable, the directory will not store book information. A relational database is suitable for
recording book information. Figure 1-7 shows the LDAP directory tree for our library application.
Figure 1-7 Library DIT
I have used the RFC 224714 convention in this directory tree to name the base entry. The base entry has
two organizational unit entries that hold the employees’ and patrons’ information. The ou=employees part
of the tree will hold all the library employee entries. The ou=patrons part of the tree will hold the library
patron entries. Both library employee and patron entries are of the type inetOrgPerson objectClass.
Both employees and patrons access library applications using their unique login id. Thus, the uid attribute
will be used as the RDN for entries.
Summary
LDAP and applications that interact with LDAP have become a key part of every enterprise today. This
chapter covered the basics of the LDAP directory. You learned that LDAP stores information as entries. Each
entry is made up of attributes that are simply key-value pairs. These entries can be accessed via their
distinguished names. You also saw that LDAP directories have schemas that determine the type of
information that can be stored.
The next chapter will look at communicating with an LDAP directory using Java Naming and Directory
Interface (JNDI). In the chapters following Chapter 2, you will focus on using Spring LDAP for developing
LDAP applications.
Footnotes
1 https://docs.oracle.com/javase/jndi/tutorial/ldap/models/x500.html
2 https://en.wikipedia.org/wiki/Write_Once_Read_Many
3 https://www.techtarget.com/searchstorage/definition/WORM-write-once-read-many
4 https://www.oracle.com/in/database/what-is-a-relational-database/
5 https://www.ibm.com/products/db2
6 https://www.mysql.com/
7 https://www.postgresql.org/
8 https://cassandra.apache.org/_/index.html
9 https://www.mongodb.com/
10 https://learn.microsoft.com/en-us/windows/win32/adschema/attributes-all
11 https://docs.oracle.com/cd/E24001_01/oid.1111/e10035/schema_objclass.htm
12 https://www.ietf.org/
13 https://www.rfc-editor.org/
14 https://www.ietf.org/rfc/rfc2247.txt
17 https://datatracker.ietf.org/doc/html/rfc1487
18 www.umich.edu/~dirsvcs/ldap/ldap.html
https://doi.org/10.1007/979-8-8688-0002-3_2
2. Java Support for LDAP

As the name suggests, the Java Naming and Directory Interface (JNDI) provides a standardized
programming interface for accessing naming and directory services. It is a generic Application
Programming Interface (API) that can access various systems, including file systems, Enterprise Java Beans
(EJB),1 Common Object Request Broker Architecture (CORBA),2 and directory services such as the Network
Information Service and LDAP. JNDI’s abstractions to directory services can be viewed as similar to Java
Database Connectivity (JDBC)’s abstractions to relational databases.
The JNDI architecture consists of an Application Programming Interface or API and a Service Provider
Interface or SPI. Developers program their Java applications using the JNDI API to access directory/naming
services. Vendors implement the SPI with details that deal with actual communication to their particular
service/product. Such implementations are referred to as service providers. Figure 2-1 shows the JNDI
architecture and a few naming and directory service providers. This pluggable architecture provides a
consistent programming model and prevents the need to learn a separate API for each product.
Figure 2-1 JNDI architecture
The JNDI has been part of the standard JDK distribution since Java version 1.3 and has not moved to
Jakarta like other packages. The API itself is spread across five packages:
The javax.naming3 package contains classes and interfaces for looking up and accessing objects in a
naming service.
The javax.naming.directory4 package contains classes and interfaces that extend the core javax.naming
package. These classes can access directory services and perform advanced operations such as filtered
searching.
The javax.naming.event5 package has functionality for event notification when accessing naming and
directory services.
The javax.naming.ldap6 package contains classes and interfaces that support the LDAP Version 3
controls and operations. Later chapters will examine controls and operations.
The javax.naming.ldap.spi7 package contains classes to support defining custom DNS for LDAP. The
support of this feature has appeared since Java 12.
The javax.naming.spi8 package contains the SPI interfaces and classes. As mentioned earlier, service
providers implement SPI, and we will not cover these classes in this book.
LDAP Using JNDI
While JNDI allows access to a directory service, it is essential to remember that JNDI is not a directory or a
naming service. Thus, we need a running LDAP directory server to access LDAP using JNDI.
Accessing LDAP using JNDI usually involves three steps:
Connect to LDAP
Perform LDAP operations
Close the resources
Note Check if you have installed the correct version of Java on your machine. To do this, look at
Appendix A, which explains how to do it.
If you don’t have a test LDAP server available, please refer to the steps in Appendix B for installing a
local LDAP server or running it using Docker. The explanation about how to install Docker and check if
everything is okay appears in Appendix A.
This chapter aims to show how you can do different operations on LDAP using Java without any
framework. With this approach, you will see the complexity of doing certain operations and writing
many lines of code to do something simple with the assistance of some framework like Spring LDAP.
Connect to LDAP
All the naming and directory operations using JNDI are performed relative to a context. So the first step in
using JNDI is to create a context that acts as a starting point on the LDAP server. Such a context is referred to
as an initial context. Once an initial context is established, it can look up other contexts or add new objects.
The Context interface and InitialContext class in the javax.naming package can be used for creating an
initial naming context. Since we are dealing with a directory here, we will use a more specific DirContext
interface and its implementation InitialDirContext. Both DirContext and InitialDirContext are available
inside the javax.naming.directory package. The directory context instances can be configured with
properties that provide information about the LDAP server. The code in Listing 2-1 creates a context for an
LDAP server running locally on port 1389.
Properties environment = new Properties();

environment.setProperty(DirContext.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.ldap.LdapCtxFactory");
environment.setProperty(DirContext.PROVIDER_URL, "ldap://localhost:11389");
DirContext context = new InitialDirContext(environment);
Listing 2-1 How to create a basic connection with LDAP
Note In the following parts of the chapter, I will explain in detail the most relevant parts to connect
and execute some operations to LDAP.
By the end of this chapter, you will see the different outputs of the execution of the different methods.
In Listing 2-1, we have used the INITIAL_CONTEXT_FACTORY constant to specify the service provider class
that needs to be used. Here, we use the sun provider com.sun.jndi.ldap.LdapCtxFactory, which is part of
the standard JDK distribution. The PROVIDER_URL is used to specify the fully qualified URL of the LDAP
server. The URL includes the protocol (LDAP for nonsecure or LDAPs for secure connections), the server
hostname, and the port.
Note The declaration of the type on a variable has been optional since Java 14, so you don’t need to
declare that the variable environment has the type Properties; you can replace the keyword var, and the
compiler will infer the correct type.
This change does not add any feature related to the performance, so I decided to keep the code
simple.
Once a connection to the LDAP server is established, the application can identify itself by providing
authentication information. Contexts like the one created in Listing 2-1, where authentication information
is not provided, are called anonymous contexts. LDAP servers usually have ACLs (access list controls) that
restrict operations and information to certain accounts. So it is very common in enterprise applications to
create and use authenticated contexts. Listing 2-2 provides an example of creating an authenticated context.
Notice that we have used three additional properties to provide the binding credentials. The
SECURITY_AUTHENTICATION property is set to simple, indicating that we will use a plain text username
and password for authentication.

environment.setProperty(DirContext.PROVIDER_URL, "ldap://localhost:11389");
environment.setProperty(DirContext.SECURITY_AUTHENTICATION, "simple");
environment.setProperty(DirContext.SECURITY_PRINCIPAL, "Directory Manager");
environment.setProperty(DirContext.SECURITY_CREDENTIALS, "secret");
DirContext context = new InitialDirContext(environment);
Listing 2-2 How to connect on LDAP using the credentials
Note On the declaration of the different properties, you can see the class DirContext appear many
times, which is not the best approach, so if you want to reduce the duplicates, you can simplify using
static imports. For example, you can declare the static import like this: import static
javax.naming.directory.DirContext.INITIAL_CONTEXT_FACTORY, and on the declaration of the variable,
just use PROVIDER_URL.
Any problems occurring during the context creation will be reported as instances of
javax.naming.NamingException. NamingException is the superclass of all the exceptions thrown by the
JNDI API. This is a checked exception and must be handled properly for the code to compile. Table 2-1 lists
common exceptions we will likely encounter during JNDI development.
Table 2-1 Common LDAP Exceptions
Exception Description
AttributeInUseException Thrown when an operation tries to add an existing attribute.
AttributeModificationException Thrown when an operation tries to add/remove/update an attribute and violates the
attribute’s schema or state. For example, adding two values to a single-valued attribute
would result in this exception.
CommunicationException Thrown when an application fails to communicate (network problems) with the LDAP
server.
InvalidAttributesException Thrown when an operation tries to add or modify an attribute set that has been specified
incompletely or incorrectly. For example, adding a new entry without specifying all the
required attributes would result in this exception.
InvalidAttributeValueException Thrown when an operation tries to add or modify a value of an attribute that enters a
conflict with the schema definition.
InvalidSearchFilterException Thrown when a search operation is given a malformed search filter.
LimitExceededException Thrown when a search operation abruptly terminates as a user- or system-specified result
limit is reached.
NameAlreadyBoundException Thrown to indicate that an entry cannot be added as the associated name is already bound
to a different object.
NotContextException Thrown when an operation process until the context is required to continue.
OperationNotSupportedException Thrown when a context implementation does not support a specific operation when
invoked.
PartialResultException Thrown to indicate that only a portion of the expected results is returned and the
Exception Description
operation cannot be completed.
SizeLimitExceededException Thrown when a method produces a result that exceeds a size-related limit.
TimeLimitExceededException Thrown when a method produces a result that exceeds a time-related limit.
LDAP Operations
Once we obtain an initial context, we can perform various operations on LDAP using the context. These
operations can involve looking up another context, creating a new one, and updating or removing an
existing one. Here is an example of looking up another context with DN
uid=emp1,ou=employees,dc=inflinx,dc=com:
DirContext
anotherContext = context.lookup("uid=emp1,ou=employees,dc=inflinx,dc=com");
We will closely examine each of these operations in the coming section.
Closing Resources
After completing all desired LDAP operations, it is important to close the context and any other associated
resources properly. Closing a JNDI resource simply involves calling the close method on it. Listing 2-3 shows
the code associated with closing a DirContext. The code shows that the close method also throws a
NamingException that needs to be properly handled.
try {
context.close();
} catch (NamingException e) {
//Do something with the exception, like log the error.
}
Listing 2-3 How to close the connection with LDAP
Note The previous block does not use “try-with-resources” because DirContext does not implement
the auto closeable.
Creating a New Entry

Consider the case where a new employee starts with our hypothetical library, and we are asked to add their
information to LDAP. As we have seen earlier, before an entry can be added to LDAP, it is necessary to obtain
an InitialDirContext. Listing 2-4 defines a reusable method for doing this.
private DirContext getContext() throws NamingException{

environment.setProperty(DirContext.PROVIDER_URL,
"ldap://localhost:1389");
environment.setProperty(DirContext.SECURITY_PRINCIPAL, "cn=Directory
Manager");
environment.setProperty(DirContext.SECURITY_CREDENTIALS, "secret");
return new InitialDirContext(environment);
}
Listing 2-4 Create a method to connect with LDAP
Once we have the initial context, adding the new employee information is straightforward, as shown in
Listing 2-5.
public void addEmployee(Employee employee) {

DirContext context = null;
try {
context = getContext();
// Populate the attributes
Attributes attributes = new BasicAttributes();
attributes.put(new BasicAttribute("objectClass", "inetOrgPerson"));
attributes.put(new BasicAttribute("uid", employee.getUid()));
attributes.put(new BasicAttribute("givenName",
employee.getFirstName()));
attributes.put(new BasicAttribute("surname", employee.getLastName()));
attributes.put(new BasicAttribute("commonName",
employee.getCommonName()));
attributes.put(new BasicAttribute("departmentNumber",
employee.getDepartmentNumber()));
attributes.put(new BasicAttribute("mail", employee.getEmail()));
attributes.put(new BasicAttribute("employeeNumber",
employee.getEmployeeNumber()));
Attribute phoneAttribute =
new BasicAttribute("telephoneNumber");
for(String phone : employee.getPhone()) {
phoneAttribute.add(phone);
}
attributes.put(phoneAttribute);
// Get the fully qualified DN
String dn = "uid="+employee.getUid() + "," + BASE_PATH;
// Add the entry
context.createSubcontext("dn", attributes);
} catch(NamingException e) {
// Handle the exception and show the description of the problem
} finally {
closeContext(context);
}
}
Listing 2-5 Add a new entry on LDAP
As you can see, the first step in the process is to create a set of attributes that needs to be added to the
entry. JNDI provides the javax.naming.directory.Attributes interface and its implementation
javax.naming.directory.BasicAttributes to abstract an attribute collection. We then add the employee’s
attributes one at a time to the collection using JNDI’s javax.naming.directory.BasicAttribute class. Notice
that we have taken two approaches in creating the BasicAttribute class. In the first approach, we added the
single-valued attributes by passing the attribute name and value to BasicAttribute’s constructor. To handle
the multivalued attribute telephone, we first created the BasicAttribute instance by just passing in the
name. Then, we individually added the telephone values to the attribute. Once all the attributes are added,
we invoked the createSubcontext method on the initial context to add the entry. The createSubcontext
method requires the fully qualified DN of the entry to be added.
Notice that we have delegated the closing of the context to a separate method closeContext. Listing 2-6
shows its implementation.
private void closeContext(DirContext context) {

try {
if (null != context) {
context.close();
}
}
}
Listing 2-6 How to close the connection with LDAP
Updating an Entry
Modifying an existing LDAP entry can involve any of the following operations:
Add a new attribute and value(s) or add a new value to an existing multivalued attribute.
Replace an existing attribute value(s).
Remove an attribute and its value(s).
To allow modification of the entries, JNDI provides an aptly named
javax.naming.directory.ModificationItem class.
A ModificationItem consists of the type of modification to be made and the attribute under modification.
The following code creates a modification item for adding a new telephone number:
Attribute telephoneAttribute = new BasicAttribute("telephone",

"80181001000");
ModificationItem modificationItem = new ModificationItem(DirContext.
ADD_ATTRIBUTE, telephoneAttribute);
Notice that in the preceding code, we have used the constant ADD_ATTRIBUTE to indicate that we want
an add operation. Table 2-2 provides the supported modification types along with their descriptions.
Table 2-2 LDAP Modification Types
Modification Type Description

ADD_ATTRIBUTE Adds the attribute with the supplied value or values to the entry. If the attribute does not exist, then it
will be created. If the attribute is multivalued, this operation adds the specified value(s) to the
existing list. However, this operation on an existing single-valued attribute will result in the
AttributeInUseException.
REPLACE_ATTRIBUTE Replaces existing attribute values of an entry with the supplied values. If the attribute does not exist,
then it will be created. If the attribute already exists, all its values will be replaced.
REMOVE_ATTRIBUTE Removes the specified value from the existing attribute. If no value is specified, the entire attribute
will be removed. If the specified value does not exist in the attribute, the operation will throw a
NamingException. If the value to be removed is the only value of the attribute, then the attribute is
also removed.
The code for updating an entry is provided in Listing 2-7. The modifyAttributes method takes the entry’s
fully qualified DN and an array of modification items.
public void update(String dn, ModificationItem[] items) {

try {
context.modifyAttributes(dn, items);
} finally {
}
}
Listing 2-7 How to update an entry
Removing an Entry
Removing an entry using JNDI is a straightforward process shown in Listing 2-8. The destroySubcontext
method takes the fully qualified DN of the entry that needs to be deleted.
public void remove(String dn) {

try {
context.destroySubcontext(dn);
} finally {
}
}
Listing 2-8 How to remove an entry
Many LDAP servers don’t allow an entry to be deleted if it has child entries. In those servers, deleting a
non-leaf entry would require traversing the subtree and deleting all the child entries. Then the non-leaf
entry can be deleted. Listing 2-9 shows the code involved in deleting a subtree.
public void removeSubtree(DirContext ctx, String root) throws

NamingException {
NamingEnumeration enumeration = null;
try {
enumeration = ctx.listBindings(root);
while (enumeration.hasMore()) {
Binding childEntry = (Binding) enumeration.next();
LdapName childName = new LdapName(root);
childName.add(childEntry.getName());
try {
ctx.destroySubcontext(childName);
} catch (ContextNotEmptyException e) {
removeSubtree(ctx, childName.toString());
ctx.destroySubcontext(childName);
}
}
} finally {
try {
enumeration.close();
} catch (Exception e) {
}
}
}
Listing 2-9 How to remove a subtree of elements
Note The OpenDJ LDAP server supports a special subtree delete control that can cause the server to
delete the non-leaf entry and all its child entries when attached to a delete request. We will look at using
LDAP controls in Chapter 7.
Searching Entries
Searching for information is usually the most common operation against an LDAP server. To perform a
search, we need to provide information such as the scope of the search, what we are looking for, and what
attributes need to be returned. In JNDI, this search metadata is provided using the SearchControls class.
Listing 2-10 provides an example of a search control with subtree scope and returns the givenName and
telephoneNumber attributes. The subtree scope indicates that the search should start from the given base
entry and should search all its subtree entries. We will look at the different scopes available in detail in
Chapter 6.
SearchControls searchControls = new SearchControls();

searchControls.setSearchScope(SearchControls.SUBTREE_SCOPE);
searchControls.setReturningAttributes(new String[]{"givenName",
"telephoneNumber"});
Listing 2-10 The attributes to return for each entry
Once the search controls are defined, the next step is invoking one of the many search methods in the
DirContext instance. Listing 2-11 provides the code that searches all the employees and prints their first
name and telephone number.
public void search() {

NamingEnumeration<SearchResult> searchResults = null;
try {
// Setup Search meta data
SearchControls searchControls = new SearchControls();
searchControls.setSearchScope(SearchControls.SUBTREE_SCOPE);
searchControls.setReturningAttributes(new String[] { "givenName",
"telephoneNumber" });
searchResults = context.search("dc=inflinx,dc=com", "
(objectClass=inetOrgPerson)", searchControls);
while (searchResults.hasMore()) {
SearchResult result = searchResults.next();
Attributes attributes = result.getAttributes();
String firstName = (String) attributes.get("givenName").get();
// Read the multi-valued attribute

Attribute phoneAttribute = attributes.get("telephoneNumber");
String[] phone = new String[phoneAttribute.size()];
NamingEnumeration phoneValues = phoneAttribute.getAll();
for (int i = 0; phoneValues.hasMore(); i++) {

phone[i] = (String) phoneValues.next();
}
//You can use logback or system.out
logger.info(firstName + "> " + Arrays.toString(phone));
}
} finally {
try {
if (null != searchResults) {
searchResults.close();
}
}
}
}
Listing 2-11 How to search elements
Here, we used the search method with three parameters: a base that determines the search’s starting
point, a filter that narrows down the results, and a search control. The search method returns an
enumeration of SearchResults. Each search result holds the LDAP entry’s attributes. Hence, we loop through
the search results and read the attribute values. Notice that we obtain another enumeration instance for
multivalued attributes and read its values one at a time. In the final part of the code, we close the result
enumeration and the context resources.
Check How the Operations Work

After that, reading all the source code of the different operations could be a good idea to check if everything
works fine or not. To do this, a possible approach is to create a class that invokes the different methods of
accessing LDAP using JNDI.
Listing 2-12 shows you a class App that creates an instance of a class JndiLdapDaoImpl, which contains
all the methods of the different operations you see from Listings 2-4 to 2-11. In the case of Listing 2-12, you
only will execute one operation because it’s more simple to analyze the logs.
public class App {

public static void main(String[] args) {
JndiLdapDaoImpl jli = new JndiLdapDaoImpl();
//Search
jli.search();
}
}
Listing 2-12 A class that invokes the method search
If you run the application with the previous block of code, you will see something like Listing 2-13.
12:23:40.978 [main] INFO com.apress.book.ldap.dao.impl.JndiLdapDaoImpl -

Chie> [+1 622 858 9026]
Chin> [+1 191 452 7983]
ChinFui> [+1 439 500 8383]
Ching-Long> [+1 407 407 2419]
Chip> [+1 833 470 1660]
Listing 2-13 The result of obtaining all the employees from LDAP
The next step is to add an employee and obtain all the employees to check whether the operations were
okay. Let’s make some little modifications to the class App, like Listing 2-14.
public class App {

//Add and search

jli.addEmployee(getEmployee());
jli.search();
}
private static Employee getEmployee() {

Employee employee = new Employee();
employee.setEmployeeNumber("50001");
employee.setFirstName("Andres");
employee.setLastName("Sacco");
employee.setEmail("sacco.andres@gmail.com");
employee.setUid("employee30");
employee.setPhone(new String[] { "+54 9 1161484" });
employee.setCommonName("Andres");
return employee;
}
}
Listing 2-14 A class that invokes the methods add and search
Check that a new employee appears at the end of the logs with the name “Andres.”

Chie> [+1 622 858 9026]
Chin> [+1 191 452 7983]
ChinFui> [+1 439 500 8383]
Ching-Long> [+1 407 407 2419]
Chip> [+1 833 470 1660]
Andres> [+54 9 1161484]
Listing 2-15 The result of adding an employee and obtaining all the employees from LDAP
After you add a new employee, the next operation to check is the deletion of an entry from LDAP. You
must send the dn like this: uid=employee29,ou=employees,dc=inflinx,dc=com to remove the
employee29. Let’s make some little modifications to the class App, like Listing 2-16.
public class App {

//Remove and search

jli.remove("uid=employee29,ou=employees,dc=inflinx,dc=com");
jli.search();
}
}
Listing 2-16 A class that invokes the methods remove and search
If you run the application with the previous block of code, you will see something like Listing 2-17. If
you compare the output of this execution with Listing 2-16, you will see that from the list of employees, the
previous one to “Andres,” which is employee number 29 with the name “Chip” was removed.

Chie> [+1 622 858 9026]
Chin> [+1 191 452 7983]
ChinFui> [+1 439 500 8383]
Ching-Long> [+1 407 407 2419]
Andres> [+54 9 1161484]
Listing 2-17 The result of removing an employee and obtaining all the employees from LDAP
The last operation to check how it works is to update an existing entry on LDAP. To make this more
interesting, you will update the givenName of the employee you added to Listing 2-14. Let’s modify your
application’s main class to call the update method, as shown in Listing 2-18.
public class App {

//Update and search

BasicAttribute attribute = new BasicAttribute("givenName", "Andy");
ModificationItem[] items = {new
ModificationItem(DirContext.REPLACE_ATTRIBUTE, attribute)};
jli.update("uid=employee30,ou=employees,dc=inflinx,dc=com", items);
jli.search();
}
}
Listing 2-18 A class that invokes the methods update and search
Check that the last entry changed the givenName attribute from “Andres” to “Andy.”

Chie> [+1 622 858 9026]
Chin> [+1 191 452 7983]
ChinFui> [+1 439 500 8383]
Ching-Long> [+1 407 407 2419]
Andy> [+54 9 1161484]
Listing 2-19 The result of updating an attribute for an employee and obtaining all the employees from LDAP
As you can see from the different examples of the results of the operations, all of them work fine and
give the information you requested. Still, suppose something bad happens during the execution of the
operation. In that case, the NamingException will give you some information about the reason for the
exception, so try to use a mechanism to save the logs in a place accessible to anyone.
JNDI Drawbacks
Though JNDI provides a nice abstraction for accessing directory services, it suffers from several drawbacks:
Explicit Resource Management
The developer is responsible for closing all the resources. This is very error-prone and can result in
memory leaks.
Plumbing Code
The preceding methods have much plumbing code that can be easily abstracted and reused. This
plumbing code makes testing harder, and the developer must learn the API’s nitty-gritty.
Checked Exceptions
The usage of checked exceptions, especially in irrecoverable situations, is questionable. Having to
explicitly handle NamingException in those scenarios usually results in empty try-catch blocks.
Summary
Java offers you a set of interfaces and classes to access and execute different operations on LDAP simply if
you do not need to do complex operations.
The next chapter will look at how to do some operations using Spring LDAP, as you’ve seen in this
chapter. The idea is to show you how Spring LDAP reduces the complexity of certain operations like Spring
Data does with the applications that need to access a database.
Footnotes
1 https://en.wikipedia.org/wiki/Jakarta_Enterprise_Beans
2 https://www.ibm.com/docs/en/sdk-java-technology/8?topic=orb-corba
3 https://docs.oracle.com/en/java/javase/21/docs/api/java.naming/javax/naming/package-
summary.html
4 https://docs.oracle.com/en/java/javase/21/docs/api/java.naming/javax/naming/directory/pack
age-summary.html
5 https://docs.oracle.com/en/java/javase/21/docs/api/java.naming/javax/naming/event/package-
summary.html
6 https://docs.oracle.com/en/java/javase/21/docs/api/java.naming/javax/naming/ldap/package-
summary.html
7 https://docs.oracle.com/en/java/javase/21/docs/api/java.naming/javax/naming/ldap/spi/packa
ge-summary.html
8 https://docs.oracle.com/en/java/javase/21/docs/api/java.naming/javax/naming/spi/package-
summary.html
https://doi.org/10.1007/979-8-8688-0002-3_3
3. Introducing Spring LDAP

Spring LDAP1 provides simple, clean, and comprehensive support for LDAP programming in Java. This
project started on SourceForge in 2006 under the name LdapTemplate to simplify access to LDAP using
JNDI. The project later became part of the Spring Framework portfolio and has come a long way. Figure 3-1
depicts the architecture of a Spring LDAP–based application.
Figure 3-1 Spring LDAP architecture directory
The application code uses the Spring LDAP API to perform LDAP server operations. The Spring LDAP
framework contains all of the LDAP-specific code and abstractions. Spring LDAP, however, will rely on the
Spring Framework for some of its infrastructural needs.
The Spring Framework has become today’s standard for developing Java-based enterprise applications.
Among many other things, it provides a dependency injection–based lightweight alternative to the JEE
programming model. The Spring Framework is the base for Spring LDAP and all other Spring portfolio
projects, such as Spring MVC and Spring Security.
Motivation
In the previous chapter, we discussed the shortcomings of the JNDI API. A notable drawback of JNDI is that it
is very lengthy; almost all of the code in Chapter 2 has to do with plumbing and very little with application
logic. Spring LDAP addresses this problem by providing template and utility classes that take care of the
plumbing code so the developer can focus on business logic.
Another notable issue with JNDI is that it requires the developer to explicitly manage resources such as
LDAP contexts. This can be very error-prone. Forgetting to close resources can result in leaks and can
quickly bring down an application under heavy load. Spring LDAP manages these resources on your behalf
and automatically closes them when you no longer need them. It also provides the ability to pool LDAP
contexts, which can improve performance.
Any problems that arise during the execution of JNDI operations will be reported as instances of
NamingException or its subclasses. NamingException is a checked exception, and thus the developer
is forced to handle it. Data access exceptions are usually not recoverable, and most often, only a little can be
done to catch these exceptions. To address this, Spring LDAP provides a consistent unchecked exception
hierarchy that mimics NamingException. This allows the application designer to choose when and where
to handle these exceptions.
Finally, plain JNDI programming is hard and daunting for new developers. Spring LDAP, with its
abstractions, makes working with JNDI more enjoyable. Additionally, it provides various features such as
Object-Directory Mapping and transaction support, making it an important tool for any enterprise LDAP
developer.
Documentation and Source Code Spring LDAP

Spring Framework portfolio projects can be checked in the documentation from the official website.2 A
direct link is available on the Spring LDAP website,3 or you can check the source code at the GitHub
repository.4
Spring LDAP source code can provide valuable insights into the framework architecture. It also includes
a rich test suite that can serve as additional documentation and help you understand the framework. You
should download and look at the source code. The Git repository also holds a sandbox folder that contains
several experimental features that may or may not make it into the framework.
Spring LDAP Packaging

Now that you can access the Spring LDAP framework’s documentation and source code, let’s delve into the
different components. The LDAP framework is packaged into six components, and Table 3-1 briefly
describes each component.
Table 3-1 Spring LDAP Distribution Modules
Component Description
spring-ldap-core It contains all the classes necessary for using the LDAP framework. This jar is required in all
applications.
spring-ldap-core- It contains classes and extensions that are specific to Java 5 and higher. Applications running under Java
tiger 5 should not use this jar.
spring-ldap-test It contains classes and utilities that make testing easier. It also includes classes for starting and
stopping in-memory instances of the ApacheDS LDAP server.
spring-ldap-ldif- It contains classes for parsing ldif format files.
core
spring-ldap-ldif- It contains classes necessary to integrate ldif parser with Spring Batch Framework.
batch
spring-ldap-odm It contains classes for enabling and creating Object-Directory Mappings.
Along with Spring Framework, you need additional jar files for compiling and running applications using
Spring LDAP. Table 3-2 lists some of these dependent jar files and describes why they are used.
Table 3-2 Spring LDAP
Library Description
slf4j5 Logging is used internally by Spring LDAP and Spring Framework. This is a required jar to be included in
applications.
spring-core Spring library that contains core utilities used internally by Spring LDAP. This is a required library for using
Spring LDAP.
spring-beans Spring Framework library used for creating and managing Spring Beans. Spring LDAP requires another library.
spring- Spring library that is responsible for dependency injection. This is required when using Spring LDAP inside a
context Spring application.
spring-tx Spring Framework library that provides transaction abstractions. This is required when using Spring LDAP
transaction support.
spring-jdbc The library simplifies access to the database using JDBC under the covers. This is an optional library and
should be used for transaction support.
Another random document with
no related content on Scribd:
Spread of Influenza in 1889–90.
Month. 1889–90.
First (October) St. Petersburg, Moscow, Courland, Livonia, Finland.
Second Berlin, Paris, Vienna, Sweden, Denmark.
Third London, Holland, Belgium, Balkan States, North America.
Fourth Capetown, Egypt, Honolulu, Mexico, Japan, Hong Kong.
Fifth San Francisco, Buenos Ayres, India, Sierra Leone, Scilly Islands.
Sixth Chili, Kamerun, Zanzibar, Basutoland, Tasmania.
Seventh British Bechuanaland, Barbados.
Eighth Gold Cost, Natal.
Ninth Trinidad.
Tenth Iceland, Madagascar, China, Senegal.
Eleventh Kashmir, Katunga.
Between the years 1889 and 1893 according to Leichtenstern there was no period
altogether free from influenza. Here and there individual cases or small epidemics
sharply localized were observed. In 1893 another epidemic appeared in many places and
became quite widespread. There was not, according to this author, the definite
geographic progression that had been observed in 1889. This was but a recrudescence, a
lighting up from endemic foci remaining after the first wide spread. In the first half of
1893 there was a light spring epidemic, and in November of the same year a larger
epidemic swept over the whole of Europe. The height of the latter was reached chiefly in
December.
The influenza incidence subsequent to 1893 will be discussed later.
TABLE I.
Influenza epidemics previous to 1889.
Date. General Site of origin. Direction of Localities Rapidity of
features. spread. affected. spread.
1173 Rather meagre Unknown. Described in Not known.
description. Italy, Germany,
England.
1239 Described by Described in Invaded all of
1311 Zeviani. France. France.
Records not
definite. Not
generally
accepted.
1323 Mentioned by
Hirsch, Gluge
and Zeviani.
Most believes
it was a
typhoid
epidemic.
1327 Mentioned by Described in
Zeviani, Italy.
Hirsch and
Gluge. Rather
doubtful.
1358 Described by Savoy, Germany,
Zeviani. Not France,
generally Catalonia.
accepted.
1387 (Zeviani, Italy. Italy, France,
Schweich, Strasbourg,
Gluge, Hirsch Southern
and Germany.
Ripperger.)
Characteristic
description.
1403 A very short France. Described in
epidemic. France. In 1404
(Gluge, it invaded
Ripperger, Flanders and
Pasquier.) Germany
(Hirsch).
1411 Described only Described only Described by
in Paris. in Paris. Pasquier as in
Extent Paris.
unknown.
1414 Characteristic In Italy and
description. France in
February and
March. In the
Danube district
between
January and
April.
1427 Very Described in
characteristic France.
description.
1438 Cited only by Described in
Zeviani. Italy.
1482 Very limited
description
by Mezeray.
1510 Widespread Malta (?) Generally, from Malta, Sicily,
over all of (Webster and South to Spain and
Europe. Hancock North. Portugal, Italy,
report that it France,
began in Hungary,
Africa). Germany,
Holland,
England,
Norway.
1557 All of Europe. Conflicting General direction Asia, 4 months from
information from South to Constantinople, Italy to
(Asia?). North in Sicily, Italy, Netherlands.
Europe. Spain, Sicily in June.
Dalmatia, Nimes in July.
Switzerland, Italy in August.
France, Madrid in
Netherlands, August.
England. Dalmatia in
September.
Netherlands in
October.
1562 Uncertain Only small
1563 information. epidemics at
most.
1580 True pandemic Orient (Hirsch) From Asia to Orient, North France in May.
covering the Africa and Constantinople Africa, Germany and
Orient, Africa Malta and in Europe Constantinople, Hungary in
and Europe. (Pechlin). from South to Malta, Venice, August.
North. Sicily, Italy, England and
Spain, Hungary Rhine Valley in
and Germany September.
to the Baltic, Saxony in
Bohemia, October.
France,
Belgium,
England,
Denmark,
Sweden.
1587 Apparently Described in Italy
quite and Germany.
localized.
1591 High mortality.
Indefinite
information.
1593 Spread over a Said to have Uncertain.
wide area in commenced
Europe. in Belgium,
“following a
violent
earthquake,”
and gradually
extended over
all the cities of
Europe.
1626 Local. Described in
Italy.
1627 In America. Spread from
North America
to West Indies
and Chili.
1647 In America
(Webster).
1658 Local. England (?). Described in
England and in
Treptow near
Stettin.
1675 Over Western Germany (?). Germany, Germany in
Europe. Hungary, September,
England, England and
France. France in
October and
November.
1688 Apparently England(?). Described only in
localized in England and
Great Britain Ireland.
and Ireland.
1693 England and Dublin(?). Dublin, Oxford, One month from
the adjacent London, Dublin to
continent. Holland, London.
Flanders.
1709 A period of In 1712, onset in 1712, spread Italy, France, Six months from
1712 extensive Germany. from Germany Belgium, Germany to
endemics. to Holland and Germany, Italy.
Italy. Denmark.
1729 First epidemic Usually Russia through Moscow, Sweden, Moscow in April,
said to have designated as Sweden, Poland, Silesia, 1729. Sweden
originated in Russia Poland, Austria, in September,
Russia and (Moscow). F. Germany, etc. Hungary, England in
first Hoffman to Italy and England, November.
described as claimed to perhaps North Switzerland, Paris in
entering have seen the America. France, Italy, December.
Europe from epidemic in Iceland. Rome in
the Northeast Halle in February,
rather than February, 1730.
the 1729.
Southeast.
First spread.
Pandemic
period.
1732 Second spread. Over Europe and Germany in
Pandemic America. November.
period. According to France in
Pelargus it January, 1733.
again followed Spain and Italy
the route from in February.
Russia through
the North of
Europe and
then South.
1737 Not generally England, North
recognized. America,
Barbados,
France.
1742 Slow spread Began either on Occurred in Germany, Germany in
1743 from the shores of Germany in Switzerland, January, 1742.
Germany. the Baltic Sea Jan. and Feb., Italy, France, England in
Recurrences or in single 1742, and then Holland, April, 1743.
in Germany cities in disappeared to Belgium,
up until 1745. Germany. reappear in England.
Switzerland in
the spring.
1757 A period of Began either France, Scotland, Barbados, Villalba states
1758 related first in North America, Germany, that the
1761 epidemics America and Finkler states Austria, epidemic in
1762 with spread thence that in 1762 Hungary, 1767 had
1767 complicated to Europe or influenza first Denmark, traveled over
geographic else began started in England, the whole of
pictures and spontaneously Germany and Ireland, Alsace. Europe in a
without clear in both spread thence period of two
cut direction hemispheres. in a very months.
of spread. irregular way
over Western
Europe. Gluge
and Hirsch
state that in
1767 the
disease
appeared
simultaneously
in Europe and
North
America.
1775 Slow spread First First spread to Germany, Italy, Invaded Vienna
1776 through appearances Vienna, and Austria, in June. Made
Western in Autumn of after a England, appearance in
Europe. 1775 in village quiescence Ireland, France. Italy in
of Clausthal in broke out in September. In
the Harz France and England and
mountains. England and France in
possibly October,
spread to November and
America and December.
China.
1780 Western January, 1780 in Spread to Alsace, Three months
1781 Europe and France. Germany and from France to
possibly Italy, and in Brazil.
Brazil and March
China. reported in Rio
de Janiero.
Appeared in
Sept. 1780 on
Southern coast
of China.
1781 One of the most China and Through Siberia China, India, Moscow,
1782 widespread perhaps India and Russia to America, January, 1782.
pandemics. in Autumn of Petrograd, Russia, Riga, Riga,
Abundant 1781 (Hirsch). Finland, Riga, Germany, February.
literature. English Germany, etc. England, Germany,
writers Scotland, March.
connect onset Netherlands, England, April.
with Ireland, France, Scotland, May.
occurrence of Italy, Spain. Ireland,
influenza in France and
the British Italy, June.
Army in India, Spain, August.
Nov., 1781.
Wittwer and
others begin
its history in
Petrograd in
January, 1782.
1788 Throughout all Russia, in West and South. Russia, Germany, Seven months
1789 of Europe. March, 1788. Spread in Hungary, required to
One year “Apparently America in Denmark, cover this
later in independent 1789 England, territory.
America. origin in throughout Scotland,
America in United States France, Italy,
Sept., 1789.” from New York Switzerland.
North and
South and
finally
touching the
West Indies,
South America
and Nova
Scotia.
Recurrences in
single cities of
U. S. in 1790.
1799 Local epidemic Origin in Russia. Spread West and Russia, Galicia,
1800 confined to South. Poland,
Northeastern Germany,
Europe. Denmark.
1802 Local endemic First reported in No clear cut France, Germany,
1803 outbreaks France. direction. Italy, England,
covering Recurrences Switzerland,
considerable until 1805–08. Central Europe.
territory General
which follow dissemination
the last throughout
period by a North America
quiescence of in 1807.
five months.
There
appears to
have been an
unassociated
epidemic
early in 1800
in China and
one in Brazil.
1811 Several 1807, onset in Usually from North and South 1815, one month
1815 epidemics in Massachusetts New England America. from Boston to
1816 North in February. West and New York, and
1824 America and 1815, onset in South. five months to
1826 to some Boston in South Carolina
extent in September. and Brazil.
South 1824, onset in 1824, three
America. Boston in months from
October. Boston to
Georgia.
1827 Widespread
epidemics
throughout
Eastern
Russia and
Siberia.
1830 Extensive China in To Manila in Entire earth. Ten months from
1833 influenza January, September, China to
period made 1830. 1830. Later to Russia. Four
up of two or South Sea months from
three Islands and Russia to
pandemic India. Germany. Two
periods. Appearance in additional
Russia in months
October, 1830, through
with France,
subsequent England,
spread West Scotland,
and South and Sweden,
on to North Belgium,
America (Feb., Switzerland.
1832). Six months
from Germany
to Italy.
1833 Second Probably Asia. After an interval Europe. (America Petrograd in
pandemic in of one year appears to have January.
above period. Europe was escaped this Berlin and
again visited second Constantinople
with an epidemic.) in March.
extensive Denmark and
plague which Sweden,
attacked the France and
same countries Great Britain
in about the in April, Italy
same order. in May.
1836 Third spread in Origin rather West and South Europe, Faroe Almost
1837 above period. obscure, as previously. Islands, simultaneous
possibly in Mexico,(?) invasion at
Russia. India, Java. Petrograd,
Sweden,
Denmark,
Germany and
England;
Egypt, Syria,
France,
Ireland,
Holland, and
Switzerland
one month
later. Italy,
Spain and
Portugal yet
another month
later.
1838 Every year in 1838, February;
1847 this period Island of
with the Bourbon and
exception of Iceland.
1840 showed, 1838,
according to November;
Hirsch, some Australia and
local New Zealand.
epidemic. 1839,
Abyssinia.
1841, Germany,
Hungary,
Ireland.
1842, Belgium,
England,
France, Egypt,
Chili.
1843, Germany,
England,
Iceland,
France, Siberia,
the United
States.
1844, Germany,
England,
Switzerland,
Cayenne.
1845, Germany
and
Switzerland.
1846–1847,
France, Russia,
Constantinople,
Brazil,
England,
Denmark,
Belgium,
Switzerland.
1847 Epidemic Origin Spread not All of the
1848 period uncertain. definite, North countries of
throughout America in Western
Europe 1848. Europe, West
without clear Indies, New
cut direction Zealand,
of spread. Newfoundland,
Sandwich
Islands, Egypt,
Algiers, West
Coast of Africa.
1850 Epidemics 1857, began in 1850–51, 1855, only one
1889 covering August in particularly month
larger or Panama and throughout the between
smaller spread to West whole Western Petrograd and
territory Indies and up coast of South Italy.
every year, and down the America with
but none to Pacific Coast. later spread to
compare in Prevailed in California &
intensity with Europe in Europe.
those of 1831, December. 1852, Australia,
1833, 1836 Tasmania,
and 1847. South America.
1853, Faroe
Islands.
1854, Bavaria.
1855, Europe,
spreading
rapidly West
and South from
Petrograd.
Later in same
year, Brazil.
1857–58,
widespread
epidemic in
both
hemispheres.
1860–70, very
irregular
appearances in
Australia,
Tasmania,
Philadelphia,
the Bermudas,
Holland,
California,
France,
Switzerland,
Africa,
Germany,
Belgium,
Russia,
Denmark,
Sweden and
Turkey.
1874–75,
Extensive
spread in
America,
Germany and
France, with
recurrence one
year later in
eleven areas of
the United
States.
1879, America.
1885–88, Re-
appeared each
year in
Petrograd.
1889, (Spring)
Greenland and
Hudson Bay
territory. (May)
Bokhara in
Turkestan from
where the great
pandemic of
1889–90 is
usually said to
have taken its
origin.
Table I shows that prior to 1510 the information was so limited as to be not entirely
conclusive. We must rely upon the fragmentary descriptions of writers located usually in
or near the intellectual centers who described the disease as they saw it in their city or
country. We have no way of ascertaining what other countries were invaded, and we
possess no method by which we may enumerate the “silent areas,” countries which in
the absence of a chronicler have not been able to transmit their story.
There have been fourteen very widespread epidemics since 1510, all of which might
appropriately be designated as pandemics. They are those of 1510, 1557, 1580, 1593,
1729, 1732, 1762, 1782, 1788, 1830, 1833, 1836, 1847, 1889 and 1918. Some of these have
spread farther than others according to the records, but in nearly all we have reports of
influenza being present in practically every country provided with a historian. We may
find from the table another group in which there have been more or less extensive
epidemics, apparently related, but without any general direction of spread. Such are the
epidemics of 1709–12, 1757–67, 1802–03, 1838–47 and the period 1850–59. Finally,
there are at least ten periods during which relatively small areas have been affected with
epidemic influenza. Such for instance is the year 1688 when the disease was apparently
localized in Great Britain and Ireland; in the year 1693 when England and the adjacent
continent were involved, with little spread elsewhere; and again in 1742, when there was
a slow spread through Germany into adjacent countries with recurrences in the former
up until 1745.
In England the following epidemics have been recorded, some of them in great detail:
1510 and 1557, described by Thomas Short; 1658 by Willis; 1675, by Sydenham; 1729–
1743 by Huxham; 1732–33 by Arbuthnot; 1758 by Whytt; 1762 by Baker and Rutty; 1767
by Heberden; 1775 by Fothergill, who collected observations from many physicians; in
1782 by Gray, Haygath and Carmichael Smith; 1803 by Pearson and Falconer, and a
great number of others; 1833 by Hingeston and others; 1837 by Streeten, Graves, and
Bryson, etc.; 1847 by Peacock, Laycock and many others; also those of 1855 and 1889–
93.
According to Stallybrass, epidemic crests have been reached in England in 1789–90,
1802–03, 1830–32, 1840–41, 1848–51, 1854, 1869–70, 1879, 1890–91, 1898 and 1918
to 1920. The periodicity in multiples of ten years in this latter group is remarkable.
The disease appears to have visited North America in the years 1627, 1647, 1729, 1732,
1737, 1762, 1782, 1789, 1811, 1832, 1850, 1857, 1860, 1874, 1879, 1889, 1900, 1915–1916
and 1918–20. Abbott speaks particularly of the years 1647, 1655 and 1697–98, 1732,
1762 and 1782 and 1889 as being years of especial epidemic prevalence in this country.
Clinical and Epidemiologic Identification.
Up to the present time we have discovered no one characteristic by which we may say
that a case or an epidemic is positively influenza. We have had to rely on the general
symptomatology, which indeed is sufficiently characteristic, although so nearly like the
symptoms of certain other diseases as to make us hesitate to make an absolute
diagnosis, and on the epidemic characteristics. The necessity of an absolute criterion in
the clinical diagnosis is particularly felt in the presence of an isolated interepidemic
case, or a small endemic outbreak. It is at this point that the opinions of epidemiologists
diverge, a divergence which results in two schools of thought in the explanation of the
endemic source of epidemic influenza. Are the interepidemic cases and the small
localized epidemics due to the virus which causes the great pandemics; are they
influenza vera, or are they entirely different diseases with similar symptomatology,
caused by some other microorganism and should they be designated by some other
name? Thus Leichtenstern remarks: “When we go over the records of the years 1173 to
1875, and particularly those of the last century, when the information has been more
extensive and more accurate, we find that scarcely a year has passed without news of the
epidemic occurrence of influenza at some point or other of the earth. Some of these local
and territorial epidemics are merely endemic recurrences of the great pandemics which
have left the germ deposited in the various localities. Others of these small epidemics
probably have nothing to do with influenza vera, but are local outbreaks of catarrhal
fever.”
Contrary to the usual belief, influenza is a disease of quite definite and distinct
characteristics, both clinical and epidemiological. The symptoms are clear cut, with
sudden onset, severe prostration out of all proportion to the clinical symptoms and to
the fever, headache and pain in the back, general body pains, and fever of greater or less
degree. There is usually a lack of leucocytosis or a true leucopenia. In uncomplicated
influenza there are as a rule no localizing symptoms. There may be a slight soreness of
the throat, or a slight cough, but these are at best mild. The fever lasts from three to five
days and disappears, while at the same time all of the symptoms clear up with the
exception of the profound prostration, which as a rule continues for some time,
rendering convalescence surprisingly slow. The pain in the back may remain for a week
or so. This is the description of uncomplicated influenza.
The manner of spread of epidemic influenza is constant in a primary epidemic and the
epidemic as a whole has certain features which render it characteristic. The sporadic
case has as a rule the same quite clear cut clinical symptomatology, but it fails to
manifest the one feature most characteristic of epidemic influenza—a high degree of
contagiousness. Further, although the symptoms in themselves are characteristic, there
is no one pathognomonic sign by which one may say, “this is a case of influenza,” and,
finally other disease conditions such as tonsillitis, frequently resemble it so much as to
cause error in diagnosis.
This becomes, then, one of the problems in the study of influenza epidemiology. It is a
matter of first importance to determine once and for all whether true influenza is with us
always, or whether it appears only at the time of the great pandemics. Upon the answer
to this question more than upon any other one thing rests our choice of methods of
eradication. Any procedures of preventive medicine that may be undertaken on the
assumption that the source of pandemic influenza is to be found in one or a few endemic
foci, such as the one supposed to exist in Turkestan, would fail utterly should the true
condition be that of a universal distribution of a relatively avirulent virus which from
time to time from some unknown cause assumes a highly increased virulence.
Before becoming involved in this very complicated question, let us familiarize
ourselves completely with the characteristics of the pandemic and epidemic variety of
the disease.
General Characteristics of Early Epidemic
Outbreaks.
We have described the symptomatology of uncomplicated influenza. It is rare that this
clinical picture is seen alone during the height of an epidemic. Complications, chiefly of
the respiratory tract, as a rule occur in such a large proportion of individuals that they
very nearly dominate the picture. Although caused by various microorganisms, all of
which appear to be secondary factors the results are so characteristic that in the past,
descriptions of influenza epidemics have usually been descriptions of the complications
of epidemic influenza. Most influenza epidemics are complicated. But we do know from
the experience of recent years as well as from history that relatively uncomplicated
epidemics of influenza have occurred, and that when they do so occur a predominant
characteristic has been the extreme mildness.
It is a fundamental characteristic of pandemic influenza that early cases in widespread
epidemics, as well as in “pre-epidemic increases” are very mild, with a minimum of
respiratory complications and with exceedingly low mortality. It is because we are better
acquainted with the more severe variety that, when these mild precursors appear we are
always in doubt for a time as to their true identity.
In spite of our 20th century erudition, the influenza when it first appeared in mild
form in the American Expeditionary Forces in 1918, for a lack of better knowledge as to
its cause was called “three-day fever.” In Italy in the same year the designation of the
disease progressed from pappataci fever through “Spanish grip” and “summer
influenza,” until finally it was designated influenza, pure and simple. Sampietro in Italy
particularly discussed the possibility of the disease being pappataci fever.
Belogu and Saccone, who wrote in May of 1918, decided that the epidemic was not
influenza in spite of the manifest clinical similarity, chiefly because of the absence of
signs of secondary invasion, such as nervous symptoms, gastro-intestinal symptoms,
and pneumonia, and especially because of the rapid recovery after defervescence. They
also considered the possibility of pappataci fever and dengue, and ruled out both. They
discussed calling the condition “influenza nostras,” but reached no definite conclusion.
Trench fever was also considered by some. United States Public Health Reports for 1918
record that dengue was reported prevalent at Chefoo, China, during the two weeks
ended June 15th, 1918. One week later there was a paragraph stating, “Prevalence of a
disease resembling dengue and affecting about fifty per cent. of the population was
reported at Shanghai, China, June 15, 1918.” It is not impossible that this was influenza.
Zinsser reminds us that Hayfelder, when he saw the influenza as it spread in
Petrograd in November of 1889, remarked its close clinical similarity to the description
of an epidemic of dengue which had prevailed in Constantinople during the preceding
September. Hayfelder, in studying the 1889 epidemic at its onset in Russia and the East,
wrote of “Sibirisches Fieber” which was first looked upon as malaria owing to the
apparently complete absence of the complicating lesions habitually associated in our
minds with influenza.
The same difficulty in early identification was experienced in this country in 1918. At
the end of March of that year the author who was stationed at Camp Sevier, South
Carolina, was one of a Board of Officers appointed to investigate a disease which had
broken out among troops stationed at that camp. At that time the line troops consisted
of three infantry regiments and three machine gun battalions. On the day following a
parade in the city of Greenville a considerable number of men in three out of the six
organizations suddenly took ill. There were a few isolated cases in other organizations,
but in the one infantry regiment and two machine gun battalions the regimental
infirmaries were filled, and some cases were sent to the base hospital. Nearly all were
very mildly ill and exhibited the symptoms of pure uncomplicated influenza as described
above. The onset was sudden, there were the usual pains and aches, the bowels were
regular, there was a feeling of discomfort in the pit of the stomach in many instances,
and there were no sore throats and very little cough. Recovery was as a rule very rapid,
although about a dozen of the entire number developed pneumonia and some of these
died. Physical examination of those only mildly ill and who remained in the regimental
infirmary showed as a rule nothing, but in some instances scattered fine moist rales near
the hilus of the lungs. In some of the organizations the disease was definitely spread
down rows of company tents. Careful bacteriologic examination was made at the time
and the predominating organisms were found to be a gram-negative coccus resembling
micrococcus catarrhalis, and a non-hemolytic streptococcus. This was in uncomplicated
cases.
The Board decided that the disease should be called influenza, but our only basis for
such decision were the clinical symptoms and the contagious character. At that time
none of us dreamed of any possible connection with a severe epidemic to occur later,
and laboratory search for influenza bacilli which was carefully made in view of the
clinical diagnosis showed none of these organisms to be present.
At about the same time a similar epidemic was being experienced at Fort Oglethorpe,
Ga. V. C. Vaughan, in describing this epidemic, remarks: “A disease strongly resembling
influenza became prevalent in the Oglethorpe Camp about March 18, 1918. It soon
assumed pandemic proportions. Within two weeks every organization in Camp Forrest
and the Reserve Officers Training Camp was affected.
“The symptoms were as follows: Headache, pain in the bones and muscles, especially
the muscles of the back, marked prostration, fever, sometimes as high as 104 degrees.
Sometimes there was conjunctivitis, coryza, a rash and possibly nausea, recovery taking
place in a few days.
“In all organizations the epidemic was first located in companies before it became
general.
“The incubation period was short, not over one or two days.
“Some organizations suffered more than others for no apparent reason.
“It is probable that the epidemic disease was recently brought to these camps. If it is
genuine influenza, and the epidemiological features no less than the leading symptoms
seem to point to that disease, there is here offered the most reasonable explanation of
the outbreak which is now possible. No other disease spreads so fast or is so prostrating,
considering its symptoms.”
We will quote at some length from the report of Zinsser of the Chaumont epidemic in
France in 1918, because of the excellence of the description, and particularly because
Zinsser has followed three successive epidemics with successive increases in the
complications and corresponding transformations in the clinical picture. It is worthy of
special note that he has remarked that the influenza, as first seen at Chaumont, showed
nothing in the symptoms that would suggest a predominant respiratory tract infection.
“It will be useful to discuss briefly the early cases as we saw them during the
Chaumont epidemic, not because the observations made there add much that is new
from a clinical point of view, but because they will remove any possible ambiguity
concerning our conception of influenza in its pure uncomplicated form.
“As far as we can judge the little outbreak at headquarters was typical of the first
advent of epidemic influenza in many places. The population of the town, at the time,
consisted of a large office personnel attached to the military administration, scattered as
to billets and places of work; of military units living in barracks and eating at common
messes; and of the townspeople. The epidemic descended upon individual military units
with the suddenness of a storm, striking a considerable percentage of the men, perhaps
most of the susceptible material, within less than a week, and ending almost as abruptly,
with only a few isolated cases trailing behind. Among the more scattered office workers
and among the townspeople it was disseminated more gradually and trailed along for a
longer period.
“These early cases were clinically so uniform that a diagnosis could be made from the
history alone. The onset was almost uniformly abrupt. Typical cases would become ill
suddenly during the night or at a given hour in the day. A patient who had been perfectly
well on going to bed, would suddenly awake with a severe headache, chilliness, malaise
and fever. Others would arise feeling perfectly well in the morning, and at some time
during the day would become aware of headache and pains in the somatic muscles.
“The typical course of these cases may be exemplified by that of J. T. W., a draftsman
attached to the 29th Engineers. He was perfectly well until May 20th, working regularly,
his bowels and appetite normal, considering himself healthy. On May 21st, at 4:30 A.M.
he awoke with a severe headache. He arose, forced himself to eat breakfast and tried to
go to work. He began to feel feverish and chilly. At the same time his headache became
worse, with pains in the back, and burning in the eye balls. At 2 P.M. he reported sick,
and was taken to the hospital with a temperature of 102.8 degrees. At midnight his
temperature dropped to 101.6 degrees, and came down to normal by noon of the 22d. As
he recovered he developed a slight sore throat, great soreness of the legs and a very
slight cough. He recovered completely within a few days.
“These cases with a few exceptions developed no rashes. One or two of them had
blotchy red eruptions which we felt incompetent to characterize dermatologically. The
leucocyte counts ranged from 5,000 to 9,000. A very few went above this. Sometimes
there was a relative increase of lymphocytes, but this was by no means regular. The few
spinal fluids that were examined were normal. As to enlargement of the spleen, we can
say nothing definitely.
“Soon after this we observed the disease in a Division, the 42d, then holding a part of
the line in front of Baccarat. Here it had already developed a somewhat different nature,
due, we believe, to the fact that the men of this Division were not, as were those at
Chaumont, living in a rest area, but were actively engaged in military operations,
working, sleeping, and eating under conditions that involved greater fatigue, less
protection against weather, and greater crowding in sleeping quarters. The Baccarat
cases were much more frequently catarrhal; sore throats, coughs and more serious
respiratory complications were more common. However, they were usually coupled
unmistakably with an underlying typical influenzal attack, sudden onset, pains and short
lived fever. Moreover, there were a great many of the entirely uncomplicated cases
interspersed with the others.
“Still later, in September, October and November, respiratory complications were so
frequent and severe, came on so early in the disease, and the pneumonia mortality
became so high, that the fundamental identity of these later cases with the early three-
day fever might easily have been lost sight of by observers who had not followed the
gradual transformation.
“In consideration of these facts, it is apparent that etiological or other investigations
can throw no light upon the problems of influenza unless they are carried out with
clearer understanding of the differentiation between the complications and the basic
disease.
“The serious respiratory infections of the bronchi and lungs we can set down with
reasonable certainty as complications due, certainly in the overwhelming majority of
cases, to secondary bacterial invaders. It is a matter of considerable difficulty, however,
to know exactly where the basic disease stops and the complications begin; and whether
we must regard the mild sore throat and conjunctival injection which so often
accompany the simple cases as a part of this basic clinical picture, or as the simplest
variety of complication. This is much more than an academic question, since, as we shall
see, the bacteriological analyses of such lesions have played an important role in
etiological investigations.”
Symptoms in Former Epidemics.
The difficulty in making a decision in the presence of an epidemic is very similar to
that of deciding whether the epidemics of former times were in each case influenza.
Some few have been recorded in which the description has corresponded fairly well to
that of primary uncomplicated influenza. Thus, concerning the epidemic of 1557 in
Spain, Thomas Short wrote as follows: “At Mantua Carpentaria, three miles from
Madrid, the epidemic began in August.... There it began with a roughness of the jaws,
small cough, then a strong fever with a pain of the head, back, and legs. Some felt as
though they were corded over the breast and had a weight at the stomach, all of which
continued to the third day at furthest. Then the fever went off, with a sweat or bleeding
at the nose. In some few, it turned to a pleurisy or fatal peripneumony.”
Most of the descriptions, however, have been of a general character and include
descriptions of the complicated periods of the epidemic. One of the more complete of the
early descriptions was that by Lobineau in 1414, who wrote: “C’était une espèce de
rhume, qui causa un tel enrouement que les chastelets furent obligez d’interrompre leurs
séances; on dormoit peu et l’on souffroit de grandes douleurs à la teste, aux reins et par
tout le reste du corps; mais le mal ne fut mortel que pour les vieilles gens de toute
condition.”
With this exception we possess no very good or complete description of influenza
prior to the epidemic of 1510. After that time they have as a rule been detailed enough to
enable identification. Hirsch bases his conclusions concerning the year 1173 chiefly on
the following quotation: “Sub hisdem diebus universus orbus infectus ex aeris nebulosa
corruptione, stomacho catarrhum causante generalem tussim, ad singulorum perniciem,
ad mortem etiam plurimorum immissam vehementer expavite.” Nearly all that we have
to go on in this description is the widespread incidence of the disease and the presence
of respiratory symptoms, particularly cough. In 1323 the description emphasizes only
the high morbidity. Thus, Pietro Buoninsegni writes: “In questo anno e d’Agosto fu un
vento pestilenzia le per lo quale amalò di freddo e di febbre per alcuni dì quasi tutte le
persone in Firenze e questo madesimo fu quais per tutta Italia.” The same author
describes the epidemic of 1327, emphasizing again the high morbidity and in addition
the low death rate: “In detto anno e mese fu quasi per tutto Italia corruzione di febbre
per freddo; ma pochi ne morirono.” Again in 1387, he emphasizes the same two features.
Pasquier, in writing of the epidemic of 1403 in France, says: “En Registres de
Parlement on trouve que le vingt-sixième jour d’avril 1403 y eut une maladie de teste et
de toux, qui courut universellement si grande, que ce jour-là le Greffier ne pût rien
enrégistrer et fut-on contraint d’abandonner le plaidoyé.” Here the high morbidity and
the symptoms, particularly cough and pain, are emphasized. In 1414, Baliolanus
describes again the high morbidity and symptoms, particularly cough and hoarseness:
“Eoque frigore humanis corporibus concepto ... tussis maxima atque raucitas orta unde
nullus pene ordo, aetas et sexus liber evasit.” In 1411, Pasquier writes the following: “En
1411 y eut une autre sorte de maladie dont une infinité de personnes furent touchez, par
laquelle l’on perdoit le boire, le manger et le dormir ... toujours trembloit et avec le estoit
si las et rompu que l’on ne l’osoit toucher en quelques parts. Sans qu’aucune personne
en mourut.”
Subsequent to 1510 descriptions have been as a rule more definite. There are,
however, exceptions to this statement and these fall in the epidemics concerning which
there is some dispute.
Manner of Spread.
More characteristic and more important from an epidemiologic standpoint than the
symptomatology in general, as we have discussed it, is the mode of development of the
epidemic as a whole.
Human intercourse.—Before the days of bacteriology the contagiousness of the
disease was little discussed. Its infectiveness was in fact not universally established until
the epidemic of 1889–1890. One of the first writers who attempted to see in the
influenza a contagious disease was Ch. Calenus who wrote in 1579: “Contagiosum dico
morbum, quia etsi quidem ab occulta quadam coeli influentia, principaliter eum profisci
haud dubium est ... eo in loco quo jam grassabatur inter homines citius eos invadabat,
qui cum affectis frequenter conversabantur, quam eos, qui a consuetudine affectorum
studiose abstinebant.” This keen observer saw that those who carelessly exposed
themselves to close contact with cases of influenza were more likely to develop the
disease than those who protected themselves in every way possible. The “contagious”
school first developed in England, where Haygarth, Hamilton, Gray, Hull, Duggard,
Bardsley, and others, in 1775–1803 described the disease as being not in the air, but in a
specific contagion. Others who considered influenza a contagious disease were Simonin,
Lombard, Petit de Corbeil (1837), Blanc (1860), and Bertholle (1876).
Watson (1847) quotes Cullen as saying that this species of catarrh proceeds from
contagion. He, himself, is not convinced of this fact. He says the visitation is too sudden
and too widely spread to be capable of explanation in that way. “There are facts in the
history of influenza which furnish a strong presumption that the exciting cause of the
disorder is material, not a mere quality of the atmosphere; and that it is at least
portable. The instances are very numerous, too numerous to be attributed to mere
chance, in which the complaint has first broken out in those particular houses of a town
at which travelers have recently arrived from infected places.... What I wish to point out
now is the fact that the influenza pervades large tracts of country in a manner much too
sudden and simultaneous to be consistent with the notion that its prevalence depends
exclusively upon any contagious properties that it may possess.”
Parkes, writing in Reynolds’ System of Medicine in 1876, views the subject more as we
see it today: “The rapidity of the spread would seem at once to negative any connection
between human intercourse and the propagation of the disease; yet there is some
affirmative evidence. It does not appear to follow the great lines of commerce; but when
it has entered towns and villages in which the investigation can be carried on, it is
curious how frequently the first cases have been introduced, and how often the
townspeople nearest the invalids have been first affected. In this country especially,
Haygarth in 1775 and 1782, and Falconer in 1802, collected so many instances of this
that they became convinced that its propagation was due entirely to human intercourse.
So also, when it passes through a house, it occasionally attacks one person after another.
But if it is introduced in this way it afterwards develops with marvelous rapidity, for we
cannot discredit the accounts of many thousands of persons being attacked within a day
or two, which is quite different from the comparatively slow spread of the contagious
diseases. This sudden invasion of a community makes it, to many persons, appear highly
improbable that any effluvia passing off from the sick should thus so rapidly
contaminate the atmosphere of a whole town.

Practical Spring Ldap Using Enterprise Java Based Ldap in Spring Data and Spring Framework 6 2Nd Edition Balaji Varanasi All Chapter

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Practical Spring Ldap Using Enterprise Java Based Ldap in Spring Data and Spring Framework 6 2Nd Edition Balaji Varanasi All Chapter

Uploaded by

Copyright:

Available Formats

Practical Spring LDAP: Using

Enterprise Java-Based LDAP in Spring

Practical Spring LDAP

ISBN 979-8-8688-0001-6 e-ISBN 979-8-8688-0002-3

© Balaji Varanasi and Andres Sacco 2013, 2023

The use of general descriptive names, registered names, trademarks,

Last, if you want to check whether Docker runs correctly on your

Remember that I mentioned that Docker is optional. It’s only

Downloading Source Code

Figure 1-1 Directory server and client interaction

Directory vs. Database

Table 1-1 Employee LDAP Entry

Attribute Type Syntax Description

uid DirectoryString Stores the user id.

Table 1-3 Person Object Class

Required Attributes Optional Attributes

Object Class Attributes Description

organizationalPerson registeredAddress Subclasses that represent a person in an organization.

Figure 1-4 Generic DIT

Figure 1-5 Directory suffix naming conventions

Note DC stands for domain component.

Figure 1-6 Example of an organization directory

cn = Balaji Varanasi + mail=balaji@inflinx.com

Tivoli IBM No https://www.ibm.com/docs/en/i/7.5?topic=services-tivoli- No existing official i

Oracle Oracle No https://www.oracle.com/security/identity- No existing official i

Figure 1-7 Library DIT

2. Java Support for LDAP

Figure 2-1 JNDI architecture

Properties environment = new Properties();

Properties environment = new Properties();

We will closely examine each of these operations in the coming section.

Creating a New Entry

private DirContext getContext() throws NamingException{

public void addEmployee(Employee employee) {

private void closeContext(DirContext context) {

Attribute telephoneAttribute = new BasicAttribute("telephone",

Table 2-2 LDAP Modification Types

Modification Type Description

public void update(String dn, ModificationItem[] items) {

public void remove(String dn) {

public void removeSubtree(DirContext ctx, String root) throws

SearchControls searchControls = new SearchControls();

public void search() {

// Read the multi-valued attribute

for (int i = 0; phoneValues.hasMore(); i++) {

Check How the Operations Work

public class App {

12:23:40.978 [main] INFO com.apress.book.ldap.dao.impl.JndiLdapDaoImpl -

public class App {

//Add and search

private static Employee getEmployee() {

12:23:40.978 [main] INFO com.apress.book.ldap.dao.impl.JndiLdapDaoImpl -

public class App {

//Remove and search

12:23:40.978 [main] INFO com.apress.book.ldap.dao.impl.JndiLdapDaoImpl -

public class App {

//Update and search

12:23:40.978 [main] INFO com.apress.book.ldap.dao.impl.JndiLdapDaoImpl -

3. Introducing Spring LDAP

Figure 3-1 Spring LDAP architecture directory

Documentation and Source Code Spring LDAP

Spring LDAP Packaging

Table 3-1 Spring LDAP Distribution Modules