Some endpoint options such as consumerKey, consumerSecret or keyLoader are usually set to the same values on gauth:authorize and gauth:upgrade endpoints. The gauth component allows to configure them on component-level. These settings are then inherited by gauth endpoints and need not be set redundantly in the endpoint URIs. Here are some configuration examples.

component configuration for a registered web application using the HMAC-SHA1 signature method

component configuration for an unregistered web application using the HMAC-SHA1 signature method

component configuration for a registered web application using the RSA-SHA1 signature method

Adding the Grape component to the project

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

Developing with the Groovy DSL

To be able to use the Groovy DSL in your camel routes you need to add the a dependency on camel-groovy which implements the Groovy DSL.

If you use Maven you can 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).

Additionally you need to make sure that the Groovy classes will be compiled. You can either use gmaven for this or, particularly with mixed projects containing Java and Groovy code, you might want to use the Groovy Eclipse compiler:

As Eclipse user, you might want to configure the Maven Eclipse plugin in a way so that your project is set up correctly for using Eclipse Plugin for Groovy when mvn eclipse:eclipse is executed:

-
@@ -177,7 +177,7 @@ public class HazelcastIdempotenRepositor
 }
 ]]>
 

Apache HBase Overview

HBase is an open-source, distributed, versioned, column-oriented store modeled after Google's Bigtable: A Distributed Storage System for Structured Data. You can use HBase when you need random, realtime read/write access to your Big Data. More information at Apache HBase.

Camel and HBase

When using a datastore inside a camel route, there is always the challenge of specifying how the camel message will stored to the datastore. In document based stores things are more easy as the message body can be directly mapped to a document. In relational databases an ORM solution can be used to map properties to columns etc. In column based stores things are more challenging as there is no standard way to perform that kind of mapping.

To overcome these challenges, camel-hbase makes use of the message headers to specify the mapping of the message to HBase columns. It also provides the ability to use some camel-hbase provided classes that model HBase data and can be easily convert to and from xml/json etc.
Finally it provides the ability to the user to implement and use his own mapping strategy.

Regardless of the mapping strategy camel-hbase will convert a message into an org.apache.camel.component.hbase.model.HBaseData object and use that object for its internal operations.

Configuring the component

The HBase component can be provided a custom HBaseConfiguration object as a property or it can create an HBase configuration object on its own based on the HBase related resources that are found on classpath.

- @@ -108,7 +108,7 @@

Put Operations.

HBase is a column based store, which allows you to store data into a specific column of a specific row. Columns are grouped into families, so in order to specify a column you need to specify the column family and the qualifier of that column. To store data into a specific column you need to specify both the column and the row.

The simplest scenario for storing data into HBase from a camel route, would be to store part of the message body to specified HBase column.

The route above assumes that the message body contains an object that has an id and value property and will store the content of value in the HBase column myfamily:myqualifier in the row specified by id. If we needed to specify more than one column/value pairs we could just specify additional column mappings. Notice that you must use numbers from the 2nd header onwards, eg RowId2, RowId3, RowId4, etc. Only the 1st header does not have the number 1.

It is important to remember that you can use uri options, message headers or a combination of both. It is recommended to specify constants as part of the uri and dynamic values as headers. If something is defined both as header and as part of the uri, the header will be used.

Get Operations.

A Get Operation is an operation that is used to retrieve one or more values from a specified HBase row. To specify what are the values that you want to retrieve you can just specify them as part of the uri or as message headers.

In the example above the result of the get operation will be stored as a header with name CamelHBaseValue.

Delete Operations.

You can also you camel-hbase to perform HBase delete operation. The delete operation will remove an entire row. All that needs to be specified is one or more rows as part of the message headers.

Scan Operations.

A scan operation is the equivalent of a query in HBase. You can use the scan operation to retrieve multiple rows. To specify what columns should be part of the result and also specify how the values will be converted to objects you can use either uri options or headers.

