You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@karaf.apache.org by jb...@apache.org on 2019/10/04 09:04:33 UTC
[karaf-cellar] branch master updated: Some grammatical + typo fixes
for the manual
This is an automated email from the ASF dual-hosted git repository.
jbonofre pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/karaf-cellar.git
The following commit(s) were added to refs/heads/master by this push:
new 647d48a Some grammatical + typo fixes for the manual
new d9626d2 Merge pull request #64 from coheigea/manual
647d48a is described below
commit 647d48a1b3b75bec683d82230188fd19b7673720
Author: Colm O hEigeartaigh <co...@apache.org>
AuthorDate: Thu Jun 13 17:06:42 2019 +0100
Some grammatical + typo fixes for the manual
---
.../architecture-guide/supported_events.adoc | 2 +-
manual/src/main/asciidoc/user-guide/groups.adoc | 27 +++++++++++-----------
manual/src/main/asciidoc/user-guide/hazelcast.adoc | 8 +++----
.../src/main/asciidoc/user-guide/introduction.adoc | 15 ++++++------
manual/src/main/asciidoc/user-guide/log.adoc | 2 +-
manual/src/main/asciidoc/user-guide/nodes.adoc | 14 +++++------
6 files changed, 35 insertions(+), 33 deletions(-)
diff --git a/manual/src/main/asciidoc/architecture-guide/supported_events.adoc b/manual/src/main/asciidoc/architecture-guide/supported_events.adoc
index af9cdab..c63462b 100644
--- a/manual/src/main/asciidoc/architecture-guide/supported_events.adoc
+++ b/manual/src/main/asciidoc/architecture-guide/supported_events.adoc
@@ -35,4 +35,4 @@ memory of the default group and will also be broadcasted to all other default gr
This happens for all PIDs but not for org.apache.karaf.cellar.node which is marked as blacklisted
and will never be written or read from the distributed memory, nor will be broadcasted via the topic.
-The user can add/remove any PID he wishes to the whitelist/blacklist.
+The user can add/remove any PID they wish to the whitelist/blacklist.
diff --git a/manual/src/main/asciidoc/user-guide/groups.adoc b/manual/src/main/asciidoc/user-guide/groups.adoc
index afcb3a1..40959f6 100644
--- a/manual/src/main/asciidoc/user-guide/groups.adoc
+++ b/manual/src/main/asciidoc/user-guide/groups.adoc
@@ -14,9 +14,9 @@
=== Cellar groups
-You can define groups in Cellar. A group allows you to define specific nodes and resources that are to be
-working together. This permits some nodes (those outside the group) not to need to sync'ed with changes of
-a node within a group.
+You can define groups in Cellar. A group allows you to define specific nodes and resources that are to
+work together. This means that nodes outside the group are not sync'ed with the
+changes of a node within a group.
By default, the Cellar nodes go into the default group:
@@ -37,7 +37,7 @@ You can create a new group using the group-create command:
karaf@root()> cluster:group-create test
----
-For now, the test group hasn't any nodes:
+For now, the test group hasn't got any nodes:
----
karaf@node1()> cluster:group-list
@@ -55,7 +55,7 @@ Cellar can manipulate features and features repositories on cluster groups.
You can use `cluster:feature-*` commands or the corresponding MBean for that.
-You can list the features repositories on a given cluster group:
+You can list the features repositories for a given cluster group:
----
karaf@node1()> cluster:feature-repo-list default
@@ -189,13 +189,13 @@ You can uninstall a bundle from a cluster group using the `cluster:bundle-uninst
karaf@node1()> cluster:bundle-uninstall default commons-lang
----
-Like for the feature, Cellar provides a bundle listener disabled by default in `etc/org.apache.karaf.cellar.nodes.cfg`:
+As for features, Cellar provides a bundle listener that is disabled by default in `etc/org.apache.karaf.cellar.nodes.cfg`:
----
bundle.listener = false
----
-The bundle listener listens the following local bundle changes:
+The bundle listener listens for the following local bundle changes:
* install bundle
* start bundle
@@ -257,18 +257,19 @@ You can delete the whole config using the `cluster:config-delete` command:
karaf@node1()> cluster:config-delete default my.config
----
-Like for feature and bundle, Cellar provides a config listener disabled by default in `etc/org.apache.karaf.cellar.nodes.cfg`:
+As for features and bundles, Cellar provides a config listener that is disabled by default in `etc/org.apache.karaf.cellar.nodes.cfg`:
----
config.listener = false
----
-The config listener listens the following local config changes:
+The config listener listens for the following local config changes:
+
* create a config
* add/delete/change a property
* delete a config
-As some properties may be local to a node, Cellar excludes some property by default.
+As some properties may be local to a node, Cellar excludes some properties by default.
You can see the current excluded properties using the `cluster:config-property-excluded` command:
----
@@ -323,7 +324,7 @@ It allows you to block or allow some resources on the cluster.
By adding a resource id in a blacklist, you block the resource.
By adding a resource id in a whitelist, you allow the resource.
-For instance, for feature, you can use the `cluster:feature-block` command to display or modify the current blocking policy for features:
+For example, for features, you can use the `cluster:feature-block` command to display or modify the current blocking policy for features:
----
karaf@node1()> cluster:feature-block default
@@ -340,7 +341,7 @@ OUTBOUND:
* is a wildcard.
====
-You have the equivalent command for bundle and config:
+You have the equivalent command for bundles and config:
----
karaf@node1()> cluster:bundle-block default
@@ -359,4 +360,4 @@ OUTBOUND:
blacklist: [org.apache.karaf.cellar*, org.apache.karaf.shell, org.ops4j.pax.logging, org.ops4j.pax.web, org.apache.felix.fileinstall*, org.apache.karaf.management, org.apache.aries.transaction]
----
-Using those commands, you can also update the blacklist and whitelist for inbound or outbound cluster events.
\ No newline at end of file
+Using those commands, you can also update the blacklist and whitelist for inbound or outbound cluster events.
diff --git a/manual/src/main/asciidoc/user-guide/hazelcast.adoc b/manual/src/main/asciidoc/user-guide/hazelcast.adoc
index d77995e..d6b3f65 100644
--- a/manual/src/main/asciidoc/user-guide/hazelcast.adoc
+++ b/manual/src/main/asciidoc/user-guide/hazelcast.adoc
@@ -14,7 +14,7 @@
=== Core runtime and Hazelcast
-Cellar uses Hazelcast as cluster engine.
+Cellar uses Hazelcast as the cluster engine.
When you install the cellar feature, a hazelcast feature is automatically installed, providing the `etc/hazelcast.xml`
configuration file.
@@ -90,8 +90,8 @@ By default, it will bind to all interfaces on the node machine. It's possible to
[NOTE]
====
-In previous Hazelcast versions (especially the one used by Cellar 2.3.x), it was possible to have multicast and tcp-ip enabled in the same time.
-In Hazelcast 3.3.x (the version currently used by Cellar 3.0.x), only one discover mechanism can be enabled at a time. Cellar uses multicast by default (tcp-ip is disabled).
+In previous Hazelcast versions (especially the one used by Cellar 2.3.x), it was possible to have multicast and tcp-ip enabled at the same time.
+In Hazelcast 3.3.x (the version currently used by Cellar 3.0.x), only one discovery mechanism can be enabled at a time. Cellar uses multicast by default (tcp-ip is disabled).
If your network or network interface don't support multicast, you have to enable tcp-ip and disable multicast.
====
@@ -114,7 +114,7 @@ You can also discover nodes located on a Amazon instance:
</aws>
----
-Third, you can specific on which network interface the cluster is running (whatever the discovery mechanism used). By default, Hazelcast listens on all interfaces (0.0.0.0).
+Thirdly, you can specific on which network interface the cluster is running (whatever the discovery mechanism used). By default, Hazelcast listens on all interfaces (0.0.0.0).
But you can specify an interface:
----
diff --git a/manual/src/main/asciidoc/user-guide/introduction.adoc b/manual/src/main/asciidoc/user-guide/introduction.adoc
index 17c9bf8..2935e49 100644
--- a/manual/src/main/asciidoc/user-guide/introduction.adoc
+++ b/manual/src/main/asciidoc/user-guide/introduction.adoc
@@ -24,7 +24,7 @@ It's also possible to enable local resources listeners: these listeners broadcas
Please note that this behavior is disabled by default as it can have side effects (especially when a node is stopped).
Enabling listeners is at your own risk.
-The nodes list could be discovered (using unicast or multicast), or "static" defined (using a couple hostname or IP
+The nodes list could be discovered (using unicast or multicast), or else defined in a static way (using a hostname/IP
and port list).
Cellar is able to synchronize:
@@ -33,30 +33,31 @@ Cellar is able to synchronize:
* config
* features
-Optionally, Cellar also support synchronization of OSGi EventAdmin, OBR (URLs and bundles).
+Optionally, Cellar also supports synchronization of OSGi EventAdmin, OBR (URLs and bundles).
The second goal is to provide a Distributed OSGi runtime. It means that using Cellar, you are able to call an OSGi
service located on a remote instance. See the link:transport[transport and DOSGi section] of the user guide.
-Finally, Cellar also provides "runtime clustering" by providing dedicated feature like:
+Finally, Cellar also provides "runtime clustering" by providing dedicated features like:
* HTTP load balancing
* HTTP sessions replication
* log centralization
+
Please, see the sections dedicated to those features.
==== Cross topology
This is the default Cellar topology. Cellar is installed on all nodes, each node has the same function.
-It means that you can perform actions on any node, it will be broadcasted to all others nodes.
+It means that you can perform actions on any node, it will be broadcast to all other nodes.
==== Star topology
In this topology, if Cellar is installed on all nodes, you perform actions only on one specific node (the "manager").
-To do that, the "manager" is a standard Cellar node, and the event producing is disable on all others nodes
+To do that, the "manager" is a standard Cellar node, and the event producing is disabled on all other nodes
(`cluster:producer-stop` on all "managed" nodes).
-Like this, only the "manager" will send event to the nodes (which are able to consumer and handle), but no event can
-be produced on the nodes.
\ No newline at end of file
+Like this, only the "manager" will send event to the nodes (which are able to consume and handle), but no event can
+be produced on the nodes.
diff --git a/manual/src/main/asciidoc/user-guide/log.adoc b/manual/src/main/asciidoc/user-guide/log.adoc
index dc184aa..4ba9cab 100644
--- a/manual/src/main/asciidoc/user-guide/log.adoc
+++ b/manual/src/main/asciidoc/user-guide/log.adoc
@@ -18,7 +18,7 @@ Apache Karaf Cellar is able to centralize and manage log service on each node.
==== Enable Cellar log
-Centralized log support is an optionnal feature that you can install using:
+Centralized log support is an optional feature that you can install using:
----
karaf@root()> feature:install cellar-log
diff --git a/manual/src/main/asciidoc/user-guide/nodes.adoc b/manual/src/main/asciidoc/user-guide/nodes.adoc
index bda3b75..c332d53 100644
--- a/manual/src/main/asciidoc/user-guide/nodes.adoc
+++ b/manual/src/main/asciidoc/user-guide/nodes.adoc
@@ -43,7 +43,7 @@ See link:hazelcast[Core Configuration section] for details.
[NOTE]
====
-In Cellar 2.3.x, Cellar used both multicast and tcp-ip by default. Due to a change in Hazelcast, it's no more possible to have both.
+In Cellar 2.3.x, Cellar used both multicast and tcp-ip by default. Due to a change in Hazelcast, it's not possible any more to have both.
Now, in Cellar 3.0.x, the default configuration is multicast enabled, tcp-ip disabled.
See link:hazelcast[Core Configuration section] for details.
====
@@ -74,7 +74,7 @@ It's where you can control the status of the different components.
==== Synchronizers and sync policy
-A synchronizer is invoked when you:
+A synchronizer is invoked when:
* Cellar starts
* a node joins a cluster group (see link:groups for details about cluster groups)
@@ -153,7 +153,7 @@ When the producer is off, it means that the node is "isolated" from the cluster
to the other nodes.
On the other hand, a node receives the cluster events on a consumer. Like for the producer, you can see and control the
-consumer using dedicated command:
+consumer using a dedicated command:
----
karaf@node1()> cluster:consumer-status
@@ -173,7 +173,7 @@ x | localhost:5701 | ON
When the consumer is off, it means that node is "isolated" from the cluster as it doesn't receive "inbound" cluster events
from the other nodes.
-Different cluster events are involved. For instance, we have cluster event for feature, for bundle, for configuration, for OBR, etc.
+Different cluster events are involved. For instance, we have cluster events for feature, for bundle, for configuration, for OBR, etc.
When a consumer receives a cluster event, it delegates the handling of the cluster event to a specific handler, depending of the
type of the cluster event.
You can see the different handlers and their status using the cluster:handler-status command:
@@ -194,12 +194,12 @@ dealt by the handler.
==== Listeners
-The listeners are listening for local resource change.
+The listeners are listening for local resource changes.
-For instance, when you install a feature (with `feature:install`), the feature listener traps the change and broadcast this
+For instance, when you install a feature (with `feature:install`), the feature listener traps the change and broadcasts this
change as a cluster event to other nodes.
-To avoid some unexpected behaviors (especially when you stop a node), most of the listeners are switch off by default.
+To avoid some unexpected behaviors (especially when you stop a node), most of the listeners are switched off by default.
The listeners status are configured in the `etc/org.apache.karaf.cellar.node.cfg` configuration file.