Practical Spring LDAP: Using Enterprise Java-Based LDAP in Spring Data and Spring Framework 6 2nd Edition Balaji Varanasi pdf download
Practical Spring LDAP: Using Enterprise Java-Based LDAP in Spring Data and Spring Framework 6 2nd Edition Balaji Varanasi pdf download
or textbooks at https://ebookmass.com
_____ Follow the link below to get your download now _____
https://ebookmass.com/product/practical-spring-ldap-using-
enterprise-java-based-ldap-in-spring-data-and-spring-
framework-6-2nd-edition-balaji-varanasi/
https://ebookmass.com/product/pro-spring-security-securing-spring-
framework-6-and-boot-3-based-java-applications-third-edition-massimo-
nardone/
https://ebookmass.com/product/beginning-spring-data-data-access-and-
persistence-for-spring-framework-6-and-boot-3-andres-sacco/
https://ebookmass.com/product/pro-spring-6-with-kotlin-an-in-depth-
guide-to-using-kotlin-apis-in-spring-framework-6-1st-edition-peter-
spath/
Spring 6 Recipes: A Problem-Solution Approach to Spring
Framework Marten Deinum
https://ebookmass.com/product/spring-6-recipes-a-problem-solution-
approach-to-spring-framework-marten-deinum/
https://ebookmass.com/product/pro-spring-6-an-in-depth-guide-to-the-
spring-framework-6th-edition-iuliana-cosmina/
https://ebookmass.com/product/beginning-spring-6-joseph-b-ottinger/
https://ebookmass.com/product/hacking-with-spring-boot-2-3-reactive-
edition/
Andres Sacco
Buenos Aires, Buenos Aires, Argentina
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 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
% docker --version
Docker version 24.0.2, build cb74dfc
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.
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.
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.
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
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.
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
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.
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.
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.
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:
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
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.
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
15 https://www.ietf.org/rfc/rfc2829.txt
16 https://www.ietf.org/rfc/rfc2849.txt
17 https://datatracker.ietf.org/doc/html/rfc1487
18 www.umich.edu/~dirsvcs/ldap/ldap.html
19 https://datatracker.ietf.org/doc/html/rfc2251
20 https://datatracker.ietf.org/doc/html/rfc4519
© 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_2
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.
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.
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.
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");
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.
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.
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:
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.
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.
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.
try {
ctx.destroySubcontext(childName);
} catch (ContextNotEmptyException e) {
removeSubtree(ctx, childName.toString());
ctx.destroySubcontext(childName);
}
}
} catch (NamingException e) {
// Handle the exception and show the description of the problem
} finally {
try {
enumeration.close();
} catch (Exception e) {
// Handle the exception and show the description of the problem
}
}
}
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.
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.
while (searchResults.hasMore()) {
SearchResult result = searchResults.next();
Attributes attributes = result.getAttributes();
String firstName = (String) attributes.get("givenName").get();
If you run the application with the previous block of code, you will see something like Listing 2-13.
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.
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
If you run the application with the previous block of code, you will see something like Listing 2-15.
Check that a new employee appears at the end of the logs with the name “Andres.”
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.
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.
If you run the application with the previous block of code, you will see something like Listing 2-19.
Check that the last entry changed the givenName attribute from “Andres” to “Andy.”
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
© 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_3
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.
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.
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.
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.
Other documents randomly have
different content
neighboring squires with matter for talk over their October, and
the neighboring rectors with topics for sharp sermons against
Whiggery and Popery.
John Wilkes in his newspaper the North Briton accused the king of
lying in his address at the opening of Parliament in 1762, for which
Wilkes was committed to the tower and expelled from the house, of
which he had been a member.
Thirst for news and for information has always prevailed and
newspaper progress undoubtedly must have taken a vigorous spurt
with the invention of type and printing but for the reason that both
church and state joined in its repression. In 1685, at the close of the
reign of King Charles II. there were in all England two newspapers
only, worthy of the name, and both of them were under the strict
supervision of the royal censor.
The family that pays a cent or two for its big morning
newspaper receives a carefully digested review of the political,
economic, social and commercial activities of the entire world
for the previous twenty-four hours. Probably five hundred men
in New York City would pay a thousand dollars a year each for
the commercial information alone that they receive from the
New York Times if they could not obtain it in any other way.
It was not so fifty years ago. These men, whose names have
come down to us, were great editorial writers rather than great
editors of the entire newspaper. Aside from the editorial page their
editions were devoid of genius. The news columns were slovenly in
appearance and dull in narration. They lacked the cunning of
embellishment with the flavor of literature and the charm of fiction.
The book reviews, the critical articles were excellent—but the editors
daubed dullness over everything else. The newspaper of that day is
not to be compared with the newspaper of to-day in general
excellence.
Abbott, Lyman, 89
Acta Diurna, 197
Addison, Joseph, 89
Arnold, Sir Edward to Tennyson, 64
Reid, Whitelaw, 94
Reporter, his beginnings and progress, 1–9;
the political, 8–10;
his unpleasant tasks, 22
Reporters, first announcements of great events
made by, 13
Review, The, 205
Roosevelt, Theodore, 31
Rossetti, 55
Sainte Beuve, 56
Saintsbury, George, 53
Salaries, newspaper, 146
Sayers, Tom, 97
Scott, Sir Walter, 55
Seitz, Don, 102
Sensationalism, wherein harmful, 103
Smith, Sidney, 70
Spectator, The, 205
Stead, William T., 67
Syndicate service, 138
System, 121
Sun, The Evening, 102
Talleyrand, 25
Tatler, The, 205, 206
Thackeray, William M., 174
Times, The New York, 91
Times, The London, 187
Titanic, steamship, loss of: how reported, 44
Tolstoy, 55
Tribune, The Chicago, 91
Tribune, The New York, 91
Page 3
everything happens in New York than
can changed to
everything happens in New York that
can
Page 47
or off Montauk Point: judgment
whether changed to
or off Montauk Point; judgment
whether
Page 60
better expresed by changed to
better expressed by
Page 89
kind to whom lacrimose emotion
changed to
kind to whom lachrymose emotion
Page 94
who succeded Greeley as editor
changed to
who succeeded Greeley as editor
Page 102
exaggeration and breathless
anouncement changed to
exaggeration and breathless
announcement
Page 111
opinion as to the propects for peace
changed to
opinion as to the prospects for peace
Page 198
sent as governor to Cilica changed to
sent as governor to Cilicia
Page 219
accounts the letters from Edinburg
changed to
accounts the letters from Edinburgh
Page 236
Gazette, The Pekin changed to
Gazette, The Peking
Page 220
Lausanne, Stéphane changed to
Lauzanne, Stéphane
*** END OF THE PROJECT GUTENBERG EBOOK THE YOUNG MAN
AND JOURNALISM ***
1.D. The copyright laws of the place where you are located also
govern what you can do with this work. Copyright laws in most
countries are in a constant state of change. If you are outside
the United States, check the laws of your country in addition to
the terms of this agreement before downloading, copying,
displaying, performing, distributing or creating derivative works
based on this work or any other Project Gutenberg™ work. The
Foundation makes no representations concerning the copyright
status of any work in any country other than the United States.
ebookmasss.com