This is an automated email from the ASF dual-hosted git repository.
davsclaus pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/main by this push:
new f32387fff24d CAMEL-16861: Update docs
f32387fff24d is described below
commit f32387fff24da3fd757697a45bfb263c429f3d86
Author: Claus Ibsen <[email protected]>
AuthorDate: Sat Feb 21 09:48:34 2026 +0100
CAMEL-16861: Update docs
---
.../user-manual/modules/ROOT/pages/expression.adoc | 7 +-
.../ROOT/pages/parameter-binding-annotations.adoc | 147 ++++++++++++---------
.../modules/ROOT/pages/pojo-consuming.adoc | 56 +++++---
.../modules/ROOT/pages/pojo-producing.adoc | 21 +--
docs/user-manual/modules/ROOT/pages/predicate.adoc | 13 +-
docs/user-manual/modules/ROOT/pages/processor.adoc | 94 +++++++------
.../modules/ROOT/pages/producertemplate.adoc | 7 +-
.../modules/ROOT/pages/property-binding.adoc | 22 +--
.../modules/faq/pages/what-is-camel.adoc | 4 +
9 files changed, 227 insertions(+), 144 deletions(-)
diff --git a/docs/user-manual/modules/ROOT/pages/expression.adoc
b/docs/user-manual/modules/ROOT/pages/expression.adoc
index 265ff8063db0..4c33398ede85 100644
--- a/docs/user-manual/modules/ROOT/pages/expression.adoc
+++ b/docs/user-manual/modules/ROOT/pages/expression.adoc
@@ -10,7 +10,8 @@ To support dynamic rules Camel supports pluggable
https://www.javadoc.io/doc/org.apache.camel/camel-api/current/org/apache/camel/Expression.html[Expression]
strategies using a variety of different
xref:components:languages:index.adoc[Languages].
-== Expression API
+NOTE: The xref:components:languages:simple-language.adoc[Simple] is often used
as predicates and expressions
+with the Camel EIPs.
If you are outside the DSL and want to create your own
expressions you can either implement the
@@ -19,7 +20,7 @@ interface], reuse one of the other builders or try the
https://www.javadoc.io/doc/org.apache.camel/camel-support/current/org/apache/camel/support/builder/ExpressionBuilder.html[ExpressionBuilder
class].
-=== Expression
+== Expression API
The API for a Camel Expression is defined in the
`org.apache.camel.Expression` interface as shown:
@@ -38,3 +39,5 @@ public interface Expression {
}
----
+A `Expression` is being evaluated to an Object value. This makes expressions so
+powerful as this can be used for functions, data mapping, templating, and for
low-code users.
diff --git
a/docs/user-manual/modules/ROOT/pages/parameter-binding-annotations.adoc
b/docs/user-manual/modules/ROOT/pages/parameter-binding-annotations.adoc
index 6afb0d5a88cc..fee5391a9e37 100644
--- a/docs/user-manual/modules/ROOT/pages/parameter-binding-annotations.adoc
+++ b/docs/user-manual/modules/ROOT/pages/parameter-binding-annotations.adoc
@@ -2,46 +2,26 @@
The bean parameter binding annotations from Camel are as follows:
-[width="100%",cols="34%,33%,33%",options="header",]
-|=======================================================================
-|Annotation |Meaning |Parameter
-|`org.apache.camel.Body`
-|To bind to an inbound message body |
-
-|`org.apache.camel.Header`
-|To bind to a message header |String name of the header
-
-|`org.apache.camel.Headers`
-|To bind to the Map of the message headers |
-
-|`org.apache.camel.Variable`
-|To bind to a named variable |String name of the
-variable
-
-|`org.apache.camel.Variables`
-|To bind to the variables map |
-
-|`org.apache.camel.ExchangeProperty`
-|To bind to a named property on the exchange |String name of the
-property
-
-|`org.apache.camel.ExchangeProperties`
-|To bind to the exchange property map on the exchange |
-
-|`org.apache.camel.ExchangeException`
-|To bind to an Exception set on the exchange |
-
-|=======================================================================
+[width="100%",cols="1m,2",options="header",]
+|===
+|Annotation | Meaning
+|`org.apache.camel.Body` | To bind to an inbound message body
+|`org.apache.camel.Header` | To bind to a message header by the given name
+|`org.apache.camel.Headers` | To bind to the Map of the message headers
+|`org.apache.camel.Variable` | To bind to a named variable the given name
+|`org.apache.camel.Variables` | To bind to the variables map
+|`org.apache.camel.ExchangeProperty` | To bind to a named property on the
exchange the given name
+|`org.apache.camel.ExchangeProperties` | To bind to the exchange property map
on the exchange
+|`org.apache.camel.ExchangeException` | To bind to an Exception set on the
exchange
+|===
These annotations can be used with the
xref:components::bean-component.adoc[Bean]
component or when invoking beans in the xref:dsl.adoc[DSL]
Annotations can be used to define an xref:expression.adoc[Expression] or
to extract various headers, properties or payloads from a
-xref:components:eips:message.adoc[Message] when invoking a bean method (see
-xref:bean-integration.adoc[Bean Integration] for more detail of how to
-invoke bean methods) together with being useful to help disambiguate
-which method to invoke.
+xref:components:eips:message.adoc[Message] when invoking a bean method. See
+xref:bean-integration.adoc[Bean Integration] for more in depth details on
invoking beans.
If no annotations are used then Camel assumes that a single parameter is
the body of the message. Camel will then use the
@@ -78,11 +58,11 @@ TIP: You don't necessarily need to use the `@Consume`
annotation if you don't
want to as you could also make use of the Camel xref:dsl.adoc[DSL] to
route to the bean's method as well.
-=== Using the DSL to invoke the bean method
+=== Calling bean from Camel routes
Here is another example which does not use xref:pojo-consuming.adoc[POJO
Consuming] annotations but instead uses the xref:dsl.adoc[DSL] to route
-messages to the bean method
+messages to the bean method.
[source,java]
----
@@ -97,23 +77,79 @@ public class MyBean {
The routing DSL then looks like this
+[tabs]
+====
+
+Java::
++
[source,java]
----
from("activemq:someQueue").
to("bean:myBean");
----
+XML::
++
+[source,xml]
+----
+<route>
+ <from uri="activemq:someQueue"/>
+ <to uri="bean:myBean"/>
+</route>
+----
+
+YAML::
++
+[source,yaml]
+----
+- route:
+ from:
+ uri: activemq:someQueue
+ steps:
+ - to:
+ uri: bean:myBean
+----
+====
+
Here *myBean* would be looked up in the xref:registry.adoc[Registry]
then the body of the message would be used to try figure out what method to
call.
If you want to be explicit you can use:
+[tabs]
+====
+
+Java::
++
[source,java]
----
from("activemq:someQueue").
- to("bean:myBean?methodName=doSomething");
+ to("bean:myBean?method=doSomething");
+----
+
+XML::
++
+[source,xml]
+----
+<route>
+ <from uri="activemq:someQueue"/>
+ <to uri="bean:myBean?method=doSomething"/>
+</route>
----
+YAML::
++
+[source,yaml]
+----
+- route:
+ from:
+ uri: activemq:someQueue
+ steps:
+ - to:
+ uri: bean:myBean?method=doSomething
+----
+====
+
And here we have a nifty example for you to show some great power in
Camel. You can mix and match the annotations with the normal parameters,
so we can have this example with annotations and the Exchange also:
@@ -136,28 +172,16 @@ Camel to bind expressions to method parameters when using
xref:bean-integration.adoc[Bean Integration]. For example, you can use
any of these annotations:
-[width="100%",cols="50%,50%",options="header",]
-|=======================================================================
+[width="100%",cols="1m,2",options="header",]
+|===
|Annotation |Description
-|`@Bean`
-|Inject a xref:components:languages:bean-language.adoc[Bean] expression
-
-|`@Constant`
-|Inject a xref:components:languages:constant-language.adoc[Constant] expression
-
-|`@Groovy`
-|Inject a xref:components:languages:groovy-language.adoc[Groovy] expression
-
-|`@Header`
-|Inject a xref:components:languages:header-language.adoc[Header] expression
-
-|`@Simple`
-|Inject an xref:components:languages:simple-language.adoc[Simple] expression
-
-|`@XPath`
-|Inject an xref:components:languages:xpath-language.adoc[XPath] expression
-
-|=======================================================================
+|`@Bean`|Inject a xref:components:languages:bean-language.adoc[Bean] expression
+|`@Constant`|Inject a
xref:components:languages:constant-language.adoc[Constant] expression
+|`@Groovy`|Inject a xref:components:languages:groovy-language.adoc[Groovy]
expression
+|`@Header`|Inject a xref:components:languages:header-language.adoc[Header]
expression
+|`@Simple`|Inject an xref:components:languages:simple-language.adoc[Simple]
expression
+|`@XPath`|Inject an xref:components:languages:xpath-language.adoc[XPath]
expression
+|===
The table above only list some of the commonly used languages. You can find
a list of all supported xref:components:languages:index.adoc[Languages]
@@ -182,7 +206,7 @@ public class Foo {
==== Advanced example using @Bean
-And an example of using the the `@Bean` binding annotation,
+And an example of using the `@Bean` binding annotation,
where you can call a xref:components::bean-component.adoc[POJO] to supply
the parameter value:
@@ -210,8 +234,7 @@ public class MyIdGenerator {
public String generate(@Header(name = "user") String user, @Body String
payload) throws Exception {
User user = userManager.lookupUser(user);
String userId = user.getPrimaryId();
- String id = userId + generateHashCodeForPayload(payload);
- return id;
+ return userId + generateHashCodeForPayload(payload);
}
}
----
@@ -250,7 +273,7 @@ For example in Spring XML:
In this example we have an Exchange that has a User object stored in the
in header. This User object has methods to get some user information. We
want to use xref:components:languages:groovy-language.adoc[Groovy] to inject
an expression that
-extracts and concats the fullname of the user into the fullName parameter.
+extracts and concat the names of the user into the fullName parameter.
[source,java]
----
diff --git a/docs/user-manual/modules/ROOT/pages/pojo-consuming.adoc
b/docs/user-manual/modules/ROOT/pages/pojo-consuming.adoc
index 9975b6e2bc23..0c711e523e4c 100644
--- a/docs/user-manual/modules/ROOT/pages/pojo-consuming.adoc
+++ b/docs/user-manual/modules/ROOT/pages/pojo-consuming.adoc
@@ -5,18 +5,12 @@ annotation to mark a particular method of a bean as being a
consumer
method. The value of the annotation defines the Camel
xref:endpoint.adoc[Endpoint] to consume from.
-IMPORTANT: The `@Consume` POJO annotations are not part of any Camel routes,
and you cannot use errorHandler or onException with that.
-
-[NOTE]
-====
-The following steps use the ActiveMQ component which is not yet supported on
Camel 4.
-====
+IMPORTANT: The `@Consume` POJO annotations are not part of any Camel routes,
and you cannot use xref:error-handler.adoc[errorHandler] or
xref:exception-clause.adoc[onException] with this.
For example lets invoke the `onCheese()` method with the String body of the
inbound JMS message from ActiveMQ on the cheese
queue; this will use the xref:type-converter.adoc[Type Converter] to
-convert the JMS ObjectMessage or BytesMessage to a String - or just use
-a TextMessage from JMS
+convert the JMS payload to `String` as declared in the method signature.
[source,java]
----
@@ -31,19 +25,19 @@ public class Foo {
The xref:bean-binding.adoc[Bean Binding] is then used to convert the
inbound xref:components:eips:message.adoc[Message] to the parameter list used
to invoke
-the method .
+the method.
-This basically creates a route that looks kinda like this:
+This basically creates a route that looks kinda like this (based on the
example above):
[source,java]
----
-from(uri).bean(theBean, "methodName");
+from("activemq:cheese").bean(Foo.class, "onCheese");
----
== Using a property to define the endpoint
-The following annotations `@Consume`, `@Produce`, `@EndpointInject`, now
-offers a `property` attribute you can use to define the endpoint as a
+The following annotations `@Consume`, `@Produce`, `@EndpointInject`, provides
+a `property` attribute you can use to define the endpoint uri as a
property on the bean. Then Camel will use the getter method to access
the property.
@@ -52,22 +46,25 @@ For example:
[source,java]
----
public class MyService {
+
private String serviceEndpoint;
public void setServiceEndpoint(String uri) {
this.serviceEndpoint = uri;
}
- public String getServiceEndpoint() {
+ public String getServiceEndpoint() { // <2>
return serviceEndpoint;
}
- @Consume(property = "serviceEndpoint")
+ @Consume(property = "serviceEndpoint") // <1>
public void onService(String input) {
// do something
}
}
----
+<1> the getter for the property
+<2> refers to the name of the property
The bean `MyService` has a property named `serviceEndpoint` which has
getter/setter for the property. Now we want to use the bean for
@@ -76,8 +73,14 @@ in the `onService` method. Notice how we use the
`property = "serviceEndpoint` to configure the property that has the
endpoint url.
-If you define the bean in Spring XML, then you can configure the property as
follows:
+[tabs]
+====
+
+Spring XML::
++
+If you define the bean in Spring XML, then you can configure the property as
follows:
++
[source,xml]
----
<bean id="myService" class="com.foo.MyService">
@@ -85,6 +88,18 @@ If you define the bean in Spring XML, then you can configure
the property as fol
</bean>
----
+YAML::
++
+[source,yaml]
+----
+- beans:
+ - name: foo
+ type: com.foo.MyService
+ properties:
+ serviceEndpoint: activemq:queue:foo
+----
+====
+
This allows you to configure the bean without with any dependency injection
style.
=== Advanced use with property naming convention
@@ -95,8 +110,8 @@ The method must be a `getXXX` method.
. Use the property name if explicit given
. If no property name was configured, then use the method name
-. Try to get the property with name**Endpoint** (eg with Endpoint as postfix)
-. Try to get the property with the name as is (eg no postfix or postfix)
+. Try to get the property with name**Endpoint** (e.g. with Endpoint as postfix)
+. Try to get the property with the name as is (e.g. no postfix or postfix)
. If the property name starts with **on** then omit that, and try step 3 and 4
again.
So in the example above, we could have defined the `@Consume` annotation as:
@@ -110,7 +125,7 @@ So in the example above, we could have defined the
`@Consume` annotation as:
Now the property is named "service" which then would match step 3 from
the algorithm, and have Camel invoke the `getServiceEndpoint` method.
-We could also have omitted the property attribute, to make it implicit
+We could also have omitted the property attribute, to make it implicit:
[source,java]
----
@@ -122,3 +137,6 @@ Now Camel matches step 5, and loses the prefix *on* in the
name, and
looks for 'service' as the property. And because there is a
`getServiceEndpoint` method, Camel will use this method.
+== See Also
+
+- xref:pojo-producing.adoc[]
\ No newline at end of file
diff --git a/docs/user-manual/modules/ROOT/pages/pojo-producing.adoc
b/docs/user-manual/modules/ROOT/pages/pojo-producing.adoc
index a1c371912db5..74d977c394a4 100644
--- a/docs/user-manual/modules/ROOT/pages/pojo-producing.adoc
+++ b/docs/user-manual/modules/ROOT/pages/pojo-producing.adoc
@@ -4,25 +4,21 @@ There are two different ways to send messages to any Camel
xref:endpoint.adoc[Endpoint] from a POJO:
- Using `@Produce` or `@EndpointInject`
-- Or to hide using an interface
-
-[NOTE]
-====
-The following steps use the ActiveMQ component which is not yet supported on
Camel 4.
-====
+- Hiding using an interface
== Using @Produce
To allow sending of messages from POJOs you can use the `@Produce` annotation.
This will inject a `org.apache.camel.ProducerTemplate` so that the bean can
send messages.
-IMPORTANT: The `@Produce` POJO annotations are not part of any Camel routes,
and you cannot use errorHandler or onException with that.
+IMPORTANT: The `@Produce` POJO annotations are not part of any Camel routes,
and you cannot use xref:error-handler.adoc[errorHandler] or
xref:exception-clause.adoc[onException] with this.
For example to send a message to the foo queue on ActiveMQ:
[source,java]
----
public class Foo {
+
@Produce("activemq:foo")
ProducerTemplate producer;
@@ -52,6 +48,7 @@ you use in your business logic. Example:
[source,java]
----
public interface MyListener {
+
// this method is request/reply (InOut) because the method has a return
value
// to use one way (InOnly) then the method should be a void method
String sayHello(String name);
@@ -78,11 +75,19 @@ endpoint; in this case the ActiveMQ endpoint to
queue *`foo`*. Because the `sayHello` method has a return type (`String`) then
Camel
will use xref:components:eips:requestReply-eip.adoc[Request Reply] (InOut)
messaging.
+If the method is a `void` method, then Camel will use
xref:components:eips:event-message.adoc[Event Message] (InOnly) messaging,
+as shown below:
+
[source,java]
----
public interface MyListener {
+
+ // this method is one-way (InOnly) because the method is void
void sayHello(String name);
+
}
----
-If the method is a `void` method, then Camel will use
xref:components:eips:event-message.adoc[Event Message] (InOnly) messaging.
+== See Also
+
+- xref:pojo-consuming.adoc[]
\ No newline at end of file
diff --git a/docs/user-manual/modules/ROOT/pages/predicate.adoc
b/docs/user-manual/modules/ROOT/pages/predicate.adoc
index 96fda381c684..43ee5587085c 100644
--- a/docs/user-manual/modules/ROOT/pages/predicate.adoc
+++ b/docs/user-manual/modules/ROOT/pages/predicate.adoc
@@ -1,20 +1,25 @@
= Predicates
-xref:expression.adoc[Expressions] and Predicates can then be used to
+Expressions and xref:predicate.adoc[Predicates] can then be used to
create the various
xref:components:eips:enterprise-integration-patterns.adoc[Enterprise
-Integration Patterns] in the xref:dsl.adoc[DSL] like with the
xref:components:eips:choice-eip.adoc[Content Based Router] EIP.
+Integration Patterns] in the xref:dsl.adoc[DSL] like with the
+xref:components:eips:choice-eip.adoc[Content Based Router] EIP, or
+xref:components:eips:recipientList-eip.adoc[Recipient List] EIP.
To support dynamic rules Camel supports pluggable
https://www.javadoc.io/doc/org.apache.camel/camel-api/current/org/apache/camel/Predicate.html[Predicate]
strategies using a variety of different
xref:components:languages:index.adoc[Languages].
+NOTE: The xref:components:languages:simple-language.adoc[Simple] is often used
as predicates and expressions
+with the Camel EIPs.
+
== Predicate API
The API for a Camel Predicate is defined in the
`org.apache.camel.Predicate` interface as shown:
[source,java]
--------------------------------------------------------------------------------
+----
public interface Predicate {
/**
@@ -27,7 +32,7 @@ public interface Predicate {
boolean matches(Exchange exchange);
}
--------------------------------------------------------------------------------
+----
A `Predicate` is being evaluated to a boolean value so the result is
either `true` or `false`. This makes predicates so
diff --git a/docs/user-manual/modules/ROOT/pages/processor.adoc
b/docs/user-manual/modules/ROOT/pages/processor.adoc
index 2f9354a9941a..c985644dc2c2 100644
--- a/docs/user-manual/modules/ROOT/pages/processor.adoc
+++ b/docs/user-manual/modules/ROOT/pages/processor.adoc
@@ -2,10 +2,14 @@
The
https://www.javadoc.io/doc/org.apache.camel/camel-api/current/org/apache/camel/Processor.html[Processor]
-interface is used to implement consumers of message exchanges or to
+interface is used to implement consumers of message exchanges, or to
implement a xref:components:eips:message-translator.adoc[Message Translator],
and other use-cases.
+The `Processor` is a central API both internally and externally with Camel.
The `Processor` has
+a single method `processor` (see below) that for example every
+xref:components:eips:enterprise-integration-patterns.adoc[EIPs] implements.
+
== Using a processor in a route
Once you have written a class which implements processor like this:
@@ -21,30 +25,24 @@ public class MyProcessor implements Processor {
}
----
-Then you can easily call this processor from a Java such as:
+Then you can easily call this processor from Camel routes:
-[source,java]
-----
-from("activemq:myQueue").process(new MyProcessor());
-----
+[tabs]
+====
+Java::
++
Notice that the processor is referred to by the class type `MyProcessor.class`
in the route.
Camel will during startup automatic create one new instance of the processor
using xref:injector.adoc[Injector]
to be used during routing messages.
-
-In XML DSL however the `<process`> tag requires, referring to an existing
processor instance
-which can be done:
-
-You can then easily use this inside a route by declaring the bean in
-Spring, say via the XML:
-
-[source,xml]
++
+[source,java]
----
-<bean id="myProcessor" class="com.acme.MyProcessor"/>
+from("activemq:myQueue").process(MyProcessor.class);
----
-And then use the bean id in the Camel route:
-
+XML::
++
[source,xml]
----
<route>
@@ -53,17 +51,44 @@ And then use the bean id in the Camel route:
</route>
----
-And in Java DSL:
-
-[source,java]
+YAML::
++
+[source,yaml]
----
-from("activemq:myQueue").process("myProcessor");
+- route:
+ from:
+ uri: activemq:myQueue
+ steps:
+ - process:
+ ref: myProcessor
----
+====
+
=== Referring to beans using #class syntax
-In XML DSL you can also refer to the processor by its class name using
`#class:` as prefix as shown:
+In all the Camel DSL you can also refer to the processor by its class name
using `#class:` as prefix as shown:
+
+[tabs]
+====
+
+Java::
++
+[source,java]
+----
+from("activemq:myQueue")
+ .process("#class:com.acme.MyProcessor");
+----
++
+However, in Java DSL you would often use the type safe way and create the
Processor directly:
++
+[source,java]
+----
+from("activemq:myQueue").process(new MyProcessor());
+----
+XML::
++
[source,xml]
----
<route>
@@ -72,22 +97,21 @@ In XML DSL you can also refer to the processor by its class
name using `#class:`
</route>
----
-This also works in Java DSL:
-
-[source,java]
+YAML::
++
+[source,yaml]
----
-from("activemq:myQueue").process("#class:com.acme.MyProcessor");
+- route:
+ from:
+ uri: activemq:myQueue
+ steps:
+ - process:
+ ref: "#class:com.acme.MyProcessor"
----
+====
NOTE: For more details about the `#class:` prefix (and others) then see
xref:property-binding.adoc[Property Binding].
-However in Java DSL you would often use the type safe way and instantiate the
Processor directly as previously shown:
-
-[source,java]
-----
-from("activemq:myQueue").process(new MyProcessor());
-----
-
== Why use process when you can use to instead?
@@ -109,7 +133,3 @@ inner class gets a bit more complicated it is of course
advised to
refactor it into a separate class. This approach is better if you do not want
to use this processor again.
From reusability perspective, it is not recommended to use this approach with
anonymous inner classes.
-== See Also
-
-** xref:manual::consumertemplate.adoc[Consumer Template]: to learn how to
consume data (including within processors)
-** xref:manual::producertemplate.adoc[Producer Template]: to learn how to
produce data (including within processors)
diff --git a/docs/user-manual/modules/ROOT/pages/producertemplate.adoc
b/docs/user-manual/modules/ROOT/pages/producertemplate.adoc
index acd37df16bf5..9a6f59db008d 100644
--- a/docs/user-manual/modules/ROOT/pages/producertemplate.adoc
+++ b/docs/user-manual/modules/ROOT/pages/producertemplate.adoc
@@ -8,6 +8,11 @@ It can be configured with a default endpoint if you just want
to send
lots of messages to the same endpoint; or you can specify an
xref:endpoint.adoc[Endpoint] or uri as the first parameter.
+IMPORTANT: You are not meant to create a `ProducerTemplate` for each message
+invocation; you are meant to create a single instance on startup and
+keep it around. Also when you have finished using the `ProducerTemplate` you
should call
+the `stop()` method to close down all the resources it has been using.
+
The `sendBody()` method allows you to send any object to an endpoint
easily as shown:
@@ -40,7 +45,7 @@ that are used to control the messaging style to use:
In other words, all the methods on the `ProducerTemplate` that starts with
`sendXXX` are for InOnly messaging,
and all the methods starting with `requestXXX` are for InOut messaging.
-Lets see an example where we invoke an endpoint to get the response (InOut):
+Let's see an example where we invoke an endpoint to get the response (InOut):
[source,java]
----
diff --git a/docs/user-manual/modules/ROOT/pages/property-binding.adoc
b/docs/user-manual/modules/ROOT/pages/property-binding.adoc
index 31d578cebd6b..33519377b627 100644
--- a/docs/user-manual/modules/ROOT/pages/property-binding.adoc
+++ b/docs/user-manual/modules/ROOT/pages/property-binding.adoc
@@ -1,9 +1,9 @@
= Property binding in Camel
Camel supports binding property values (key=value) in many places such as
configuration of Camel
-components, endpoints, EIPs, routes, and Camel bootstrap configuration.
+components, endpoints,
xref:components:eips:enterprise-integration-patterns.adoc[EIPs], routes, and
Camel bootstrap configuration.
-Together with property placeholders, property placeholder functions, then
there is plenty of power, but also
+Together with xref:using-propertyplaceholder.adoc[property placeholders], then
there is plenty of power, but also
something that takes a little learning to master.
== Property binding features
@@ -134,13 +134,14 @@ PropertyBindingSupport.bindProperties(context, foo, prop);
This will then set the POJOs to have the following values:
+[source,properties]
----
Foo.name = James
Foo.Bar.age = 33
Foo.Bar.rider = true
----
-Instead of providing a map with all the parameters then a single parameter can
also be set using builder style as shown:
+Instead of providing a `Map` with all the parameters then a single parameter
can also be set using builder style as shown:
[source,java]
----
@@ -169,11 +170,11 @@ Foo class has a `getBar` method that returns the `Bar`
instance to use:
[source,java]
----
- private Bar bar = new Bar();
+private Bar bar = new Bar();
- public Bar getBar() {
- return bar;
- }
+public Bar getBar() {
+ return bar;
+}
----
It's a common practice for POJO classes to not create nested instances, but
instead on demand. So suppose
@@ -243,11 +244,10 @@ MyDriver driver = PropertyBindingSupport.build()
Notice how we use the `build(MyDriver.class)` to build the bean via the target
class `.withTarget(new MyDriverBuilder())`.
The build method will by default invoke `build` as the builder method, but you
can specify the name, such as `.build(MyDriver.class, "myBuilderMethod");`
-
== More details
-Property binding is notably used when running Camel in standalone mode with
Camel Main, or using Camel Spring Boot, Camel K,
-Camel Kafka Connector, or Camel Quarkus. All these runtimes have a similar way
of configuring via property bindings such
-as from `application.properties` files.
+Property binding is notably used when running Camel in standalone mode such as
with Camel Main.
+
+When using Camel Spring Boot, or Camel Quarkus, then these runtimes have their
own way of doing dependency injection and property binding.
See more at xref:components:others:main.adoc[Camel Main]
diff --git a/docs/user-manual/modules/faq/pages/what-is-camel.adoc
b/docs/user-manual/modules/faq/pages/what-is-camel.adoc
index 86ea997dc114..2ce2f4d63096 100644
--- a/docs/user-manual/modules/faq/pages/what-is-camel.adoc
+++ b/docs/user-manual/modules/faq/pages/what-is-camel.adoc
@@ -30,3 +30,7 @@ A highly recommended video introducing Apache Camel and the
concepts is a must t
* https://www.youtube.com/watch?v=5xQKG1TSrZc[Enterprise Integration Patterns
(EIP) | What is Apache Camel?]
+We also highly recommend taking a look at the AI powered research of Apache
Camel, which
+provides good technical overview and diagrams in a single wiki page:
+
+* https://deepwiki.com/apache/camel[DeepWiki - Apache Camel]
