The Entry class is one of the most important one in the API. It describes the base element stored into a LDAP server, and it associates a Dn and some Attributes.
We have two kinds of Entry in the API, depending on the presence of a SchemaManager (...) in the Entry, or not.
We also provide a few extended classes, like the ImmutableEntry, an immutable version of the Entry.
Content
Creating an Entry
We have many ways to create an Entry. Basically, an Entry has a Dn and some Attributes. It can be schema aware, or not. We provide constructors to allow a user to create the kind of Entry he wants.
The simplest way to create an Entry is to call the default constructor. The created entry will have no attributes, and no Dn. We can also make it schema aware by passing a SchemaManager (...). Here is an example:
You can also create an Entry passing a Dn, but no attribute. We can create schema aware entries this way too, passing a SchemaManager (...).
We can also create an entry by copying an existing entry. The created Entry must be schema aware. Here is an example:
Last, not least, it's possible to create an Entry using a list of LDIF formated attributes. An example worth ten lines of documentation, so let's see what it means.
First, we will create a schema agnostic entry:
We can also provide a complete LDIF file (except that we can't add the dn):
One can also combine LDIF and variables like in this example (note that if you use a variable, the attribute must not be followed by the ':' char):
Modifying an Entry
We have four methods available that modify the Entry content : add, remove, put and set. We will review those four methods in the following paragraphs.
Adding Attributes
Two methods can be used to add some attribute into an Entry, depending on the fact that we will add some value without replacing an existing attribute with the same name (and we use the add method for that), or replace it with a new attribute (and we use the put method for that).
In any case, we can add either an empty attribute, or an attribute with some values. Those values can be Strings, byte[] or Values. The added attributes can be schema aware, and we can also provide a user provided name for the attribute type.
add() methods
The first method makes it possible to add some existing Attribute to an Entry. Let's see how it works:
Otherwise, we can add a new attribute and values into the Entry by passing both parameters. We can also pass an AttributeType (...) to the add() method, making the added attribute schema aware. Note that if the Entry itself is already schema aware, this is not necessary.
Here are some examples, the first one with a schema aware Entry, the second one with a schema agnostic Entry:
When manipulating a schema agnostic Entry, do not expect that the attribute type will be recognized if you inject schema aware attributes.
put() methods
The big difference with the add method is that the attribute is not added, it will replace an existing one. let's see with an example :
Removing Attributes
We can remove either an attribute having a specific value, or an entire attribute. In order to remove a complete attribute, you just have to provide the attribute's name, and use the removeAttributes method.
Here are some example for both usages :
Storing a Dn
It's also possible to store a new Dn into the Entry, using the setDn() method. It will replace an existing Dn. This method takes either a Dn instance, or a _String.
Attribute data access methods
The API provides convenient methods to access the Entry content, and to check if it contains some attributes or some values. We will shortly expose those methods in the following paragraphs.
Contains method
The contains and containsAttributes methods check that the Entry contain a couple of <attributeType/values> for the first set of methods, and for the existence of a specific attribute for the second method.
One can check for the existence of a specific value for a given attribute, or even for multiple values for a specific attribute. Let's see the contains method in action:
get(AttributeType) and get(String)
Returns the Attribute having the given name if it exists. The following test demonstrates its usage:
getAttributeTypes()
This method returns the list of AttributeType (...)s stored into the Entry.
This method is only valuable if the Entry is schema aware !
Here is an example of usage:
This code produces the following output:
getDn()
This method returns the Entry's Dn.
hasObjectClass methods
The hasObjectClass() methods are used to discover if an Entry has a specific ObjectClass. This is a convenient method, as it's possible to do the same thing with a contains() call, but with one less parameter (you don't have to provide the "ObjectClass" as a first parameter).
Here is an example using the two existing methods:
Obviously, dealing with a schema agnostic Entry, those methods are more strict. You have to use the exact ObjectClasses case sensitive trimmed names (in the previous example, we can use upper cased names, even with spaces around the names).
Also note that the hasObjectClass method used with AttributeType (...) does not work on a schema agnostic entry.
Miscellaneous methods
We also have some other methods which can be used on an Entry. Here is a list of those methods.
clear()
This method removes all the added Attributes from this Entry. The Dn remains the same.
clone()
Creates a copy of the current Entry. All the Attributes are also cloned.
iterator()
Allows an iteration over all the Attributes. The following examples shows how this can be used:
This produces the following output:
Note that the Attribute order is not guaranteed.
isSchemaAware()
Tells if the ¨Entry has an associated SchemaManager (...).
size()
Returns the number of Attribute stored in the Entry.
equals(Object)
Check if two Entries are equal or not. It's important to understand that depending on whether the entry is schema aware or not, the comparison will be processed differently. Typically, the attribute's name must be equals when they have been trimmed and lower cased if the entry is not schema aware, and we can't compare an attribute named 'cn' with another one named '2.5.4.3' in this case (the Entry must be schema aware to allow such comparison). More important, the values must be identical (same casing, same spaces) in this case.
The attribute's values order is irrelevant.
Here are one example with a schema agnostic Entry:
and another example with a schema aware Entry: