Skip to content
Permalink
Browse files
guide/concepts: fix typos and add clarifications
  • Loading branch information
kemitix committed Aug 15, 2018
1 parent e45af5e commit 31a1e42d9c670d01792e101448a93f3ed2e842d1
Show file tree
Hide file tree
Showing 4 changed files with 7 additions and 7 deletions.
@@ -15,8 +15,8 @@ by calling `.configure(KEY, VALUE)` in the entity spec when creating it.
There is also an `entity.config().set(KEY, VALUE)` method.

Additionally, many common configuration parameters are available as "flags" which can be supplied as Strings when constructing
then entity, in the form
`EntitySpec.create˙(MyEntity.class).configure("config1", "value1").configure("config2", "value2")`.
the entity, in the form
`EntitySpec.create(MyEntity.class).configure("config1", "value1").configure("config2", "value2")`.

Documentation of the flags available for individual entities can normally be found in the javadocs.
The `@SetFromFlag` annotations on `ConfigKey` static field definitions
@@ -32,6 +32,6 @@ Sensors can be updated by the entity or associated tasks, and sensors from an en
Effectors can be invoked by an entity's parent remotely, and the invoker is able to track the execution of that effector. Effectors can be invoked by other entities, but use this functionality with care to prevent too many managers!

An entity consists of a Java interface (used when interacting with the entity) and a Java class. For resilience. it is recommended to store
the entity's state in attributes (see `getAttribute(AttributeKey)`). If internal fields can be used then the data will be lost on brooklyn
the entity's state in attributes (see `getAttribute(AttributeKey)`). If internal fields are used then the data will be lost on brooklyn
restart, and may cause problems if the entity is to be moved to a different brooklyn management node.

@@ -10,7 +10,7 @@ setConfiguration(UsesJava.JAVA_OPTIONS, ImmutableMap.of("mysql.url",
```

The ``attributeWhenReady(Entity, Sensor)`` call (a static method on the class ``DependentConfiguration``)
causes the configuration value to be set when that given entity's attribue is ready.
causes the configuration value to be set when that given entity's attribute is ready.
In the example, ``attributeWhenReady()`` causes the JVM system property ``mysql.url`` to be set to the value of the ``MySqlNode.MY_SQL_URL`` sensor from ``mysql`` when that value is ready. As soon as the database URL is announced by the MySql entity, the configuration value will be available to the Tomcat cluster.

By default "ready" means being *set* (non-null) and, if appropriate, *non-empty* (for collections and strings) or *non-zero* (for numbers). Formally the interpretation of ready is that of "Groovy truth" defined by an ``asBoolean()`` method on the class and in the Groovy language extensions.
@@ -12,7 +12,7 @@ hierarchical causal chain even when operations are run in parallel
Some executions create new entities, which can then have tasks associated with them, and the system will record, for example, that a start effector on the new entity is a task associated with that entity, with that task
created by a task associated with a different entity.

The execution of a typical overall start-up sequence is shown below:
The execution of a typical overall start-up sequence is shown below (click image to magnify):

[![Brooklyn Flow Diagram](brooklyn-flow-websequencediagrams.com-w400.png "Brooklyn Flow Diagram" )](brooklyn-flow-websequencediagrams.com.png)

@@ -3,7 +3,7 @@ title: Lifecycle and ManagementContext
---

Under-the-covers, at heart of the brooklyn management plane is the ``ManagementContext``.
This is started automatically when using launching an application using the brooklyn CLI. For programmatic use, see
This is started automatically when launching an application using the brooklyn CLI. For programmatic use, see
``BrooklynLauncher.newLauncher().launch()``.

A Brooklyn deployment consists of many entities in a hierarchical tree, with the privileged *application* entity at the top level.
@@ -25,7 +25,7 @@ Typically a Brooklyn deployment has a single management context which records:
* all entities under management that are reachable by the application(s) via the parent-child relationships,
* the state associated with each entity,
* subscribers (listeners) to sensor events arising from the entities,
* active tasks (jobs) associated with any the entity,
* active tasks (jobs) associated with the entity,
* which Brooklyn management node is mastering (managing) each entity.

<!-- TODO Distributed brooklyn not yet supported; needs clarification in docs -->

0 comments on commit 31a1e42

Please sign in to comment.