This closes #3372

docs/user-manual/en/address-model.md

@@ -292,7 +292,7 @@ is controlled by following:
 Parameter|Description
 ---|---
 `auto-create-addresses`|When set to true, the broker will create the address requested by the client if it does not exist already. The default is `true`.
-`auto-delete-addresses`|When set to true, the broker will be delete any **auto-created** adddress once all of it’s queues have been deleted. The default is `true`
+`auto-delete-addresses`|When set to true, the broker will be delete any **auto-created** address once all of it’s queues have been deleted. The default is `true`
 `default-address-routing-type`|The routing type to use if the client does not specify one. Possible values are `MULTICAST` and `ANYCAST`. See earlier in this chapter for more information about routing types. The default value is `MULTICAST`.
 
 ### Auto Address Creation
@@ -508,7 +508,7 @@ Open the file `<broker-instance>/etc/broker.xml` for editing.
 If a user requires to statically configure a queue that routes exclusively to
 one active consumer the **exclusive** flag can be enabled on the queue.
   
-When **exclusive** is set to **true** the queue will route messages to the a
+When **exclusive** is set to **true** the queue will route messages to a
 single active consumer.  When the active consumer that is being routed to is
 detached from the queue, if another active consumer exist, one will be chosen
 and routing will now be exclusive to it.
@@ -534,7 +534,7 @@ for example where a queue needs to be defined so a consumer can bind,
 but you want to disable message routing to it for the time being.
 
 Or you need to stop message flow to the queue to allow investigation keeping the consumer bound, 
-but dont wish to have further messages routed to the queue to avoid message build up.
+but don't wish to have further messages routed to the queue to avoid message build up.
   
 When **enabled** is set to **true**  the queue will have messages routed to it. (default)
 
@@ -615,7 +615,7 @@ the queue once the client disconnects.
 
 When a client requests to subscribe to a point to point address.  The protocol
 manager will look up the queue associated with the point to point address.
-This queue should have the same name as the addresss.
+This queue should have the same name as the address.
 
 **Note:** If the queue is auto created, it will be auto deleted once there are
 no consumers and no messages in it.  For more information on auto create see

docs/user-manual/en/core.md

@@ -187,7 +187,7 @@ address is specified at send time for the message.
 
 Here's a very simple program using the core messaging API to send and receive a
 message. Logically it's comprised of two sections: firstly setting up the
-producer to write a message to an *addresss*, and secondly, creating a *queue*
+producer to write a message to an *address*, and secondly, creating a *queue*
 for the consumer using anycast routing, creating the consumer, and *starting*
 it.
 

docs/user-manual/en/federation-address.md

@@ -36,7 +36,7 @@ If `max-hops` is not configured correctly, consumers will get multiple copies of
 ![Address Federation](images/federation-address-complete-graph.png)
 Figure 3. Address Federation - Full Mesh
 
-If not already spotted, the setup is identical to symemtric but simply where all brokers are symmetrically federating each other, creating a full mesh.
+If not already spotted, the setup is identical to symmetric but simply where all brokers are symmetrically federating each other, creating a full mesh.
 
 As illustrated, a publisher and consumer are connected to each broker. 
 Queues and thus consumers on those queues, can receive messages published by either publisher.

docs/user-manual/en/federation-queue.md

@@ -110,7 +110,7 @@ Let's take a look at all the `queue-policy` parameters in turn, in order of prio
 - `priority-adjustment` when a consumer attaches its priority is used to make the upstream consumer, 
 but with an adjustment by default -1, so that local consumers get load balanced first over remote, this enables this to be configurable should it be wanted/needed. 
 
-- `include-federated` by default this is false, we dont federate a federated consumer, this is to avoid issue, where in symmetric or any closed loop setup you could end up when no "real" consumers attached with messages flowing round and round endlessly. 
+- `include-federated` by default this is false, we don't federate a federated consumer, this is to avoid issue, where in symmetric or any closed loop setup you could end up when no "real" consumers attached with messages flowing round and round endlessly. 
 
     There is though a valid case that if you dont have a close loop setup e.g. three brokers in a chain (A->B->C) with producer at broker A and consumer at C, you would want broker B to re-federate the consumer onto A.
 

docs/user-manual/en/intercepting-operations.md

@@ -74,7 +74,7 @@ understand how to make your interceptor available to the broker.
 
 ## Interceptors on the Client Side
 
-The interceptors can also be run on the Apache ActiveMQ Artemit client side to
+The interceptors can also be run on the Apache ActiveMQ Artemis client side to
 intercept packets either sent by the client to the server or by the server to
 the client.  This is done by adding the interceptor to the `ServerLocator` with
 the `addIncomingInterceptor(Interceptor)` or

docs/user-manual/en/logging.md

@@ -118,11 +118,11 @@ formatter.PATTERN.pattern=%d{HH:mm:ss,SSS} %-5p [%c] %s%E%n
 
 ## Configuring Audit Logging
 