In this case its probable that you also also need to specify a list of filters for limiting the results. You can specify a list of filters as part of the uri and camel will return only the rows that satisfy ALL the filters.
To have a filter that will be aware of the information that is part of the message, camel defines the ModelAwareFilter. This will allow your filter to take into consideration the model that is defined by the message and the mapping strategy.
When using a ModelAwareFilter camel-hbase will apply the selected mapping strategy to the in message, will create an object that models the mapping and will pass that object to the Filter.

For example to perform scan using as criteria the message headers, you can make use of the ModelAwareColumnMatchingFilter as shown below.

Spring DSL:

Spring DSL Based Configuration of Endpoint

Using Different `SSLContextParameters`

The HTTP4 component only support one instance of org.apache.camel.util.jsse.SSLContextParameters per component. If you need to use two or more different instances, then you need to setup multiple HTTP4 components as shown below. Where we have two components, each using their own instance of sslContextParameters property.

And in XML DSL:

You can also configure hystrix globally and then refer to that configuration:

This endpoint only supports producers.

Options

Option Type Default value Description Compulsory Consumer/producer

Option	Type	Default value	Description	Compulsory	Consumer/producer
`operation`	`IgniteIdGenOperation enum`	`---`	The operation to invoke on the Ignite ID Generator. Superseded by the `IgniteConsta nts.IGNITE_IDGEN_OPERATION` header in the IN message. Possible values: `ADD_AND_GET, GET, GET_AND_ADD, GET_AND_INCREMENT, INCREMENT_AND_GET`.	N	Producer
`configuration`	CollectionConfiguration	empty CollectionConfiguration	The configuration for this data structure. You can also specify inner properties by using t he `config.` prefix. For example: `?config.backups=4`	N	Producer

operation

IgniteIdGenOperation enum

---

The operation to invoke on the Ignite ID Generator.

Superseded by the IgniteConsta nts.IGNITE_IDGEN_OPERATION header in the IN message.

Possible values: ADD_AND_GET, GET, GET_AND_ADD, GET_AND_INCREMENT, INCREMENT_AND_GET.

Producer

configuration

CollectionConfiguration

empty CollectionConfiguration

The configuration for this data structure. You can also specify inner properties by using t he config. prefix.

For example: ?config.backups=4

Producer

Initializing the Ignite component

Each instance of the Ignite component is associated with an underlying org.apache.ignite.Ignite instance. You can interact with two Ignite clusters by initializing two instances of the Ignite component and binding them to different IgniteConfigurations. There are 3 ways to initialize the Ignite component:

By passing in an existing org.apache.ignite.Ignite instance. Here's an example using Spring config:

By passing in an IgniteConfiguration, either constructed programmatically or through inversion of control (e.g. Spring, Blueprint, etc.). Here's an example using Spring config:

By passing in a URL, InputStream or String URL to a Spring-based configuration file. In all three cases, you inject them in the same property called configurationResource. Here's an example using Spring config:

Additionally, if using Camel programmatically, there are several convenience static methods in IgniteComponent that return a component out of any of these configuration options:

IgniteComponent#fromIgnite(Ignite)
IgniteComponent#fromConfiguration(IgniteConfiguration)
IgniteComponent#fromInputStream(InputStream)
IgniteComponent#fromUrl(URL)
IgniteComponent#fromLocation(String)

You may use those methods to quickly create an IgniteComponent with your chosen configuration technique.

General options

All endpoints share the following options:

Option	Type	Default value	Description
`propagateIncomingBodyIfNoReturnValue`	`boolean`	`true`	If the underlying Ignite operation returns void (no return type), this flag determines whether the producer will copy the IN body into the OUT body.
`treatCollectionsAsCacheObjects`	`boolean`	`false`	Some Ignite operations can deal with multiple elements at once, if passed a Collection. Enabling this option will treat Collections as a single object, invoking the operation variant for cardinality 1.

OSGi Support

Apache Ignite supports OSGi from version 1.5.0.final onwards.

NOTES when installing on Apache Karaf:

Installing the camel-ignite feature will require the Ignite feature repository to be present.
You must have exported from the JRE (system bundle) some low-level, non-standard packages that Ignite requires.

Please refer to the OSGi section in the Ignite documentation for more information.