[camel] 05/15: Polish and cleanup documentation

[da...@apache.org]

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

commit adbd552dabd41f85a65b0de9eacc3bd79be3eea2
Author: Claus Ibsen <cl...@gmail.com>
AuthorDate: Mon Aug 16 16:54:47 2021 +0200

    Polish and cleanup documentation
---
 .../ROOT/pages/transactionerrorhandler.adoc        | 172 ---------------------
 1 file changed, 172 deletions(-)

diff --git a/docs/user-manual/modules/ROOT/pages/transactionerrorhandler.adoc b/docs/user-manual/modules/ROOT/pages/transactionerrorhandler.adoc
deleted file mode 100644
index 2b1f276..0000000
--- a/docs/user-manual/modules/ROOT/pages/transactionerrorhandler.adoc
+++ /dev/null
@@ -1,172 +0,0 @@
-[[TransactionErrorHandler-TransactionErrorHandler]]
-= TransactionErrorHandler
-
-*Since Camel 2.0*
-
-This is the new default transaction error handler in Camel 2.0 onwards,
-used for transacted routes.
-
-It uses the same base as the
-xref:defaulterrorhandler.adoc[DefaultErrorHandler] so it has the same
-feature set as this error handler.
-
-By default any exception thrown during routing will be propagated back
-to the caller and the xref:exchange.adoc[Exchange] ends immediately.
-However you can use the xref:exception-clause.adoc[Exception Clause] to
-catch a given exception and lower the exception by marking it as
-handled. If so the exception will *not* be sent back to the caller and
-the xref:exchange.adoc[Exchange] continues to be routed.
-
-[[TransactionErrorHandler-Example]]
-== Example
-
-In this route below, any exception thrown in eg the `validateOrder` bean
-will be propagated back to the caller, and its the jetty endpoint. It
-will return a HTTP error message back to the client.
-
-[source,java]
-----
-from("jetty:http://localhost/myservice/order").transacted().to("bean:validateOrder").to("jms:queue:order");
-----
-
-We can add a *onException* in case we want to catch certain exceptions
-and route them differently, for instance to catch a
-*ValidationException* and return a fixed response to the caller.
-
-[source,java]
-----
-onException(ValidationException.class).handled(true).transform(body(constant("INVALID ORDER")));
-
-from("jetty:http://localhost/myservice/order").transacted().to("bean:validateOrder").to("jms:queue:order");
-----
-
-When the *ValidationException* is thrown from the validate order bean it
-is intercepted by the
-xref:transactionerrorhandler.adoc[TransactionErrorHandler] and it let
-the `onException(ValidationException.class` handle it so the
-xref:exchange.adoc[Exchange] is routed to this route and since we use
-*handled(true)* then the original exception is lowered (= cleared) and
-we transform the message into a fixed response that are returned to
-jetty endpoint that returns it to the original caller.
-
-[[TransactionErrorHandler-Conventionoverconfiguration]]
-== Convention over configuration
-
-When you configure a route to be transacted you just mark it as
-transacted as follows:
-
-[source,java]
-----
-from("jms:queue:foo").transacted().to("bean:handleFoo");
-----
-
-And in Spring DSL:
-
-[source,xml]
-----
-<route>
-   <from uri="jms:queue:foo"/>
-   <transacted/>
-   <to uri="bean:handleFoo"/>
-</route>
-----
-
-What happens is that Camel will automatic lookup the right Spring
-transaction manager. It does using the following rules, in order: +
-1. If there is only 1 bean with the type
-`org.apache.camel.spi.TransactedPolicy` then its used. +
-2. If there is a bean with id `PROPAGATION_REQUIRED` and of type
-`org.apache.camel.spi.TransactedPolicy` then its used. +
-3. If there is only 1 bean with the type
-`org.springframework.transaction.PlatformTransactionManager` then its
-used.
-
-However you can explicit configure what you want to use. For instance
-the *transacted* DSL accepts a String reference parameter to indicate
-the bean id of the `org.apache.camel.spi.TransactedPolicy` bean to use
-in case you have multiple beans. For instance a PROPAGATION_REQUIRES_NEW
-bean.
-
-The *transactionErrorHandler* like the *transacted* also supprts
-convention over configuration and it will also automatic lookup the
-right Spring transaction manager. It does using the following rules, in
-order: +
-1. If there is only 1 bean with the type
-`org.apache.camel.spi.TransactedPolicy` then its used. +
-2. If there is a bean with id `PROPAGATION_REQUIRED` and of type
-`org.apache.camel.spi.TransactedPolicy` then its used. +
-3. If there is only 1 bean with the type
-`org.springframework.transaction.support.TransactionTemplate` then its
-used. +
-4. If there is only 1 bean with the type
-`org.springframework.transaction.PlatformTransactionManager` then its
-used.
-
-However you can explicit configure what you want to use. For instance
-the *transactionErrorHandler* DSL accepts either a TransactedPolicy, a
-TransactionTemplate or a PlatformTransactionManager.
-
-[[TransactionErrorHandler-UsingCameltodoredeliveries]]
-== Using Camel to do redeliveries
-
-As the xref:transactionerrorhandler.adoc[TransactionErrorHandler] also
-supports to let Camel do redeliveries you can use both worlds. Letting
-Camel do some redeliveries and at the end the backing transaction
-manager doing other redeliveries. In fact in the end the transaction
-manager have the final word. That means if Camel cannot process the
-exchange then its thrown back to the transaction manager that will
-perform the rollback, and redelivery.
-
-[[TransactionErrorHandler-ExamplewithusingCameltodoredeliveries]]
-=== Example with using Camel to do redeliveries
-
-In the route below we have configured a transaction error handler. It
-will by default do local redeliveries up till 6 times. In Case Camel
-could not redeliver the message it will be thrown back to the
-transaction manager that will do a rollback, and a redelivery if it was
-configured to do so.
-
-Notice that as we have all the powers from
-xref:defaulterrorhandler.adoc[DefaultErrorHandler] we can configure an
-*onException* where we state that in case of this particular exception,
-an IllegalArgumentException we will only do redeliveries up till 4
-times. (Yes the code is based on an unit test).
-
-And also notice that we mark the routes as transacted using
-*transacted*. This is always needed to instruct Camel that these routes
-are transacted.
-
-If you do not provide any Spring TransactionTemplate to either the
-*transactionErrorHandler*, then Camel will automatic lookup in the
-Spring application context for a transaction manager to use. See more in
-the Convention over configuration section on this page.
-
-And now the route:
-
-[source,java]
-----
-// configure transacted error handler to use up till 4 redeliveries
-// we have not passed in any spring TX manager. Camel will automatic
-// find it in the spring application context. You only need to help
-// Camel in case you have multiple TX managers
-errorHandler(transactionErrorHandler().maximumRedeliveries(6));
-
-// speical for this exception we only want to do it at most 4 times
-onException(IllegalArgumentException.class).maximumRedeliveries(4);
-
-from("direct:okay")
-    // marks this route as transacted, and we dont pass in any parameters so we
-    // will auto lookup and use the Policy defined in the spring XML file
-    .transacted()
-    .setBody(constant("Tiger in Action")).bean("bookService")
-    .setBody(constant("Elephant in Action")).bean("bookService");
-
-// marks this route as transacted that will use the single policy defined in the registry
-from("direct:fail")
-    // marks this route as transacted, and we dont pass in any parameters so we
-    // will auto lookup and use the Policy defined in the spring XML file
-    .transacted()
-    .setBody(constant("Tiger in Action")).bean("bookService")
-    .setBody(constant("Donkey in Action")).bean("bookService");
-----
-