此内容没有您所选择的语言版本。

Chapter 201. LDIF Component


Available as of Camel version 2.20

The ldif component allows you to do updates on an LDAP server from a LDIF body content.

This component uses a basic URL syntax to access the server. It uses the Apache DS LDAP library to process the LDIF. After processing the LDIF, the response body will be a list of statuses for success/failure of each entry.

Note

The Apache LDAP API is very sensitive to LDIF syntax errors. If in doubt, refer to the unit tests to see an example of each change type.

Maven users will need to add the following dependency to their pom.xml for this component:

<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-ldif</artifactId>
    <version>x.x.x</version>
    <!-- use the same version as your Camel core version -->
</dependency>

201.1. URI format

ldap:ldapServerBean[?options]

The ldapServerBean portion of the URI refers to a LdapConnection. This should be constructed from a factory at the point of use to avoid connection timeouts. The LDIF component only supports producer endpoints, which means that an ldif URI cannot appear in the from at the start of a route.

For SSL configuration, refer to the camel-ldap component where there is an example of setting up a custom SocketFactory instance.

You can append query options to the URI in the following format, ?option=value&option=value&…​

201.2. Options

The LDIF component has no options.

The LDIF endpoint is configured using URI syntax:

ldif:ldapConnectionName

with the following path and query parameters:

201.2.1. Path Parameters (1 parameters):

NameDescriptionDefaultType

ldapConnectionName

Required The name of the LdapConnection bean to pull from the registry. Note that this must be of scope prototype to avoid it being shared among threads or using a connection that has timed out.

 

String

201.2.2. Query Parameters (1 parameters):

NameDescriptionDefaultType

synchronous (advanced)

Sets whether synchronous processing should be strictly used, or Camel is allowed to use asynchronous processing (if supported).

false

boolean

201.3. Body types:

The body can be a URL to an LDIF file or an inline LDIF file. To signify the difference in body types, an inline LDIF must start with:

version: 1

If not, the component will try to parse the body as a URL.

201.4. Result

The result is returned in the Out body as a ArrayList<java.lang.String> object. This contains either "success" or an Exception message for each LDIF entry.

201.5. LdapConnection

The URI, ldif:ldapConnectionName, references a bean with the ID, ldapConnectionName. The ldapConnection can be configured using a LdapConnectionConfig bean. Note that the scope must have a scope of prototype to avoid the connection being shared or picking up a stale connection.

The LdapConnection bean may be defined as follows in Spring XML:

<bean id="ldapConnectionOptions" class="org.apache.directory.ldap.client.api.LdapConnectionConfig">
  <property name="ldapHost" value="${ldap.host}"/>
  <property name="ldapPort" value="${ldap.port}"/>
  <property name="name" value="${ldap.username}"/>
  <property name="credentials" value="${ldap.password}"/>
  <property name="useSsl" value="false"/>
  <property name="useTls" value="false"/>
</bean>

<bean id="ldapConnectionFactory" class="org.apache.directory.ldap.client.api.DefaultLdapConnectionFactory">
  <constructor-arg index="0" ref="ldapConnectionOptions"/>
</bean>

<bean id="ldapConnection" factory-bean="ldapConnectionFactory" factory-method="newLdapConnection" scope="prototype"/>

or in a OSGi blueprint.xml:

<bean id="ldapConnectionOptions" class="org.apache.directory.ldap.client.api.LdapConnectionConfig">
  <property name="ldapHost" value="${ldap.host}"/>
  <property name="ldapPort" value="${ldap.port}"/>
  <property name="name" value="${ldap.username}"/>
  <property name="credentials" value="${ldap.password}"/>
  <property name="useSsl" value="false"/>
  <property name="useTls" value="false"/>
</bean>

<bean id="ldapConnectionFactory" class="org.apache.directory.ldap.client.api.DefaultLdapConnectionFactory">
  <argument ref="ldapConnectionOptions"/>
</bean>

<bean id="ldapConnection" factory-ref="ldapConnectionFactory" factory-method="newLdapConnection" scope="prototype"/>

201.6. Samples

Following on from the Spring configuration above, the code sample below sends an LDAP request to filter search a group for a member. The Common Name is then extracted from the response.

ProducerTemplate<Exchange> template = exchange.getContext().createProducerTemplate();