-There are 3 audit loggers that can be enabled separately and audit sifferent types of events, these are:
+There are 3 audit loggers that can be enabled separately and audit different types of events, these are:
 
 1. Base logger: This is a highly verbose logger that will capture most events that occur on JMX beans
 2. Resource logger: This logs creation, updates and deletion of resources such as Addresses and Queues and also authentication, the main purpose of this is to track console activity and access to broker.
-3. Message logger: this logs message production and consumption of messages and will have a potentially negatibve affect on performance
+3. Message logger: this logs message production and consumption of messages and will have a potentially negative affect on performance
 
 These are disabled by default in the logging.properties configuration file:
 

docs/user-manual/en/management.md

@@ -141,7 +141,7 @@ Individual addresses can be managed using the `AddressControl` interface.
 
   The `AddressControl` can pause and resume an address and all the queues that
   are bound to it. Newly added queue will be paused too until the address is resumed.
-  Thus all messages sent to the address will be recived but not delivered. When it is
+  Thus all messages sent to the address will be received but not delivered. When it is
   resumed, delivering will occur again.
 
 #### Queue Management

docs/user-manual/en/masking-passwords.md

@@ -98,7 +98,7 @@ default `PropertiesLoginModule` will not decode the passwords in
 `artemis-users.properties` but will instead hash the input and compare the two
 hashed values for password verification.
 
-Use the following command from the CLI of the Aremtis *instance* you wish to
+Use the following command from the CLI of the Artemis *instance* you wish to
 add the user/password to. This command will not work from the Artemis home
 used to create the instance, and it will also not work unless the broker has
 been started. For example:

docs/user-manual/en/restart-sequence.md

@@ -47,7 +47,7 @@ no replication that is happening from the master broker to the slave.
 
 In such situation, there can be some client applications that are connected to the master 
 broker and other connected to the slave broker. Now after we restart the brokers and the 
-the cluster is properly formed.
+cluster is properly formed.
 
 Here, the clients that were connected to the master broker during the split brain situation 
 are auto-connected to the cluster and start processing the messages. But the clients that got 

docs/user-manual/en/security.md

@@ -12,7 +12,7 @@ when the cache reaches its maximum size in which case the least-recently used
 entry is removed or when an entry has been in the cache "too long".
 
 The size of the caches are controlled by the `authentication-cache-size` and
-`authorization-cache-size` configuration parameters. Both deafult to `1000`.
+`authorization-cache-size` configuration parameters. Both default to `1000`.
 
 How long cache entries are valid is controlled by
 `security-invalidation-interval`, which is in milliseconds. Using `0` will
@@ -1255,7 +1255,7 @@ using HTTPS protocol. e.g.:
 
 As shown in the example, to enable https the first thing to do is config the
 `bind` to be an `https` url. In addition, You will have to configure a few
-extra properties desribed as below.
+extra properties described as below.
 
 - `keyStorePath` - The path of the key store file.
 

docs/user-manual/en/stomp.md

@@ -329,7 +329,7 @@ The type of this attribute is integer. When this attributed is configured, the
 broker will check the size of the body of each STOMP frame arrived from
 connections established with this acceptor. If the size of the body is equal or
 greater than the value of `stompMinLargeMessageSize`, the message will be
-persisted as a large message. When a large message is delievered to a STOMP
+persisted as a large message. When a large message is delivered to a STOMP
 consumer, the broker will automatically handle the conversion from a large
 message to a normal message, before sending it to the client.
 
@@ -374,7 +374,7 @@ STOMP clients can use the `consumer-window-size` header on the `SUBSCRIBE`
 frame to control the flow of messages to clients. This is broadly discussed in
 the [Flow Control](flow-control.md) chapter.
 
-This ability is similiar to the `activemq.prefetchSize` header supported by
+This ability is similar to the `activemq.prefetchSize` header supported by
 ActiveMQ 5.x. However, that header specifies the size in terms of *messages*
 whereas `consumer-window-size` specifies the size in terms of *bytes*. ActiveMQ
 Artemis supports the `activemq.prefetchSize` header for backwards compatibility

docs/user-manual/en/transformers.md

@@ -1,6 +1,6 @@
 # Transformers
 
-A transfomer, as the name suggests, is a component which transforms a message.
+A transformer, as the name suggests, is a component which transforms a message.
 For example, a transformer could modify the body of a message or add or remove
 properties. Both [diverts](diverts.md) and [core bridges](core-bridges.md)
 support.
@@ -47,4 +47,4 @@ specified using a slightly different syntax, e.g.:
 
 Any transformer implementation needs to be added to the broker's classpath. See
 the documentation on [adding runtime dependencies](using-server.md#adding-runtime-dependencies)
-to understand how to make your transformer available to the broker.
+to understand how to make your transformer available to the broker.