Update documentation issues and update links (#470)

Maxim Thomas

31.30.2025 d80bb3a1a7256866b4cc1a6611e427cc985bcfe8

Update documentation issues and update links (#470)

 opendj-doc-generated-ref/src/main/asciidoc/admin-guide/chap-connection-handlers.adoc

@@ -12,7 +12,7 @@
  information: "Portions copyright [year] [name of copyright owner]".
 
  Copyright 2017 ForgeRock AS.
  Portions Copyright 2024 3A Systems LLC.
  Portions Copyright 2024-2025 3A Systems LLC.
////

:figure-caption!:
@@ -1251,7 +1251,8 @@

There are many possibilities when configuring HTTP authorization mechanisms. __This procedure shows only one OAuth 2.0 example.__

The example that follows demonstrates an OpenDJ directory server configured for tests (insecure connections) to request OAuth 2.0 token information from OpenAM. Download ForgeRock Access Management or OpenAM software from link:https://backstage.forgerock.com/downloads/[https://backstage.forgerock.com/downloads/, window=\_top].
The example that follows demonstrates an OpenDJ directory server configured for tests (insecure connections) to request OAuth 2.0 token information from OpenAM.
Download OpenAM software from link:https://github.com/OpenIdentityPlatform/OpenAM/releases[https://github.com/OpenIdentityPlatform/OpenAM/releases, window=\_top].

[#d67723e3953]
.Settings for OAuth 2.0 Example With OpenAM

 opendj-doc-generated-ref/src/main/asciidoc/admin-guide/chap-monitoring.adoc

@@ -12,7 +12,7 @@
  information: "Portions copyright [year] [name of copyright owner]".
 
  Copyright 2017 ForgeRock AS.
  Portions Copyright 2024 3A Systems LLC.
  Portions Copyright 2024-2025 3A Systems LLC.
////

:figure-caption!:
@@ -40,7 +40,7 @@

OpenDJ exposes monitoring information over LDAP under the entry `cn=monitor`. Many different types of information are exposed. The following example shows monitoring information about the `userRoot` backend holding Example.com data:

Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"] in the __Reference__)
Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"] in the __Reference__)

[source, console]
----
@@ -163,7 +163,7 @@

OpenDJ provides JMX-based monitoring. A number of tools support JMX, including `jconsole` and `jvisualvm`, which are bundled with the Sun/Oracle Java platform. JMX is not configured by default. Use the `dsconfig` command to configure the JMX connection handler:

Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"] in the __Reference__)
Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"] in the __Reference__)

Configure the server to activate JMX access. The following example uses the reserved port number, 1689:

@@ -301,7 +301,7 @@

By default OpenDJ stores access and errors logs, and a server process ID file under the `logs/` directory. For the replication service, OpenDJ also keeps a replication log there. You can also configure a debug log. You can also configure policies about how logs are rotated, and how they are retained. You configure logging using the `dsconfig` command.

Each log depends on a __log publisher__, whose type corresponds to the type of log. OpenDJ provides a number of file-based log publishers out of the box, and supports the ForgeRock common audit event framework, sometimes referred to as Common Audit. The ForgeRock common audit event framework provides log handlers for publishing to CSV files, relational databases, and the UNIX system log (Syslog) as described in xref:#log-common-audit["Common ForgeRock Access Logs"]. The framework makes it possible to plug in additional handlers as well.
Each log depends on a __log publisher__, whose type corresponds to the type of log. OpenDJ provides a number of file-based log publishers out of the box, and supports the Open Identity Platform common audit event framework, sometimes referred to as Common Audit. The ForgeRock common audit event framework provides log handlers for publishing to CSV files, relational databases, and the UNIX system log (Syslog) as described in xref:#log-common-audit["Common ForgeRock Access Logs"]. The framework makes it possible to plug in additional handlers as well.

[#log-access]
==== Access Logs
@@ -325,14 +325,14 @@


[#log-common-audit]
==== Common ForgeRock Access Logs
==== Common Open Identity Platform Access Logs

In addition to the default file-based access log formats, OpenDJ directory server supports the ForgeRock common audit event framework. OpenDJ uses the framework to write access logs in formats that are compatible with all products using the framework. The framework uses transaction IDs that make it easy to correlate requests as they traverse the platform. This makes it easier to monitor activity and to enrich reports.
In addition to the default file-based access log formats, OpenDJ directory server supports the Open Identity Platform common audit event framework. OpenDJ uses the framework to write access logs in formats that are compatible with all products using the framework. The framework uses transaction IDs that make it easy to correlate requests as they traverse the platform. This makes it easier to monitor activity and to enrich reports.

Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"] in the __Reference__)
Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"] in the __Reference__)

The ForgeRock common audit event framework is built around audit event handlers. Audit event handlers can encapsulate their own configurations. Audit event handlers are the same in each product in the ForgeRock platform. As a result, you can plug in custom handlers that comply with the framework without having to upgrade OpenDJ directory server.
The ForgeRock common audit event framework includes handlers for logging audit event messages to local files and facilities, as well as to remote systems. Handlers for the following are supported:
The Open Identity Platform common audit event framework is built around audit event handlers. Audit event handlers can encapsulate their own configurations. Audit event handlers are the same in each product in the Open Identity Platform. As a result, you can plug in custom handlers that comply with the framework without having to upgrade OpenDJ directory server.
The Open Identity Platform common audit event framework includes handlers for logging audit event messages to local files and facilities, as well as to remote systems. Handlers for the following are supported:

* CSV files, with support for tamper-evident logs.
+
@@ -350,7 +350,7 @@
+
Although it is rarely used for access events, you can configure the Syslog handler as an external log publisher that logs access messages to the UNIX Syslog facility.

The ForgeRock common audit event framework supports a variety of audit event topics. OpenDJ currently supports handling for access events, which are system boundary events such as the initial request and final response to that request. In other words, the implementation in OpenDJ is focused only on access logging. Based on the connection handler for the request, OpenDJ divides access events into `ldap-access` events and `http-access` events.
The Open Identity Platform common audit event framework supports a variety of audit event topics. OpenDJ currently supports handling for access events, which are system boundary events such as the initial request and final response to that request. In other words, the implementation in OpenDJ is focused only on access logging. Based on the connection handler for the request, OpenDJ divides access events into `ldap-access` events and `http-access` events.
To enable common audit-based logging, follow one of these procedures:

* xref:#log-common-audit-ldap-csv["To Enable LDAP CSV Access Logs"]
@@ -692,7 +692,7 @@
[#log-common-audit-trust-transaction-ids]
.To Trust Transaction IDs
====
Client applications using the ForgeRock common audit event framework send transaction IDs with their requests. The transaction IDs are used to correlate audit events for monitoring and reporting that trace the request through multiple applications.
Client applications using the Open Identity Platform common audit event framework send transaction IDs with their requests. The transaction IDs are used to correlate audit events for monitoring and reporting that trace the request through multiple applications.

Transaction IDs are sent over LDAP using an internal OpenDJ request control. They are sent over HTTP in an HTTP header.

@@ -1702,7 +1702,7 @@

For the HTTP Connection Handler, OpenDJ maintains a separate access log in `logs/http-access`. This access log, by default configured as the File Based HTTP Access Log Publisher, uses a different format than the LDAP access log. This HTTP access log uses link:http://www.w3.org/TR/WD-logfile.html[Extended Log File Format, window=\_blank] with fields described in link:http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/676400bc-8969-4aa7-851a-9319490a9bbb.mspx?mfr=true[Microsoft's implementation, window=\_blank] as well.

Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"] in the __Reference__)
Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"] in the __Reference__)
--
The following default fields are shown here in the order they occur in the log file:

@@ -1755,7 +1755,7 @@
Execution time in milliseconds needed by OpenDJ to service the HTTP request

`x-transaction-id`::
ForgeRock common audit event framework transaction ID for the request
Open Identity Platform common audit event framework transaction ID for the request

+
This defaults to `0` unless you configure OpenDJ to trust transaction IDs as described in xref:#log-common-audit-trust-transaction-ids["To Trust Transaction IDs"].

 opendj-doc-generated-ref/src/main/asciidoc/install-guide/chap-install.adoc

@@ -12,7 +12,7 @@
  information: "Portions copyright [year] [name of copyright owner]".
 
  Copyright 2017 ForgeRock AS.
  Portions Copyright 2024 3A Systems LLC.
  Portions Copyright 2024-2025 3A Systems LLC.
////

:figure-caption!:
@@ -62,7 +62,7 @@
+
Antivirus and intrusion detection systems that do a deep inspection of database files are not compatible with OpenDJ directory server. Disable antivirus and intrusion detection systems, or at least prevent them from operating on OpenDJ directory server files.

. Download enterprise software releases through the ForgeRock link:https://backstage.forgerock.com/[BackStage, window=\_blank] site. ForgeRock enterprise releases are thoroughly validated builds for ForgeRock customers who run OpenDJ in production deployments, and for those who want to try or test with release builds.
. Download software releases from the link:https://github.com/OpenIdentityPlatform/OpenDJ/releases[GitHub, window=\_blank].
+
--
The following OpenDJ 3.5.3 server software is available:

 opendj-doc-generated-ref/src/main/asciidoc/install-guide/chap-upgrade.adoc

@@ -12,7 +12,7 @@
  information: "Portions copyright [year] [name of copyright owner]".
 
  Copyright 2017 ForgeRock AS.
  Portions Copyright 2024 3A Systems LLC.
  Portions Copyright 2024-2025 3A Systems LLC.
////

:figure-caption!:
@@ -25,7 +25,7 @@

This chapter covers upgrade from previous versions.

If the OpenDJ directory server version is older than 2.6.0, you must upgrade your deployment to use at least OpenDJ directory server 2.6.0 before following the procedures in this chapter. For details on upgrading to that version, see link:https://backstage.forgerock.com/docs/opendj/2.6/install-guide/#chap-upgrade[Upgrading to OpenDJ 2.6.0, window=\_blank].
If the OpenDJ directory server version is older than 2.6.0, you must upgrade your deployment to use at least OpenDJ directory server 2.6.0 before following the procedures in this chapter.

[TIP]
====
@@ -70,7 +70,7 @@

. (Optional)  If you are upgrading to OpenDJ OEM edition from OpenDJ 2.6, make sure there is enough disk space to export all of the data to LDIF files.

. Download enterprise software releases through the ForgeRock link:https://backstage.forgerock.com/[BackStage, window=\_blank] site. ForgeRock enterprise releases are thoroughly validated builds for ForgeRock customers who run OpenDJ in production deployments, and for those who want to try or test with release builds.
. Download enterprise releases from the link:https://github.com/OpenIdentityPlatform/OpenDJ/releases[GitHub, window=\_blank] site.

. (Optional)  If you are upgrading OpenDJ directory server on Windows, and OpenDJ is registered as a Windows service, disable OpenDJ as a Windows service before upgrade, as in the following example:
+

 opendj-doc-generated-ref/src/main/asciidoc/reference/appendix-rest2ldap-3-0.adoc

@@ -12,7 +12,7 @@
  information: "Portions copyright [year] [name of copyright owner]".
 
  Copyright 2017 ForgeRock AS.
  Portions Copyright 2024 3A Systems LLC.
  Portions Copyright 2024-2025 3A Systems LLC.
////

:figure-caption!:
@@ -38,7 +38,7 @@
--
The JSON format configuration can hold the following configuration objects. Some of the configuration settings are available only in the REST LDAP gateway configuration. The order here is the order shown in the default configuration file:

Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"])
Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"])

"ldapConnectionFactories" (required, gateway only)::
Configures how the gateway connects to LDAP servers. This entire configuration object applies only to the REST to LDAP gateway.
@@ -198,7 +198,7 @@
The gateway authenticates by simple bind using the credentials specified:
+

[source, javascript]
[source, json]
----
{
    "authentication": {
@@ -334,10 +334,10 @@


"proxyAuthzIdTemplate" (gateway only)::
Specifies the template to derive the authorization ID from the security context created during authentication. Use `{dn}` to indicate the user's bind DN or `{id}` to indicate the user name provided for authentication.
Specifies the template to derive the authorization ID from the security context created during authentication. Use `\{dn\}` to indicate the user's bind DN or `\{id\}` to indicate the user name provided for authentication.

+
Default: "dn:{dn}"
Default: "dn:\{dn\}"

"mappings"::
For each collection URI such as `/users` and `/groups`, you configure a mapping between the JSON resource returned over HTTP, and the LDAP entry returned by the directory service.
@@ -401,7 +401,7 @@
* RDN and resource ID are both derived from a single user attribute in the LDAP entry, as in the following example, where the `uid` attribute is the RDN and its value is the JSON resource ID:
+

[source, javascript]
[source, json]
----
{
    "namingStrategy": {
@@ -414,7 +414,7 @@
* RDN and resource ID are derived from separate user attributes in the LDAP entry, as in the following example where the RDN attribute is `uid` but the JSON resource ID is the value of the `mail` attribute:
+

[source, javascript]
[source, json]
----
{
    "namingStrategy": {
@@ -428,7 +428,7 @@
* RDN is derived from a user attribute and the resource ID from an operational attribute in the LDAP entry, as in the following example, where the RDN attribute is `uid` but the JSON resource ID is the value of the `entryUUID` operational attribute:
+

[source, javascript]
[source, json]
----
{
    "namingStrategy": {
@@ -444,7 +444,7 @@
LDAP attributes to include during LDAP add operations as an array of type-value lists, such as the following example:
+

[source, javascript]
[source, json]
----
{
    "additionalLDAPAttributes": [
@@ -476,7 +476,7 @@
This can be useful as in the default case where each JSON resource "schemas" takes the SCIM URN, and so the value is not related to the underlying LDAP entries:
+

[source, javascript]
[source, json]
----
{
    "schemas": {
@@ -494,7 +494,7 @@
Simple mappings are used where the correspondence between JSON fields and LDAP attributes is one-to-one:
+

[source, javascript]
[source, json]
----
{
    "userName": {
@@ -555,7 +555,7 @@
This mapping works for LDAP attributes whose values reference other entries. This is shown in the following example from the default configuration. The LDAP `manager` attribute values are user entry DNs. Here, the JSON `manager` field takes the user ID and name from the entry referenced by the LDAP attribute. On updates, changes to the JSON manager `_id` affect which manager entry is referenced, yet any changes to the manager's name are discarded, because changing managers only affects which user entry to point to, not the referenced user's name:
+

[source, javascript]
[source, json]
----
{
    "manager": {
@@ -589,7 +589,7 @@
Babs Jensen's manager in the sample LDAP data is Torrey Rigden, who has user ID `trigden`. Babs's entry has `manager: uid=trigden,ou=People,dc=example,dc=com`. With this mapping, the resulting JSON field is the following:
+

[source, javascript]
[source, json]
----
{
    "manager": [
@@ -631,7 +631,7 @@
The default mappings expose a SCIM view of user and group data:
+

[source, javascript]
[source, json]
----
{
    "/users": {

 opendj-doc-generated-ref/src/main/asciidoc/reference/appendix-rest2ldap.adoc

@@ -12,7 +12,7 @@
  information: "Portions copyright [year] [name of copyright owner]".
 
  Copyright 2017 ForgeRock AS.
  Portions Copyright 2024 3A Systems LLC.
  Portions Copyright 2024-2025 3A Systems LLC.
////

:figure-caption!:
@@ -30,7 +30,7 @@

* The OpenDJ REST to LDAP gateway runs in a Servlet container independent from the directory service. You configure the gateway to access the directory service by editing configuration files for the gateway web application.

Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"])
Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"])

[NOTE]
====
@@ -246,7 +246,7 @@
The gateway accesses this array of LDAP servers if primary LDAP servers cannot be contacted. These might be LDAP servers in the same remote data center, for example:
+

[source, javascript]
[source, json]
----
{
    "secondaryLdapServers": [
@@ -282,7 +282,7 @@
The gateway authenticates by simple bind using the credentials specified:
+

[source, javascript]
[source, json]
----
{
    "authentication": {
@@ -411,13 +411,13 @@
The template to produce the bind DN from the HTTP Basic user name.

+
A single occurrence of the string `{username}` is replaced in the template with the HTTP Basic user name.
A single occurrence of the string `\{username\}` is replaced in the template with the HTTP Basic user name.

+
For example, if the user name is also the UID of the LDAP entry, use `uid={username},ou=People,dc=example,dc=com`.
For example, if the user name is also the UID of the LDAP entry, use `uid=\{username\},ou=People,dc=example,dc=com`.

+
Default: `{username}`
Default: `\{username\}`

========

@@ -438,13 +438,13 @@
The template to produce the authorization ID from the HTTP Basic user name.

+
A single occurrence of the string `{username}` is replaced in the template with the HTTP Basic user name.
A single occurrence of the string `\{username\}` is replaced in the template with the HTTP Basic user name.

+
If the user name is also the authorization ID, use `u:{username}`.
If the user name is also the authorization ID, use `u:\{username\}`.

+
If the user name is the LDAP bind DN, use `dn:{username}`.
If the user name is the LDAP bind DN, use `dn:\{username\}`.

========

@@ -483,10 +483,10 @@
The template for the filter of the LDAP search.

+
A single occurrence of the string `{username}` is replaced in the template with the HTTP Basic user name.
A single occurrence of the string `\{username\}` is replaced in the template with the HTTP Basic user name.

+
If the user name is also the UID, use `(&(uid={username})(objectClass=inetOrgPerson))`.
If the user name is also the UID, use `(&(uid=\{username\})(objectClass=inetOrgPerson))`.

========

@@ -581,7 +581,7 @@
This template must start with `u:` or `dn:`.

+
For example, if token resolution returns a JSON document where the value of the `uid` field is the UID of the user entry in the directory, you might use `u:{uid}` or `dn:{uid},ou=People,dc=example,dc=com`.
For example, if token resolution returns a JSON document where the value of the `uid` field is the UID of the user entry in the directory, you might use `u:\{uid\}` or `dn:\{uid\},ou=People,dc=example,dc=com`.

========

@@ -631,13 +631,13 @@
This template must start with `u:` or `dn:`.

+
For example, if token resolution returns a JSON document where the value of the `username` field is the UID of the user entry in the directory, you might use `u:{username}` or `dn:{username},ou=People,dc=example,dc=com`.
For example, if token resolution returns a JSON document where the value of the `username` field is the UID of the user entry in the directory, you might use `u:\{username\}` or `dn:\{username\},ou=People,dc=example,dc=com`.

`cts`::
Configuration for resolving OAuth 2.0 tokens when the directory service acts as OpenAM's CTS store.

+
OpenAM's CTS store is constrained to a specific layout. The `authzIdTemplate` must therefore use `{userName/0}` for the user identifier.
OpenAM's CTS store is constrained to a specific layout. The `authzIdTemplate` must therefore use `\{userName/0}` for the user identifier.

+
This mechanism makes it possible to resolve access tokens by making a request to the CTS directory service, without making a request to OpenAM. __This mechanism does not, however, ensure that the token requested will have already been replicated to the directory server where the request is routed.__
@@ -848,7 +848,7 @@

* `ou=tablets,ou=devices,dc=example,dc=com`

The subresource name `/{type}` would be substituted in actual paths with `/others`, `/pcs`, `/phones`, and `/tablets`. The DN template for the subresource would specify `ou={type},ou=devices,dc=example,dc=com` in order to locate the entries in the correct LDAP organizational unit. In the example, REST to LDAP substitutes `{type}` in the DN template with the type defined in the request URL path.
The subresource name `/\{type\}` would be substituted in actual paths with `/others`, `/pcs`, `/phones`, and `/tablets`. The DN template for the subresource would specify `ou=\{type\},ou=devices,dc=example,dc=com` in order to locate the entries in the correct LDAP organizational unit. In the example, REST to LDAP substitutes `\{type\}` in the DN template with the type defined in the request URL path.

For details on subresource configuration, see xref:#rest-subresource-properties["Sub-Resource Properties"].

@@ -1091,7 +1091,7 @@
* RDN and resource ID are both derived from a single user attribute in the LDAP entry, as in the following example, where the `uid` attribute is the RDN and its value is the JSON resource ID:
+

[source, javascript]
[source, json]
----
{
    "namingStrategy": {
@@ -1104,7 +1104,7 @@
* RDN and resource ID are derived from separate user attributes in the LDAP entry, as in the following example, where the RDN attribute is `uid`, but the JSON resource ID is the value of the `mail` attribute:
+

[source, javascript]
[source, json]
----
{
    "namingStrategy": {
@@ -1118,7 +1118,7 @@
* RDN is derived from a user attribute and the resource ID from an operational attribute in the LDAP entry, as in the following example, where the RDN attribute is `uid`, but the JSON resource ID is the value of the `entryUUID` operational attribute:
+

[source, javascript]
[source, json]
----
{
    "namingStrategy": {

 opendj-doc-generated-ref/src/main/asciidoc/server-dev-guide/chap-rest-operations-3-0.adoc

@@ -12,7 +12,7 @@
  information: "Portions copyright [year] [name of copyright owner]".
 
  Copyright 2017 ForgeRock AS.
  Portions Copyright 2024 3A Systems LLC.
  Portions Copyright 2024-2025 3A Systems LLC.
////

:figure-caption!:
@@ -51,9 +51,9 @@

Before trying the examples, enable HTTP access to OpenDJ directory server as described in xref:../admin-guide/chap-connection-handlers.adoc#setup-rest2ldap-3-0["RESTful Client Access (3.0)"] in the __Administration Guide__. The examples in this chapter use HTTP, but the procedure also shows how to set up HTTPS access to the server.

Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"] in the __Reference__.)
Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"] in the __Reference__.)

The OpenDJ REST API is built on a common ForgeRock HTTP-based REST API for interacting with JSON Resources. All APIs built on this common layer let you perform the following operations. For an overview of ForgeRock common REST APIs, see xref:chap-rest-operations.adoc#sec-about-crest["About ForgeRock Common REST"].
The OpenDJ REST API is built on a common Open Identity Platform HTTP-based REST API for interacting with JSON Resources. All APIs built on this common layer let you perform the following operations. For an overview of Open Identity Platform common REST APIs, see xref:chap-rest-operations.adoc#sec-about-crest["About Common REST"].

[#authenticate-rest-3-0]
=== Authenticating Over REST (3.0)

 opendj-doc-generated-ref/src/main/asciidoc/server-dev-guide/chap-rest-operations.adoc

@@ -12,7 +12,7 @@
  information: "Portions copyright [year] [name of copyright owner]".
 
  Copyright 2017 ForgeRock AS.
  Portions Copyright 2024 3A Systems LLC.
  Portions Copyright 2024-2025 3A Systems LLC.
////

:figure-caption!:
@@ -53,14 +53,14 @@

Before trying the examples, enable HTTP access to OpenDJ directory server as described in xref:../admin-guide/chap-connection-handlers.adoc#setup-rest2ldap-endpoint["To Set Up REST Access to User Data"] in the __Administration Guide__. (If you are using OpenDJ 3.0, see xref:../admin-guide/chap-connection-handlers.adoc#setup-rest2ldap-3-0["RESTful Client Access (3.0)"] in the __Administration Guide__ instead.) The examples in this chapter use HTTP, but the procedure also shows how to set up HTTPS access to the server.

Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"] in the __Reference__.)
Interface stability: Evolving (See xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"] in the __Reference__.)

The OpenDJ REST API is built on a common ForgeRock HTTP-based REST API for interacting with JSON Resources. All APIs built on this common layer let you perform the following operations.
The OpenDJ REST API is built on a common Open Identity Platform HTTP-based REST API for interacting with JSON Resources. All APIs built on this common layer let you perform the following operations.

[#sec-about-crest]
=== About ForgeRock Common REST
=== About Common REST

For many REST APIs that are not defined by external standards, ForgeRock products provide common ways to access web resources and collections of resources. This section covers what is common across products. Adapt the examples to your types of resources and to your deployment.
For many REST APIs that are not defined by external standards, Open Identity Platform products provide common ways to access web resources and collections of resources. This section covers what is common across products. Adapt the examples to your types of resources and to your deployment.

[#about-crest-resources]
==== Common REST Resources
@@ -375,7 +375,7 @@

* *set semantics array*, where the elements are not ordered, and duplicates are not allowed.

ForgeRock PATCH supports several different `operations`. The following sections show each of these operations, along with options for the `field` and `value`:
Open Identity Platform PATCH supports several different `operations`. The following sections show each of these operations, along with options for the `field` and `value`:

[#crest-patch-add]
===== Patch Operation: Add
@@ -396,7 +396,7 @@

As an example, start with the following list semantic array resource:

[source, javascript]
[source, json]
----
{
    "fruits" : [ "orange", "apple" ]
@@ -404,7 +404,7 @@
----
The following add operation includes the pineapple to the end of the list of fruits, as indicated by the `-` at the end of the `fruits` array.

[source, javascript]
[source, json]
----
{
    "operation" : "add",
@@ -414,7 +414,7 @@
----
The following is the resulting resource:

[source, javascript]
[source, json]
----
{
    "fruits" : [ "orange", "apple", "pineapple" ]
@@ -429,7 +429,7 @@

The following `copy` operation takes the value from the source named `/hot/potato`, and then runs a `replace` operation on the target value, `/hot/tamale`.

[source, javascript]
[source, json]
----
[
  {
@@ -447,7 +447,7 @@

The `increment` operation changes the value or values of the target field by the amount you specify. The value that you include must be one number, and may be positive or negative. The value of the target field must accept numbers. The following `increment` operation adds `1000` to the target value of `/user/payment`.

[source, javascript]
[source, json]
----
[
  {
@@ -467,7 +467,7 @@

The following `move` operation is equivalent to a `remove` operation on the source named `/hot/potato`, followed by a `replace` operation on the target value, `/hot/tamale`.

[source, javascript]
[source, json]
----
[
  {
@@ -485,7 +485,7 @@

The `remove` operation ensures that the target field no longer contains the value provided. If the remove operation does not include a value, the operation removes the field. The following `remove` deletes the value of the `phoneNumber`, along with the field.

[source, javascript]
[source, json]
----
[
  {
@@ -500,7 +500,7 @@
* *List semantic arrays*: A `remove` operation deletes the specified element in the array. For example, the following operation removes the first phone number, based on its array index (zero-based):
+

[source, javascript]
[source, json]
----
[
   {
@@ -521,7 +521,7 @@

The following `replace` operation removes the existing `telephoneNumber` value for the user, and then adds the new value of `+1 408 555 9999`.

[source, javascript]
[source, json]
----
[
  {
@@ -533,15 +533,15 @@
----
A PATCH replace operation on a list semantic array works in the same fashion as a PATCH remove operation. The following example demonstrates how the effect of both operations. Start with the following resource:

[source, javascript]
[source, json]
----
{
    "fruits" : [ "apple", "orange", "kiwi", "lime" ],
    "fruits" : [ "apple", "orange", "kiwi", "lime" ]
}
----
Apply the following operations on that resource:

[source, javascript]
[source, json]
----
[
  {
@@ -562,7 +562,7 @@
----
[
  {
    "fruits" : [ "orange", "kiwi", "lime" ],
    "fruits" : [ "orange", "kiwi", "lime" ]
  }
]
----
@@ -583,7 +583,7 @@

The `transform` operation changes the value of a field based on a script or some other data transformation command. The following `transform` operation takes the value from the field named `/objects`, and applies the `something.js` script as shown:

[source, javascript]
[source, json]
----
[
  {
@@ -595,7 +595,7 @@
        "file" : "something.js"
      }
    }
  },
  }
]
----

@@ -2306,7 +2306,7 @@
[#mime-types-rest]
=== Working With Alternative Content Types

OpenDJ generally maps JSON resources to LDAP entries. Some resources such as profile photos, however, are best expressed with other MIME types. ForgeRock common REST lets your applications make HTTP multipart requests, so you can work with other MIME types differently from regular JSON resources. This is done using the `_mimeType` parameter described in xref:#about-crest-read["Read"].
OpenDJ generally maps JSON resources to LDAP entries. Some resources such as profile photos, however, are best expressed with other MIME types. Open Identity Platform common REST lets your applications make HTTP multipart requests, so you can work with other MIME types differently from regular JSON resources. This is done using the `_mimeType` parameter described in xref:#about-crest-read["Read"].
This section includes the following procedures:

* xref:#mime-types-rest-mapping["To Map an Alternative Content Type"]

 opendj-doc-generated-ref/src/main/asciidoc/server-dev-guide/chap-writing-plugins.adoc

@@ -12,7 +12,7 @@
  information: "Portions copyright [year] [name of copyright owner]".
 
  Copyright 2017 ForgeRock AS.
  Portions Copyright 2024 3A Systems LLC.
  Portions Copyright 2024-2025 3A Systems LLC.
////

:figure-caption!:
@@ -35,9 +35,9 @@

[IMPORTANT]
====
ForgeRock supports customers using standard plugins delivered as part of OpenDJ directory server.
Open Identity Platform Approved Vendors support customers using standard plugins delivered as part of OpenDJ directory server.

If you deploy with custom plugins and need support in production, contact link:mailto:info\@forgerock.com[info@forgerock.com, window=\_top] in advance to determine how your deployment can be supported.
If you deploy with custom plugins and need support in production, see link:https://github.com/OpenIdentityPlatform/.github/wiki/Approved-Vendor-List[Approved Vendors List, window=\_top] in advance to determine how your deployment can be supported.
====

[#about-server-plugins]
@@ -47,7 +47,7 @@

[NOTE]
====
The OpenDJ server Java API has interface stability: Evolving, as described in xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"] in the __Reference__.
The OpenDJ server Java API has interface stability: Evolving, as described in xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"] in the __Reference__.

This means that a server plugin built with one version of OpenDJ directory server will not necessarily work or even compile with a different version of the server.
====
@@ -256,7 +256,7 @@
The OpenDJ example server plugin is an Apache Maven project.

As you can see in the `pom.xml` file for the project, the plugin depends on the OpenDJ directory server module.
The plugin project uses these ForgeRock Maven plugins:
The plugin project uses these Open Identity Platform Maven plugins:

* The `i18n-maven-plugin` generates message source files from properties files in the resource bundle.
+
@@ -338,7 +338,7 @@

[NOTE]
====
The OpenDJ server Java API has interface stability: Evolving, as described in xref:../reference/appendix-interface-stability.adoc#interface-stability["ForgeRock Product Interface Stability"] in the __Reference__.
The OpenDJ server Java API has interface stability: Evolving, as described in xref:../reference/appendix-interface-stability.adoc#interface-stability["Product Interface Stability"] in the __Reference__.

This means that a server plugin built with one version of OpenDJ directory server will not necessarily work or even compile with a different version of the server.
====