List<?> results = (Collection<?>) template.sendBody("ldap:ldapConnection, "LDiff goes here");

if (results.size() > 0) {
  // Check for no errors

  for (String result : results) {
    if ("success".equalTo(result)) {
      // LDIF entry success
    } else {
      // LDIF entry failure
    }
  }
}

201.7. LevelDB

Available as of Camel 2.10

Leveldb is a very lightweight and embedable key value database. It allows together with Camel to provide persistent support for various Camel features such as Aggregator.

Current features it provides:

  • LevelDBAggregationRepository

201.7.1. Using LevelDBAggregationRepository

LevelDBAggregationRepository is an AggregationRepository which on the fly persists the aggregated messages. This ensures that you will not loose messages, as the default aggregator will use an in memory only AggregationRepository.

It has the following options:

OptionTypeDescription

repositoryName

String

A mandatory repository name. Allows you to use a shared LevelDBFile for multiple repositories.

persistentFileName

String

Filename for the persistent storage. If no file exists on startup a new file is created.

levelDBFile

LevelDBFile

Use an existing configured org.apache.camel.component.leveldb.LevelDBFile instance.

sync

boolean

Camel 2.12: Whether or not the LevelDBFile should sync on write or not. Default is false. By sync on write ensures that its always waiting for all writes to be spooled to disk and thus will not loose updates. See LevelDB docs for more details about async vs sync writes.

returnOldExchange

boolean

Whether the get operation should return the old existing Exchange if any existed. By default this option is false to optimize as we do not need the old exchange when aggregating.

useRecovery

boolean

Whether or not recovery is enabled. This option is by default true. When enabled the Camel Aggregator automatic recover failed aggregated exchange and have them resubmitted.

recoveryInterval

long

If recovery is enabled then a background task is run every x’th time to scan for failed exchanges to recover and resubmit. By default this interval is 5000 millis.

maximumRedeliveries

int

Allows you to limit the maximum number of redelivery attempts for a recovered exchange. If enabled then the Exchange will be moved to the dead letter channel if all redelivery attempts failed. By default this option is disabled. If this option is used then the deadLetterUri option must also be provided.

deadLetterUri

String

An endpoint uri for a Dead Letter Channel where exhausted recovered Exchanges will be moved. If this option is used then the maximumRedeliveries option must also be provided.

The repositoryName option must be provided. Then either the persistentFileName or the levelDBFile must be provided.

201.7.2. What is preserved when persisting

LevelDBAggregationRepository will only preserve any Serializable compatible message body data types. Message headers must be primitive / string / numbers / etc. If a data type is not such a type its dropped and a WARN is logged. And it only persists the Message body and the Message headers. The Exchange properties are not persisted.

201.7.3. Recovery

The LevelDBAggregationRepository will by default recover any failed Exchange. It does this by having a background tasks that scans for failed Exchanges in the persistent store. You can use the checkInterval option to set how often this task runs. The recovery works as transactional which ensures that Camel will try to recover and redeliver the failed Exchange. Any Exchange which was found to be recovered will be restored from the persistent store and resubmitted and send out again.

The following headers is set when an Exchange is being recovered/redelivered:

HeaderTypeDescription

Exchange.REDELIVERED

Boolean

Is set to true to indicate the Exchange is being redelivered.

Exchange.REDELIVERY_COUNTER

Integer

The redelivery attempt, starting from 1.

Only when an Exchange has been successfully processed it will be marked as complete which happens when the confirm method is invoked on the AggregationRepository. This means if the same Exchange fails again it will be kept retried until it success.

You can use option maximumRedeliveries to limit the maximum number of redelivery attempts for a given recovered Exchange. You must also set the deadLetterUri option so Camel knows where to send the Exchange when the maximumRedeliveries was hit.

You can see some examples in the unit tests of camel-leveldb, for example this test.

201.7.3.1. Using LevelDBAggregationRepository in Java DSL

In this example we want to persist aggregated messages in the target/data/leveldb.dat file.

201.7.3.2. Using LevelDBAggregationRepository in Spring XML

The same example but using Spring XML instead:

201.7.4. Dependencies

To use LevelDB in your camel routes you need to add the a dependency on camel-leveldb.

If you use maven you could just add the following to your pom.xml, substituting the version number for the latest & greatest release (see the download page for the latest versions).

<dependency>
  <groupId>org.apache.camel</groupId>
  <artifactId>camel-leveldb</artifactId>
  <version>2.10.0</version>
</dependency>

201.7.5. See Also

  • Configuring Camel
  • Component
  • Endpoint
  • Getting Started
  • Aggregator
  • HawtDB
  • Components
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.