This is an automated email from the ASF dual-hosted git repository.
pascalschumacher pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/camel.git
commit 00cf1cf6e2d73d9924daea9d31dba2e1c71321b8
Author: PascalSchumacher <pascalschumac...@gmx.net>
AuthorDate: Wed Feb 3 21:08:48 2021 +0100
Fix some typos and improve the grammar of the Camel 3.8 Upgrade Guide.
---
.../ROOT/pages/camel-3x-upgrade-guide-3_8.adoc | 39 +++++++++++-----------
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git
a/docs/user-manual/modules/ROOT/pages/camel-3x-upgrade-guide-3_8.adoc
b/docs/user-manual/modules/ROOT/pages/camel-3x-upgrade-guide-3_8.adoc
index bf7407c..68343e9 100644
--- a/docs/user-manual/modules/ROOT/pages/camel-3x-upgrade-guide-3_8.adoc
+++ b/docs/user-manual/modules/ROOT/pages/camel-3x-upgrade-guide-3_8.adoc
@@ -10,12 +10,12 @@ from both 3.0 to 3.1 and 3.1 to 3.2.
Camel will now initialize all routes during initialization of `CamelContext`
itself.
Before all routes where lazy initialized when they were started, which happens
in the starting phase of `CamelContext`.
-But moving this forward to initialization phase, then we ensure all is done
together.
+By moving this forward to initialization phase, we ensure all is done together.
This means that all the resources used in the routes such as EIPs, processors,
beans, components, data formats, languages etc.
are also initialized. An affect of this change is that any custom Camel
component that may do initialization logic in
the constructors of `Consumer` or `Producer` should *not* do this, but move
this logic to `doInit` or `doStart` where
-such logic correctly belongs.
+such logic belongs.
=== API changes
@@ -26,10 +26,11 @@ The following type names are renamed in `CamelEvent.Type`
enum:
- `CamelContextRoutesStopping` to `RoutesStopping`
- `CamelContextRoutesStopped` to `RoutesStopped`
-The method `isOnlyDynamicQueryParameters` is removed from
`org.apache.camel.spi.SendDynamicAware` and
+The method `isOnlyDynamicQueryParameters` was removed from
`org.apache.camel.spi.SendDynamicAware` and
`org.apache.camel.support.component.SendDynamicAwareSupport` classes.
-The `PackageScanResourceResolver` has been revisited and `findResources`` now
returns a colelctions of `org.apache.camel.spi.Resource` which provide both the
location of the resolved resources an a method to open the related InpuStream:
+The class `PackageScanResourceResolver` has been revisited and the method
`findResources` now returns a collection of `org.apache.camel.spi.Resource`
+which provide both the location of the resolved resources and a method to open
the related `InpuStream`:
[source,java]
----
@@ -38,12 +39,12 @@ Collection<Resource> findResources(String location) throws
Exception;
=== OnCompletion EIP
-The `onCompletion` EIP has fixed it could trigger multiple completions for a
given `Exchange`
+The `onCompletion` EIP has been fixed. It could trigger multiple completions
for a given `Exchange` before.
=== Transactions and Multicast, Splitter, or Recipient List EIPs
-When using `transacted` in Camel routes with Multicast, Splitter, or Recipient
List EIPs, then the exection strackframe
-may grown deep and could cause Stack overflow exception. This has been fixed
by refactoring the EIP into a special
+When using `transacted` in Camel routes with Multicast, Splitter, or Recipient
List EIPs, the exection strackframe
+could grown deep and this could cause a stack overflow exception. This has
been fixed by refactoring the EIP into a special
transacted mode and the existing reactive mode.
We do not anticipate any issues but if you are using transactions and these
EIPs then we would like to have feedback
@@ -51,7 +52,7 @@ if you encounter any problems with upgrading.
=== camel-jackson
-When using XML DSL then `jsonView` has been renamed to `jsonViewTypeName` and
made general available in the model,
+In the XML DSL `jsonView` has been renamed to `jsonViewTypeName` and made
general available in the model
and for the lightweight `camel-xml-io` route parser.
=== camel-caffeine-lrucache
@@ -59,36 +60,36 @@ and for the lightweight `camel-xml-io` route parser.
This LRUCache implementation is using an algorithm where elements that are
removed may not be in strict order, and therefore
not ideal for LRU caches assuming ordering.
-The need for this implementation is not needed anymore in Camel 3, as we are
using a simpler default implementation internally.
-This component is deprecated, and has been removed as Maven dependency in
`camel-core` pom.xml file.
+The implementation is not needed anymore in Camel 3, as we are using a simpler
default implementation internally.
+This component was deprecated, and has been removed as Maven dependency in
`camel-core` pom.xml file.
=== camel-infinispan
The infinispan component has been splitup into client and embedded server mode.
The module `camel-infinispan` is the client mode, and
`camel-infinispan-embedded` is for server mode.
-Most use cases would be client mode to integrate with an existing Infinispan
cluster, and hence why it was choosen
+Most use cases would be client mode to integrate with an existing Infinispan
cluster, therefore it was choosen
to be the `camel-infinispan` component.
=== camel-activemq and camel-jms
-The JMS and ActiveMQ component now supports optimized toD EIP pattern by using
a single endpoint/producer for dynamic destination names.
+The JMS and ActiveMQ components now support the optimized toD EIP pattern by
using a single endpoint/producer for dynamic destination names.
=== camel-sjms and camel-sjms2
-These two components has been overhauled and re-written with the goals of
being more feature complete with the Spring JMS component.
-They also no longer uses their own connection pooling, but let you use the
existing 3rd party pooling for `ConnectionFactory` which is common practice.
-The components are now also reactive and non-blocking, and also supports
optimized toD EIP pattern by using a single endpoint/producer for dynamic
destination names.
+These two components have been overhauled and re-written with the goal of
being more feature complete with the Spring JMS component.
+They no longer uses their own connection pooling, but let you use the existing
3rd party pooling for `ConnectionFactory` which is common practice.
+The components are now reactive and non-blocking, and support the optimized
toD EIP pattern by using a single endpoint/producer for dynamic destination
names.
Many of the previous features and configuration options have been
removed/renamed.
To migrate you need to read their documentation and see what options they now
offer.
=== Camel-AWS2-SNS
-The policy option now expects a file, since the policy are going to be
complex. It can be from classpath:, http: or file: etc.
+The policy option now expects a file, since the policy is going to be complex.
It can be from classpath:, http: or file: etc.
=== Camel-AWS2-SQS
-The policy option now expects a file, since the policy are going to be
complex. It can be from classpath:, http: or file: etc.
+The policy option now expects a file, since the policy is going to be complex.
It can be from classpath:, http: or file: etc.
=== Camel-Github
@@ -116,9 +117,9 @@ Other information has been stored in headers declared in
GitHubConstants class:
There are now two components for Infinispan:
- *camel-infinispan* to integrate with remote caches through the Hot Rod
protocol (scheme: *infinispan*).
-- *camel-infinispan-embedded* to integrate with local/embedded caches
(scheme: *infinispan-embedded*).
+- *camel-infinispan-embedded* to integrate with local/embedded caches (scheme:
*infinispan-embedded*).
-As conseguence of the refactor
+As consequence of the refactor:
- the remote and embedded endpoints provide support the same capabilities, as
example queries were only possible on a remote cache and now they are suported
on both remote and local/embedded caches
- the configuration options for the endpoint are now specific to the context
which remove the possibility to mix unrelated propertis
