You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by da...@apache.org on 2023/10/20 07:35:18 UTC
[camel] branch main updated: Remove outdated walk-throughs in documentation (#11778)
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 5f36146846e Remove outdated walk-throughs in documentation (#11778)
5f36146846e is described below
commit 5f36146846e206c80d05fa7f41353a0ca9b58cb9
Author: Aurélien Pupier <ap...@redhat.com>
AuthorDate: Fri Oct 20 09:35:12 2023 +0200
Remove outdated walk-throughs in documentation (#11778)
* they are based on examples that were removed from camel-examples in
Camel 3.8 or 3.9
* there is no more a JMS based example
Signed-off-by: Aurélien Pupier <ap...@redhat.com>
---
.../working-with-camel-core/pages/index.adoc | 7 -
docs/user-manual/modules/ROOT/pages/examples.adoc | 10 --
.../ROOT/pages/walk-through-an-example.adoc | 127 --------------
.../ROOT/pages/walk-through-another-example.adoc | 187 ---------------------
.../faq/pages/running-camel-standalone.adoc | 3 -
5 files changed, 334 deletions(-)
diff --git a/docs/main/modules/working-with-camel-core/pages/index.adoc b/docs/main/modules/working-with-camel-core/pages/index.adoc
index 1db9c0271b7..fa5127d92e6 100644
--- a/docs/main/modules/working-with-camel-core/pages/index.adoc
+++ b/docs/main/modules/working-with-camel-core/pages/index.adoc
@@ -1,12 +1,5 @@
= Working with Camel Core
-== Walk-troughs
-
-We have prepared these two guides to explain in greater detail a few of the concepts presented in the xref:getting-started:index.adoc[Getting Started With Camel] Guide.
-
-1. xref:manual::walk-through-an-example.adoc[Example Walk-through 1].
-2. xref:manual::walk-through-another-example.adoc[Example Walk-through 2].
-
== Routes
In Apache Camel, a _route_ is a set of processing steps that are applied to a message as it travels from a source to a destination. A route typically consists of a series of processing steps that are connected in a linear sequence.
diff --git a/docs/user-manual/modules/ROOT/pages/examples.adoc b/docs/user-manual/modules/ROOT/pages/examples.adoc
index 6493ec3d0db..c97a3961479 100644
--- a/docs/user-manual/modules/ROOT/pages/examples.adoc
+++ b/docs/user-manual/modules/ROOT/pages/examples.adoc
@@ -4,16 +4,6 @@ Once you have read about xref:getting-started.adoc[Getting Started] and
looked at the xref:components:eips:enterprise-integration-patterns.adoc[Enterprise
Integration Patterns], you might want to try out some examples.
-
-== Walk-throughs
-
-* Walk through the code of a
-xref:walk-through-an-example.adoc[beginner's example] so you can
-understand how things fit together using the Java xref:dsl.adoc[DSL] to
-set up some routes in a simple `main(...)` method.
-* Walk through the xref:walk-through-another-example.adoc[Spring XML DSL
-example] to look at XML-based routing.
-
[NOTE]
====
The examples listed below are hosted at Apache. We also offer the
diff --git a/docs/user-manual/modules/ROOT/pages/walk-through-an-example.adoc b/docs/user-manual/modules/ROOT/pages/walk-through-an-example.adoc
deleted file mode 100644
index 80e6b779437..00000000000
--- a/docs/user-manual/modules/ROOT/pages/walk-through-an-example.adoc
+++ /dev/null
@@ -1,127 +0,0 @@
-= Walk through an Example Code
-
-This mini-guide takes you through the source code of a
-https://github.com/apache/camel-examples/blob/main/examples/jms-file/src/main/java/org/apache/camel/example/jmstofile/CamelJmsToFileExample.java[simple
-example].
-
-Camel can be configured either by using xref:spring.adoc[Spring] or
-directly in Java - which
-https://github.com/apache/camel-examples/blob/main/examples/jms-file/src/main/java/org/apache/camel/example/jmstofile/CamelJmsToFileExample.java[this
-example does].
-
-We start with creating a xref:camelcontext.adoc[CamelContext] - which is
-a container for xref:components::index.adoc[Components],
-xref:routes.adoc[Routes]
-etc:
-
-[source,java]
-----
- CamelContext context = new DefaultCamelContext();
-----
-
-There is more than one way of adding a Component to the CamelContext. You can
-add components implicitly - when we set up the routing - as we do here
-for the
-xref:components::file-component.adoc[FileComponent]:
-
-[source,java]
-----
-context.addRoutes(new RouteBuilder() {
- public void configure() {
- from("test-jms:queue:test.queue").to("file://test");
- }
- });
-----
-
-or explicitly - as we do here when we add the JMS Component:
-
-[source,java]
-----
-ConnectionFactory connectionFactory = new ActiveMQConnectionFactory("vm://localhost?broker.persistent=false");
- // Note we can explicit name the component
- context.addComponent("test-jms", JmsComponent.jmsComponentAutoAcknowledge(connectionFactory));
-----
-
-or explicitly using the Component DSL which allows you to configure the components using DSL APIs and register them to the camel context. First you will have the import the maven package for the Component DSL:
-[source,xml]
-------------------------------------------------------------
-<dependency>
- <groupId>org.apache.camel</groupId>
- <artifactId>camel-componentdsl</artifactId>
- <version>x.x.x</version>
- <!-- use the same version as your Camel core version -->
-</dependency>
-------------------------------------------------------------
-
-and the register the component like this:
-[source,java]
-----
-ConnectionFactory connectionFactory = new ActiveMQConnectionFactory("vm://localhost?broker.persistent=false");
-
-ComponentsBuilderFactory.jms()
- .connectionFactory(connectionFactory)
- .acknowledgementMode(1)
- .register(context, "test-jms");
-----
-
-The above works with any JMS provider.
-
-In normal use, an external system would be firing messages or events
-directly into Camel through one of its xref:components::index.adoc[Components]
-but we are going to use tha xref:producertemplate.adoc[ProducerTemplate]
-which is a really easy way for testing your
-configuration:
-
-[source,java]
-----
-ProducerTemplate template = context.createProducerTemplate();
-----
-
-Next you *must* start the camel context. If you are using
-xref:spring.adoc[Spring] to configure the camel context this is
-automatically done for you; though if you are using a pure Java approach
-then you just need to call the start() method
-
-[source,java]
-----
-camelContext.start();
-----
-
-This will start all of the configured routing rules.
-
-So after starting the xref:camelcontext.adoc[CamelContext], we can fire
-some objects into
-camel:
-
-[source,java]
-----
-for (int i = 0; i < 10; i++) {
- template.sendBody("test-jms:queue:test.queue", "Test Message: " + i);
-}
-----
-
-== What happens?
-
-From the
-xref:producertemplate.adoc[ProducerTemplate]
-- we send objects (in this case text) into the
-xref:camelcontext.adoc[CamelContext] to the Component
-_test-jms:queue:test.queue_. These text objects will be
-xref:type-converter.adoc[converted automatically] into JMS Messages and
-posted to a JMS Queue named _test.queue_. When we set up the
-xref:routes.adoc[Route], we configured the
-xref:components::file-component.adoc[FileComponent] to listen off the _test.queue_.
-
-The File xref:components::file-component.adoc[FileComponent] will take messages off the
-Queue, and save them to a directory named _test_. Every message will be
-saved in a file that corresponds to its destination and message id.
-
-Finally, we configured our own listener in the xref:routes.adoc[Route] -
-to take notifications from the xref:components::file-component.adoc[FileComponent] and print
-them out as text.
-
-*That's it!*
-
-If you have the time then use 5 more minutes to
-xref:walk-through-another-example.adoc[Walk through another example]
-that demonstrates the Spring DSL (XML based) routing.
diff --git a/docs/user-manual/modules/ROOT/pages/walk-through-another-example.adoc b/docs/user-manual/modules/ROOT/pages/walk-through-another-example.adoc
deleted file mode 100644
index 02177c83f87..00000000000
--- a/docs/user-manual/modules/ROOT/pages/walk-through-another-example.adoc
+++ /dev/null
@@ -1,187 +0,0 @@
-= Walk through another example
-
-== Introduction
-
-Continuing the walk from our first
-xref:walk-through-an-example.adoc[example], we take a closer look at the
-routing and explain a few pointers - so you won't walk into a bear trap,
-but can enjoy an after-hours walk to the local pub for a large beer.
-
-First we take a moment to look at the
-xref:components:eips:enterprise-integration-patterns.adoc[Enterprise Integration
-Patterns] - the base pattern catalog for integration scenarios. In
-particular we focus on http://www.enterpriseintegrationpatterns.com/PipesAndFilters.html[Pipes and Filters] -
-a central pattern. This is used to route messages through a sequence of
-processing steps, each performing a specific function - much like the
-Java Servlet Filters.
-
-== Pipes and filters
-
-In this sample we want to process a message in a sequence of steps where
-each steps can perform their specific function. In our example we have a
-xref:components::jms-component.adoc[JMS] queue for receiving new orders. When an order is
-received we need to process it in several steps:
-
-* validate
-* register
-* send confirm email
-
-This can be created in a route like this:
-
-[source,xml]
-----
-<route>
- <from uri="jms:queue:order"/>
- <pipeline>
- <bean ref="validateOrder"/>
- <bean ref="registerOrder"/>
- <bean ref="sendConfirmEmail"/>
- </pipeline>
-</route>
-----
-
-**Pipeline is default**
-
-In the route above we specify `pipeline` but it can be omitted as its
-default, so you can write the route as:
-
-[source,xml]
-----
-<route>
- <from uri="jms:queue:order"/>
- <bean ref="validateOrder"/>
- <bean ref="registerOrder"/>
- <bean ref="sendConfirmEmail"/>
-</route>
-----
-
-This is commonly used not to state the pipeline.
-
-An example where the pipeline needs to be used, is when using a
-multicast and "one" of the endpoints to send to (as a logical group) is
-a pipeline of other endpoints. For example.
-
-[source,xml]
-----
-<route>
- <from uri="jms:queue:order"/>
- <multicast>
- <to uri="log:org.company.log.Category"/>
- <pipeline>
- <bean ref="validateOrder"/>
- <bean ref="registerOrder"/>
- <bean ref="sendConfirmEmail"/>
- </pipeline>
- </multicast>
-</route>
-----
-
-The above sends the order (from `jms:queue:order`) to two locations at
-the same time, our log component, and to the "pipeline" of beans which
-goes one to the other. If you consider the opposite, sans the
-`<pipeline>`
-
-[source,xml]
-----
-<route>
- <from uri="jms:queue:order"/>
- <multicast>
- <to uri="log:org.company.log.Category"/>
- <bean ref="validateOrder"/>
- <bean ref="registerOrder"/>
- <bean ref="sendConfirmEmail"/>
- </multicast>
-</route>
-----
-
-you would see that multicast would not "flow" the message from one bean
-to the next, but rather send the order to all 4 endpoints (1x log, 3x
-bean) in parallel, which is not (for this example) what we want. We need
-the message to flow to the validateOrder, then to the registerOrder,
-then the sendConfirmEmail so adding the pipeline, provides this
-facility.
-
-Where as the `bean ref` is a reference for a spring bean id, so we
-define our beans using regular Spring XML as:
-
-[source,xml]
-----
-<bean id="validateOrder" class="com.mycompany.MyOrderValidator"/>
-----
-
-Our validator bean is a plain POJO that has no dependencies to Camel
-what so ever. So you can implement this POJO as you like. Camel uses
-rather intelligent xref:bean-binding.adoc[Bean Binding] to invoke your
-POJO with the payload of the received message. In this example we will
-*not* dig into this how this happens. You should return to this topic
-later when you got some hands on experience with Camel how it can easily
-bind routing using your existing POJO beans.
-
-So what happens in the route above. Well when an order is received from
-the xref:components::jms-component.adoc[JMS] queue the message is routed like
-pipes and filters:
-1. payload from the xref:components::jms-component.adoc[JMS] is sent as input to the
-validateOrder bean +
-2. the output from validateOrder bean is sent as input to the
-registerOrder bean +
-3. the output from registerOrder bean is sent as input to the
-sendConfirmEmail bean
-
-== Using Camel Components
-
-In the route lets imagine that the registration of the order has to be
-done by sending data to a TCP socket that could be a big mainframe. As
-Camel has many xref:components::index.adoc[Components] we will use the
-camel-mina component that supports xref:components::mina-component.adoc[TCP] connectivity. So
-we change the route to:
-
-[source,syntaxhighlighter-pre]
-----
-<route>
- <from uri="jms:queue:order"/>
- <bean ref="validateOrder"/>
- <to uri="mina:tcp://mainframeip:4444?textline=true"/>
- <bean ref="sendConfirmEmail"/>
-</route>
-----
-
-What we now have in the route is a `to` type that can be used as a
-direct replacement for the bean type. The steps is now:
-1. payload from the xref:components::jms-component.adoc[JMS] is sent as input to the
-validateOrder bean
-2. the output from validateOrder bean is sent as text to the mainframe
-using TCP
-3. the output from mainframe is sent back as input to the
-sendConfirmEmai bean
-
-What to notice here is that the `to` is not the end of the route (the
-world) in this example it's used in the middle of the
-xref:components:eips:pipeline-eip.adoc[Pipes and filters]. In fact we can change
-the `bean` types to `to` as well:
-
-[source,syntaxhighlighter-pre]
-----
-<route>
- <from uri="jms:queue:order"/>
- <to uri="bean:validateOrder"/>
- <to uri="mina:tcp://mainframeip:4444?textline=true"/>
- <to uri="bean:sendConfirmEmail"/>
-</route>
-----
-
-As the `to` is a generic type we must state in the uri scheme which
-component it is. So we must write *bean:* for the xref:components::bean-component.adoc[Bean]
-component that we are using.
-
-== Conclusion
-
-This example was provided to demonstrate the Spring DSL (XML based) as
-opposed to the pure Java DSL from the
-xref:walk-through-an-example.adoc[first example]. And as well to point
-about that the `to` doesn't have to be the last node in a route graph.
-
-This example is also based on the *in-only* message exchange pattern.
-What you must understand as well is the *in-out* message exchange
-pattern, where the caller expects a response. We will look into this in
-another example.
-
diff --git a/docs/user-manual/modules/faq/pages/running-camel-standalone.adoc b/docs/user-manual/modules/faq/pages/running-camel-standalone.adoc
index 9db92c287f8..6e8cf0d13cf 100644
--- a/docs/user-manual/modules/faq/pages/running-camel-standalone.adoc
+++ b/docs/user-manual/modules/faq/pages/running-camel-standalone.adoc
@@ -10,9 +10,6 @@ by the xref:ROOT:camel-maven-plugin.adoc[Camel Maven Plugin].
The starting guide is a good place to start: +
xref:ROOT:getting-started.adoc[Getting Started]
-And the concrete walk through a plain old java main example: +
-xref:ROOT:walk-through-an-example.adoc[Walk through an Example]
-
The FAQ have some more details: +
xref:index.adoc[FAQ]