You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@brooklyn.apache.org by m4...@apache.org on 2017/10/25 21:04:50 UTC
[05/50] [abbrv] brooklyn-docs git commit: Adapt doc to make compile
with gitbook
Adapt doc to make compile with gitbook
Project: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/repo
Commit: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/commit/18c248c5
Tree: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/tree/18c248c5
Diff: http://git-wip-us.apache.org/repos/asf/brooklyn-docs/diff/18c248c5
Branch: refs/heads/master
Commit: 18c248c53190ca06f91822caeacad2d62a97833b
Parents: 4af9a8b
Author: Thomas Bouron <th...@cloudsoftcorp.com>
Authored: Fri Oct 6 10:19:02 2017 +0100
Committer: Thomas Bouron <th...@cloudsoftcorp.com>
Committed: Mon Oct 16 14:55:34 2017 +0100
----------------------------------------------------------------------
.gitignore | 2 +
SUMMARY.md | 4 -
book.json | 42 ++++-
guide/README.md | 0
guide/SUMMARY.md | 86 +++++++++
guide/blueprints/ansible/index.md | 2 +-
guide/blueprints/blueprinting-tips.md | 8 +-
guide/blueprints/catalog/index.md | 2 +-
guide/blueprints/catalog/schema.md | 2 +-
.../chef/advanced-chef-integration.md | 4 +-
guide/blueprints/chef/creating-blueprints.md | 4 +-
guide/blueprints/chef/index.md | 2 +-
guide/blueprints/clusters-and-policies.md | 13 +-
guide/blueprints/clusters.md | 4 +-
guide/blueprints/configuring-vms.md | 8 +-
guide/blueprints/creating-yaml.md | 22 ++-
guide/blueprints/custom-entities.md | 49 ++---
guide/blueprints/effectors.md | 22 +--
guide/blueprints/enrichers.md | 28 +--
guide/blueprints/entity-configuration.md | 62 +++----
guide/blueprints/index.md | 2 +-
guide/blueprints/java/archetype.md | 28 +--
guide/blueprints/java/bundle-dependencies.md | 10 +-
guide/blueprints/java/common-usage.md | 24 +--
guide/blueprints/java/defining-and-deploying.md | 39 ++--
guide/blueprints/java/entities.md | 4 +-
guide/blueprints/java/entitlements.md | 18 +-
guide/blueprints/java/entity.md | 10 +-
guide/blueprints/java/feeds.md | 24 +--
guide/blueprints/java/index.md | 2 +-
guide/blueprints/java/topology-dependencies.md | 6 +-
guide/blueprints/multiple-services.md | 12 +-
guide/blueprints/policies.md | 16 +-
guide/blueprints/salt/index.md | 2 +-
guide/blueprints/setting-locations.md | 35 ++--
guide/blueprints/test/index.md | 2 +-
guide/blueprints/test/test-entities.md | 34 ++--
guide/blueprints/test/usage-examples.md | 20 +--
guide/blueprints/winrm/index.md | 10 +-
guide/blueprints/yaml-reference.md | 4 +-
guide/concepts/dependent-configuration.md | 4 +-
guide/concepts/index.md | 2 +-
guide/dev/env/ide/index.md | 12 +-
guide/dev/env/maven-build.md | 12 +-
guide/dev/index.md | 4 +-
guide/dev/tips/debugging-remote-brooklyn.md | 16 +-
guide/dev/tips/index.md | 4 +-
guide/dev/tips/logging.md | 8 +-
guide/index.md | 21 ---
guide/list-children.html | 0
guide/locations/_AWS.md | 2 +-
guide/locations/_GCE.md | 2 +-
guide/locations/_azure-ARM.md | 4 +-
guide/locations/_azure-classic.md | 20 +--
guide/locations/_byon.md | 14 +-
guide/locations/_clouds.md | 22 +--
guide/locations/_cloudstack.md | 2 +-
guide/locations/_ibm-softlayer.md | 2 +-
.../_inheritance-and-named-locations.md | 12 +-
guide/locations/_localhost.md | 14 +-
guide/locations/_openstack.md | 2 +-
guide/locations/_special-locations.md | 18 +-
guide/locations/_ssh-keys.md | 10 +-
guide/locations/index.md | 180 ++++++++++++++++++-
.../provisioned-machine-requirements.md | 161 -----------------
guide/misc/download.md | 110 +++++-------
guide/misc/index.md | 2 +-
guide/misc/release-notes.md | 4 +-
guide/ops/cli/cli-ref-guide.md | 12 +-
guide/ops/cli/cli-usage-guide.md | 124 ++++++-------
guide/ops/cli/index.md | 12 +-
guide/ops/configuration/brooklyn_cfg.md | 42 ++---
guide/ops/configuration/cors.md | 4 +-
guide/ops/configuration/https.md | 12 +-
guide/ops/externalized-configuration.md | 72 ++++----
guide/ops/gui/blueprints.md | 10 +-
guide/ops/gui/index.md | 2 +-
guide/ops/gui/policies.md | 4 +-
guide/ops/gui/running.md | 10 +-
.../high-availability-supplemental.md | 32 ++--
guide/ops/index.md | 2 +-
guide/ops/logging.md | 8 +-
guide/ops/persistence/index.md | 8 +-
guide/ops/production-installation.md | 42 +++--
guide/ops/requirements.md | 8 +-
guide/ops/server-cli-reference.md | 12 +-
guide/ops/starting-stopping-monitoring.md | 10 +-
guide/ops/troubleshooting/connectivity.md | 2 +-
guide/ops/troubleshooting/deployment.md | 24 +--
.../troubleshooting/detailed-support-report.md | 6 +-
.../going-deep-in-java-and-logs.md | 82 ++++-----
guide/ops/troubleshooting/increase-entropy.md | 20 +--
guide/ops/troubleshooting/index.md | 2 +-
guide/ops/troubleshooting/overview.md | 2 +-
guide/ops/troubleshooting/slow-unresponsive.md | 72 ++++----
guide/ops/upgrade.md | 28 +--
guide/start/blueprints.md | 38 ++--
guide/start/concept-quickstart.md | 2 +-
guide/start/index.md | 2 +-
guide/start/managing.md | 100 +++++------
guide/start/policies.md | 58 +++---
guide/start/running.md | 118 ++++++------
102 files changed, 1155 insertions(+), 1159 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/.gitignore
----------------------------------------------------------------------
diff --git a/.gitignore b/.gitignore
index 97a4608..49aa963 100644
--- a/.gitignore
+++ b/.gitignore
@@ -35,3 +35,5 @@ _pdf
_config_local.yml
.sass-cache
style/js/catalog/items.js
+
+_book
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/SUMMARY.md
----------------------------------------------------------------------
diff --git a/SUMMARY.md b/SUMMARY.md
deleted file mode 100644
index 263112f..0000000
--- a/SUMMARY.md
+++ /dev/null
@@ -1,4 +0,0 @@
-# Summary
-
-* [Introduction](README.md)
-
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/book.json
----------------------------------------------------------------------
diff --git a/book.json b/book.json
index 316db54..36dda82 100644
--- a/book.json
+++ b/book.json
@@ -1,3 +1,43 @@
{
- "root": "./guide"
+ "root": "./guide",
+ "variables": {
+ "encoding": "utf-8",
+ "markdown": "kramdown",
+
+ "url_root": "http://0.0.0.0:4000",
+
+ "path": {
+ "style": "/style",
+ "guide": "/guide",
+ "website": "/website",
+ "v": "/v"
+ },
+
+ "dependency_mode": "local",
+ "dependency_urls": {
+ "bootstrap.css": "https://netdna.bootstrapcdn.com/bootstrap/3.1.1/css/bootstrap.min.css",
+ "bootstrap.js": "https://netdna.bootstrapcdn.com/bootstrap/3.1.1/js/bootstrap.min.js",
+ "jquery.js": "https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"
+ },
+
+ "root_menu_page": "/website/index.md",
+
+ "exclude": ["/Gemfile*", "/README.md"],
+
+ "sass": {
+ "sass_dir": "style/css"
+ },
+
+ "brooklyn-stable-version": "0.11.0",
+ "pdf-default-base-url": "http://brooklyn.apache.org",
+ "pdf-default-versioned-url-subpath": "/v/0.11.0",
+
+ "pdf-rewrite-prefixes": {
+ "/guide": "/v/0.11.0",
+ "/website": ""
+ },
+
+ "brooklyn-version": "0.13.0-SNAPSHOT",
+ "brooklyn-snapshot-git-branch": "master"
+ }
}
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/README.md
----------------------------------------------------------------------
diff --git a/guide/README.md b/guide/README.md
new file mode 100644
index 0000000..e69de29
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/SUMMARY.md
----------------------------------------------------------------------
diff --git a/guide/SUMMARY.md b/guide/SUMMARY.md
new file mode 100644
index 0000000..9974807
--- /dev/null
+++ b/guide/SUMMARY.md
@@ -0,0 +1,86 @@
+# Apache Brooklyn documentation
+
+### User Guide
+
+* Getting Started
+ * [Running Apache Brooklyn](start/running.md)
+ * [Deploying Blueprints](start/blueprints.md)
+ * [Monitoring and Managing Applications](start/managing.md)
+ * [Policies](start/policies.md)
+ * [Concepts](start/concept-quickstart.md)
+* [Downloads](misc/download.md)
+* Brooklyn Concepts
+ * [Entities](concepts/entities.md)
+ * [Application, Parent and Membership](concepts/application-parent-membership.md)
+ * [Configuration, Sensors and Effectors](concepts/configuration-sensor-effectors.md)
+ * [Lifecycle and ManagementContext](concepts/lifecycle-managementcontext.md)
+ * [Dependent Configuration](concepts/dependent-configuration.md)
+ * [Location](concepts/location.md)
+ * [Policies](concepts/policies.md)
+ * [Execution](concepts/execution.md)
+ * [Stop/start/restart behaviour](concepts/stop-start-restart-behaviour.md)
+* [Writing Blueprints](blueprints/index.md)
+ * [Creating YAML Blueprint](blueprints/creating-yaml.md)
+ * [Entity Configuration](blueprints/entity-configuration.md)
+ * [Setting Locations](blueprints/setting-locations.md)
+ * [Configuring VMs](blueprints/configuring-vms.md)
+ * [Multiple Services and Dependency Injection](blueprints/multiple-services.md)
+ * [Custom Entities](blueprints/custom-entities.md)
+ * [Catalog](blueprints/catalog/index.md)
+ * [Clusters, Specs, and Composition](blueprints/clusters.md)
+ * [Enrichers](blueprints/enrichers.md)
+ * [Policies](blueprints/policies.md)
+ * [Effectors](blueprints/effectors.md)
+ * [Clusters and Policies](blueprints/clusters-and-policies.md)
+ * [Java Entities](blueprints/java/index.md)
+ * [Windows Blueprints](blueprints/winrm/index.md)
+ * [Testing YAML Blueprints](blueprints/test/index.md)
+ * [Ansible in YAML Blueprints](blueprints/ansible/index.md)
+ * [Chef in YAML Blueprints](blueprints/chef/index.md)
+ * [Salt in YAML Blueprints](blueprints/salt/index.md)
+ * [YAML Blueprint Advanced Example](blueprints/advanced-example.md)
+ * [Blueprinting Tips](blueprints/blueprinting-tips.md)
+ * [YAML Blueprint Reference](blueprint/yaml-reference.md)
+* [Deploying Blueprint](locations/index.md)
+ * [Provisioned Machine Requirements](locations/provisioned-machine-requirements.md)
+* Reference Guide
+ * [Production Installation](ops/production-installation.md)
+ * [Starting, Stopping and Monitoring](ops/starting-stopping-monitoring.md)
+ * [Server CLI Reference](ops/server-cli-reference.md)
+ * [Client CLI Reference](ops/cli/index.md)
+ * GUI Guide
+ * [Launching](ops/gui/running.md)
+ * [Deploying Blueprints](ops/gui/blueprints.md)
+ * [Monitoring and Managing Applications](ops/gui/managing.md)
+ * [Using Policies](ops/gui/policies.md)
+ * [REST API](ops/rest.md)
+ * [Brooklyn Configuration and Options](ops/configuration/index.md)
+ * [Persistence](ops/persistence/index.md)
+ * [High Availability](ops/high-availability/index.md)
+ * [Configuring HA - an example](ops/high-availability/high-availability-supplemental.md)
+ * [Logging](ops/logging.md)
+ * [Externalized Configuration](ops/externalized-configuration.md)
+ * [Requirements](ops/requirements.md)
+ * [Upgrade](ops/upgrade.md)
+ * [Security Guidelines](ops/security-guidelines.md)
+ * [Troubleshooting](ops/troubleshooting/index.md)
+* [Other 0.12.0 Resources](misc/index.md)
+
+### Developer Guide
+
+* [Get the Code](https://brooklyn.apache.org/developers/code/)
+* [Maven Build](dev/env/maven-build.md)
+* [IDE Setup](dev/env/ide/index.md)
+* [Code Structure](dev/code/structure.md)
+* [Tests](dev/code/tests.md)
+* [License Considerations](dev/code/licensing.md)
+* [Miscellaneous Tips and Tricks](dev/tips/index.md)
+* [Logging](dev/tips/logging.md)
+* [Brooklyn Remote Debugging](dev/tips/debugging-remote-brooklyn.md)
+* [GitHub](http://github.com/apache/brooklyn)
+* [Javadoc](https://brooklyn.apache.org/v/latest/misc/javadoc)
+
+----
+
+* [Versions](https://brooklyn.apache.org/meta/versions.html)
+* [Other Resources](https://brooklyn.apache.org/documentation/other-docs.html)
\ No newline at end of file
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/ansible/index.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/ansible/index.md b/guide/blueprints/ansible/index.md
index a2376d1..78ce33b 100644
--- a/guide/blueprints/ansible/index.md
+++ b/guide/blueprints/ansible/index.md
@@ -13,4 +13,4 @@ Comments on this support and suggestions for further development are welcome.
This guide assumes you are familiar with the basics of [creating YAML blueprints](../).
-{% include list-children.html %}
+
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/blueprinting-tips.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/blueprinting-tips.md b/guide/blueprints/blueprinting-tips.md
index 9712fef..40e33d7 100644
--- a/guide/blueprints/blueprinting-tips.md
+++ b/guide/blueprints/blueprinting-tips.md
@@ -37,11 +37,11 @@ Options for speeding up provisioning include those below.
#### Deploying to Bring Your Own Nodes (BYON)
-A [BYON location]({{ site.path.guide }}/locations/#byon) can be defined, which avoids the time
+A [BYON location]({{ book.path.guide }}/locations/#byon) can be defined, which avoids the time
required to provision VMs. This is fast, but has the downside that artifacts installed during a
previous run can interfere with subsequent runs.
-A variant of this is to [use Vagrant]({{ site.path.guide }}/start/running.html) (e.g. with VirtualBox)
+A variant of this is to [use Vagrant]({{ book.path.guide }}/start/running.html) (e.g. with VirtualBox)
to create VMs on your local machine, and to use these as the target for a BYON location.
These VMs should mirror the target environment as much as possible.
@@ -113,7 +113,7 @@ real thing.
## Writing Entity Tests
-Use the [test framework]({{ site.path.guide }}/blueprints/test/) to write test cases. This will make
+Use the [test framework]({{ book.path.guide }}/blueprints/test/) to write test cases. This will make
automated (regression) testing easier, and will allow others to easily confirm that the entity
works in their environment.
@@ -180,4 +180,4 @@ below may also be of help:
ALWAYS keep logs when there is an error.
-See the [Troubleshooting]({{ site.path.guide }}/ops/troubleshooting/) guide for more information.
+See the [Troubleshooting]({{ book.path.guide }}/ops/troubleshooting/) guide for more information.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/catalog/index.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/catalog/index.md b/guide/blueprints/catalog/index.md
index ed56483..d56be8f 100644
--- a/guide/blueprints/catalog/index.md
+++ b/guide/blueprints/catalog/index.md
@@ -18,4 +18,4 @@ folder by default and additional ones can be added through the web console or CL
the catalog can be deployed directly, via the Brooklyn CLI or the web console, or referenced in
other blueprints using their `id`.
-{% include list-children.html %}
+
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/catalog/schema.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/catalog/schema.md b/guide/blueprints/catalog/schema.md
index 3edccf9..3291c03 100644
--- a/guide/blueprints/catalog/schema.md
+++ b/guide/blueprints/catalog/schema.md
@@ -223,7 +223,7 @@ The items this will add to the catalog are:
#### Locations in the Catalog
-In addition to blueprints, locations can be added to the Apache Brooklyn catalog. The example below shows a location for the vagrant configuration used in the [getting started guide]({{ site.path.guide }}/start/blueprints.html), formatted as a catalog entry.
+In addition to blueprints, locations can be added to the Apache Brooklyn catalog. The example below shows a location for the vagrant configuration used in the [getting started guide]({{ book.path.guide }}/start/blueprints.html), formatted as a catalog entry.
~~~ yaml
brooklyn.catalog:
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/chef/advanced-chef-integration.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/chef/advanced-chef-integration.md b/guide/blueprints/chef/advanced-chef-integration.md
index 1081cd3..0652d9b 100644
--- a/guide/blueprints/chef/advanced-chef-integration.md
+++ b/guide/blueprints/chef/advanced-chef-integration.md
@@ -30,7 +30,7 @@ indicated earlier. If you'd like to work with us to implement these, please let
A general schema for the supported YAML is below:
-{% highlight yaml %}
+```yaml
- type: chef:cookbook_name
brooklyn.config:
cookbook_urls:
@@ -40,7 +40,7 @@ A general schema for the supported YAML is below:
launch_attributes: # map of arguments to set in the chef node
service_name: cookbook_service
pid_file: /var/run/cookbook.pid
-{% endhighlight %}
+```
If you are interested in exploring the Java code for creating blueprints,
start with the `TypedToyMySqlEntiyChef` class, which essentially does what this tutorial has shown;
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/chef/creating-blueprints.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/chef/creating-blueprints.md b/guide/blueprints/chef/creating-blueprints.md
index 8d30131..7d838a7 100644
--- a/guide/blueprints/chef/creating-blueprints.md
+++ b/guide/blueprints/chef/creating-blueprints.md
@@ -8,9 +8,7 @@ In a nutshell, a new Chef-based entity can be defined as a service by specifying
`chef:cookbook_name` as the `service_type`, along with a collection of optional configuration.
An illustrative example is below:
-{% highlight yaml %}
-{% readj example_yaml/mysql-chef-1.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/mysql-chef-1.yaml"
*This works without any installation: try it now, copying-and-pasting to the Brooklyn console.
(Don't forget to add your preferred `location: some-cloud` to the spec.)*
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/chef/index.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/chef/index.md b/guide/blueprints/chef/index.md
index f0fa3d0..d183a5f 100644
--- a/guide/blueprints/chef/index.md
+++ b/guide/blueprints/chef/index.md
@@ -15,4 +15,4 @@ A plan for the full integration is online [here](https://docs.google.com/a/cloud
This guide assumes you are familiar with the basics of [creating YAML blueprints](../).
-{% include list-children.html %}
+
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/clusters-and-policies.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/clusters-and-policies.md b/guide/blueprints/clusters-and-policies.md
index 0e9630f..0f3a740 100644
--- a/guide/blueprints/clusters-and-policies.md
+++ b/guide/blueprints/clusters-and-policies.md
@@ -12,9 +12,8 @@ But another blueprint, the `ControlledDynamicWebAppCluster`, does this for us.
It takes the same `dynamiccluster.memberspec`, so we can build a fully functional elastic 3-tier
deployment of our `hello-world-sql` application as follows:
-{% highlight yaml %}
-{% readj example_yaml/appserver-clustered-w-db.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/appserver-clustered-w-db.yaml"
+
This sets up Nginx as the controller by default, but that can be configured
using the `controllerSpec` key.
@@ -25,9 +24,7 @@ JBoss is actually the default appserver in the `ControlledDynamicWebAppCluster`,
so because `brooklyn.config` keys in Brooklyn are inherited by default,
the same blueprint can be expressed more concisely as:
-{% highlight yaml %}
-{% readj example_yaml/appserver-clustered-w-db-concise.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/appserver-clustered-w-db-concise.yaml"
The other nicety supplied by the `ControlledDynamicWebAppCluster` blueprint is that
it aggregates sensors from the appserver, so we have access to things like
@@ -37,9 +34,7 @@ We can set up our blueprint to do autoscaling based on requests per second
(keeping it in the range 10..100, with a maximum of 5 appserver nodes)
as follows:
-{% highlight yaml %}
-{% readj example_yaml/appserver-w-policy.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/appserver-w-policy.yaml"
Use your favorite load-generation tool (`jmeter` is one good example) to send a huge
volume of requests against the server and see the policies kick in to resize it.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/clusters.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/clusters.md b/guide/blueprints/clusters.md
index 4c1312c..11eb958 100644
--- a/guide/blueprints/clusters.md
+++ b/guide/blueprints/clusters.md
@@ -10,9 +10,7 @@ What if you want multiple machines?
One way is just to repeat the `- type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess` block,
but there's another way which will keep your powder [DRY](http://en.wikipedia.org/wiki/Don't_repeat_yourself):
-{% highlight yaml %}
-{% readj example_yaml/cluster-vm.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/cluster-vm.yaml"
Here we've composed the previous blueprint introducing some new important concepts, the `DynamicCluster`
the `$brooklyn` DSL, and the "entity-spec". Let's unpack these.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/configuring-vms.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/configuring-vms.md b/guide/blueprints/configuring-vms.md
index e7e7f47..07ab39a 100644
--- a/guide/blueprints/configuring-vms.md
+++ b/guide/blueprints/configuring-vms.md
@@ -7,9 +7,7 @@ categories: [use, guide, defining-applications]
Another simple blueprint will just create a VM which you can use, without any software installed upon it:
-{% highlight yaml %}
-{% readj example_yaml/simple-vm.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/simple-vm.yaml"
*We've omitted the `location` section here and in many of the examples below;
@@ -18,7 +16,7 @@ ignored if deploying to `localhost` or `byon` fixed-IP machines.*
This will create a VM with the specified parameters in your choice of cloud.
In the GUI (and in the REST API), the entity is called "VM",
-and the hostname and IP address(es) are reported as [sensors]({{ site.path.guide }}/concepts/entities.html).
+and the hostname and IP address(es) are reported as [sensors]({{ book.path.guide }}/concepts/entities.html).
There are many more `provisioning.properties` supported here,
including:
@@ -28,4 +26,4 @@ including:
* `machineCreateAttempts` (for dodgy clouds, and they nearly all fail occasionally!)
* and things like `imageId` and `userMetadata` and disk and networking options (e.g. `autoAssignFloatingIp` for private clouds)
-For more information, see [Operations: Locations]({{ site.path.guide }}/locations/index.html).
+For more information, see [Operations: Locations]({{ book.path.guide }}/locations/index.html).
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/creating-yaml.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/creating-yaml.md b/guide/blueprints/creating-yaml.md
index 6f91784..3798c0b 100644
--- a/guide/blueprints/creating-yaml.md
+++ b/guide/blueprints/creating-yaml.md
@@ -18,26 +18,24 @@ it's easy to add new extensions using your favorite JVM language.)
Here's a very simple YAML blueprint plan, to explain the structure:
-{% highlight yaml %}
-{% readj example_yaml/simple-appserver.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/simple-appserver.yaml"
* The `name` is just for the benefit of us humans.
* The `location` specifies where this should be deployed.
- If you've [set up passwordless localhost SSH access]({{ site.path.guide }}/locations/#localhost)
+ If you've [set up passwordless localhost SSH access]({{ book.path.guide }}/locations/#localhost)
you can use `localhost` as above, but if not, just wait ten seconds for the next example.
* The `services` block takes a list of the typed services we want to deploy.
This is the meat of the blueprint plan, as you'll see below.
Finally, the clipboard in the top-right corner of the example plan box above (hover your cursor over the box) lets you easily copy-and-paste into the web-console:
-simply [download and launch]({{ site.path.guide }}/start/running.html) Brooklyn,
+simply [download and launch]({{ book.path.guide }}/start/running.html) Brooklyn,
then in the "Create Application" dialog at the web console
(usually [http://127.0.0.1:8081/](http://127.0.0.1:8081/), paste the copied YAML into the "Yaml" tab of the dialog and press "Finish".
There are several other ways to deploy, including `curl` and via the command-line,
and you can configure users, https, persistence, and more,
-as described [in the ops guide]({{ site.path.guide }}/ops/).
+as described [in the ops guide]({{ book.path.guide }}/ops/).
[](web-console-yaml.png)
@@ -54,25 +52,25 @@ TODO building up children entities
Topics to explore next on the topic of YAML blueprints are:
-{% include list-children.html %}
+
Plenty of examples of blueprints exist in the Brooklyn codebase,
-so another starting point is to [`git clone`]({{ site.path.website }}/developers/code/index.html) it
+so another starting point is to [`git clone`]({{ book.path.website }}/developers/code/index.html) it
and search for `*.yaml` files therein.
Brooklyn lived as a Java framework for many years before we felt confident
to make a declarative front-end, so you can do pretty much anything you want to
by dropping to the JVM. For more information on Java:
-* start with a [Maven archetype]({{site.path.guide}}/blueprints/java/archetype.html)
-* see all [Brooklyn Java guide]({{site.path.guide}}/blueprints/java/) topics
+* start with a [Maven archetype]({{book.path.guide}}/blueprints/java/archetype.html)
+* see all [Brooklyn Java guide]({{book.path.guide}}/blueprints/java/) topics
* look at test cases in the [codebase](https://github.com/apache/brooklyn)
<!--
TODO
-* review some [examples]({{site.path.guide}}/use/examples/index.html)
+* review some [examples]({{book.path.guide}}/use/examples/index.html)
-->
You can also come talk to us, on IRC (#brooklyncentral on Freenode) or
-any of the usual [hailing frequencies]({{site.path.website}}/community/),
+any of the usual [hailing frequencies]({{book.path.website}}/community/),
as these documents are a work in progress.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/custom-entities.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/custom-entities.md b/guide/blueprints/custom-entities.md
index efd03ba..5f77faf 100644
--- a/guide/blueprints/custom-entities.md
+++ b/guide/blueprints/custom-entities.md
@@ -19,9 +19,7 @@ including `bash` and Chef.
The following blueprint shows how a simple script can be embedded in the YAML
(the `|` character is special YAML which makes it easier to insert multi-line text):
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/vanilla-bash-netcat.yaml"
This starts a simple `nc` listener on port 4321 which will respond `hello` to the first
session which connects to it. Test it by running `telnet localhost 4321`
@@ -49,9 +47,7 @@ So if we create a file `/tmp/netcat-server.tgz` containing just `start.sh` in th
which contains the line `echo hello | nc -l 4321`,
we can instead write our example as:
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-file.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/vanilla-bash-netcat-file.yaml"
#### Determining Successful Launch
@@ -69,14 +65,11 @@ the `nc` process exits afterwards, causing Brooklyn to set the entity to an `ON_
(You can also test this with a `killall nc`).
There are other options for determining health: you can set `checkRunning.command` and `stop.command` instead,
-as documented on the javadoc and config keys of the
-{% include java_link.html class_name="VanillaSoftwareProcess" package_path="org/apache/brooklyn/entity/software/base" project_subpath="software/base" %} class,
-and those scripts will be used instead of checking and stopping the process whose PID is in `$PID_FILE`. For example:
-
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-more-commands.yaml %}
-{% endhighlight %}
+as documented on the javadoc and config keys of the
+[org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess](https://brooklyn.apache.org/v/latest/misc/javadoc/org/apache/brooklyn/entity/software/base/VanillaSoftwareProcess.html)
+class, and those scripts will be used instead of checking and stopping the process whose PID is in `$PID_FILE`. For example:
+!CODEFILE "example_yaml/vanilla-bash-netcat-more-commands.yaml"
#### Periodic Health Check
@@ -96,9 +89,7 @@ We can tell Brooklyn to open this port explicitly by specifying `inboundPorts: [
however a more idiomatic way is to specify a config ending with `.port`,
such as:
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-port.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/vanilla-bash-netcat-port.yaml"
The regex for ports to be opened can be configured using
the config `inboundPorts.configRegex` (which has `.*\.port` as the default value).
@@ -126,9 +117,7 @@ However config keys which are *not* declared on the type *must* be declared in t
Blueprint scripts can be parametrised through environment variables, making them reusable in different use-cases.
Define the variables in the `env` block and then reference them using the standard bash notation:
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-env.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/vanilla-bash-netcat-env.yaml"
Non-string objects in the `env` map will be serialized to JSON before passing them to the script.
@@ -138,9 +127,7 @@ Non-string objects in the `env` map will be serialized to JSON before passing th
We can define config keys to be presented to the user
using the `brooklyn.parameters` block:
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-port-parameter.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/vanilla-bash-netcat-port-parameter.yaml"
The example above will allow a user to specify a message to send back
and the port where netcat will listen.
@@ -166,9 +153,7 @@ This gives us quite a bit more power in writing our blueprint:
The *Catalog* tab allows you to add blueprints which you can refer to in other blueprints.
In that tab, click *+* then *YAML*, and enter the following:
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-catalog.bom %}
-{% endhighlight %}
+!CODEFILE "example_yaml/vanilla-bash-netcat-catalog.bom"
This is the same example as in the previous section, wrapped according to the catalog YAML requirements,
with one new block added defining an enricher. An enricher creates a new sensor from other values;
@@ -178,9 +163,7 @@ with the sensor values.
With this added to the catalog, we can reference the type `netcat-example` when we deploy an application.
Return to the *Home* or *Applications* tab, click *+*, and submit this YAML blueprint:
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-reference.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/vanilla-bash-netcat-reference.yaml"
This extends the previous blueprint which we registered in the catalog,
meaning that we don't need to include it each time.
@@ -190,9 +173,7 @@ More importantly, we can package it for others to consume -- or take items other
We can go further and use this to deploy a cluster,
this time giving a custom port as well as a custom message:
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-cluster.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/vanilla-bash-netcat-cluster.yaml"
In either of the above examples, if you explore the tree in the *Applications* view
and look at the *Summary* tab of any of the server instances, you'll now see the URL where netcat is running.
@@ -206,9 +187,7 @@ and if you haven't yet experimented with `resize` on the cluster you might want
Besides detecting this failure, Brooklyn policies can be added to the YAML to take appropriate
action. A simple recovery here might just to automatically restart the process:
-{% highlight yaml %}
-{% readj example_yaml/vanilla-bash-netcat-restarter.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/vanilla-bash-netcat-restarter.yaml"
Autonomic management in Brooklyn often follows the principle that complex behaviours emerge
from composing simple policies.
@@ -285,7 +264,7 @@ command over ssh every 5 seconds. This can be very CPU intensive when there are
is to disable the ssh-polling (by setting `sshMonitoring.enabled: false`) and to configure a different
health-check.
-See documentation on the [Entity's error status]({{ site.path.guide }}/ops/troubleshooting/overview.html#entitys-error-status)
+See documentation on the [Entity's error status]({{ book.path.guide }}/ops/troubleshooting/overview.html#entitys-error-status)
for how Brooklyn models an entity's health.
In the snippet below, we'll define a new health-check sensor (via http polling), and will automatically add this
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/effectors.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/effectors.md b/guide/blueprints/effectors.md
index 41eb645..e56bcd0 100644
--- a/guide/blueprints/effectors.md
+++ b/guide/blueprints/effectors.md
@@ -4,7 +4,7 @@ layout: website-normal
---
Effectors perform an operation of some kind, carried out by a Brooklyn Entity.
-They can be manually invoked or triggered by a [Policy]({{ site.path.guide }}/blueprints/policies.html).
+They can be manually invoked or triggered by a [Policy]({{ book.path.guide }}/blueprints/policies.html).
Common uses of an effector include the following:
@@ -36,7 +36,7 @@ There are a number of additional configuration keys available for the `SSHComman
Here is a simple example of an `SshCommandEffector` definition:
-{% highlight yaml %}
+```yaml
brooklyn.initializers:
- type: org.apache.brooklyn.core.effector.ssh.SshCommandEffector
brooklyn.config:
@@ -48,7 +48,7 @@ Here is a simple example of an `SshCommandEffector` definition:
message:
description: The string to pass to netcat
defaultValue: hi netcat
-{% endhighlight %}
+```
See [`here`](https://brooklyn.apache.org/v/latest/misc/javadoc/org/apache/brooklyn/core/effector/ssh/SshCommandEffector.html) for more details.
@@ -74,7 +74,7 @@ There are a number of additional configuration keys available for the `HTTPComma
When a the header `HttpHeaders.CONTENT_TYPE` is equals to *application/x-www-form-urlencoded* and the `httpPayload` is a `map`, the payload is transformed into a single string using `URLEncoded`.
-{% highlight yaml %}
+```yaml
brooklyn.initializers:
- type: org.apache.brooklyn.core.effector.http.HttpCommandEffector
brooklyn.config:
@@ -94,7 +94,7 @@ brooklyn.initializers:
$.access_token: access.token
headers:
Content-Type: "application/x-www-form-urlencoded"
-{% endhighlight %}
+```
See [`here`](https://brooklyn.apache.org/v/latest/misc/javadoc/org/apache/brooklyn/core/effector/http/HttpCommandEffector.html) for more details.
@@ -102,7 +102,7 @@ See [`here`](https://brooklyn.apache.org/v/latest/misc/javadoc/org/apache/brookl
An `Effector` to add a child blueprint to an entity.
-{% highlight yaml %}
+```yaml
brooklyn.initializers:
- type: org.apache.brooklyn.core.effector.AddChildrenEffector
brooklyn.config:
@@ -129,7 +129,7 @@ brooklyn.initializers:
version: 0.1.0
url: classpath:/brooklyn/osgi/brooklyn-test-osgi-entities.jar
auto_start: true
-{% endhighlight %}
+```
One of the config keys `BLUEPRINT_YAML` (containing a YAML blueprint (map or string)) or `BLUEPRINT_TYPE` (containing a string referring to a catalog type) should be supplied, but not both.
@@ -148,7 +148,7 @@ Writing an effector is straightforward.
Simply extend [`AddEffector`](https://brooklyn.apache.org/v/latest/misc/javadoc/org/apache/brooklyn/core/effector/AddEffector.html),
providing an implementation for `newEffectorBuilder` and adding a constructor that consumes the builder or override an existing effector.
-{% highlight java %}
+```java
public MyEffector(ConfigBag params) {
super(newEffectorBuilder(params).build());
@@ -159,11 +159,11 @@ public static EffectorBuilder<String> newEffectorBuilder(ConfigBag params) {
eff.impl(new Body(eff.buildAbstract(), params));
return eff;
}
-{% endhighlight %}
+```
and supply an `EffectorBody` similar to:
-{% highlight java %}
+```java
protected static class Body extends EffectorBody<String> {
...
@@ -173,7 +173,7 @@ protected static class Body extends EffectorBody<String> {
...
}
}
-{% endhighlight %}
+```
### Best Practice
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/enrichers.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/enrichers.md b/guide/blueprints/enrichers.md
index 6ef1247..2d7cb01 100644
--- a/guide/blueprints/enrichers.md
+++ b/guide/blueprints/enrichers.md
@@ -14,9 +14,7 @@ See below for documentation of the stock enrichers available in Apache Brooklyn.
Takes a source sensor and modifies it in some way before publishing the result in a new sensor. See below an example using `$brooklyn:formatString`.
-{% highlight yaml %}
-{% readj example_yaml/enricher-transformer.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/enricher-transformer.yaml"
#### Propagator
@@ -26,9 +24,7 @@ Use propagator to duplicate one sensor as another, giving the supplied sensor ma
The other use of Propagator is where you specify a producer (using `$brooklyn:entity(...)` as below)
from which to take sensors; in that mode you can specify `propagate` as a list of sensors whose names are unchanged, instead of (or in addition to) this map.
-{% highlight yaml %}
-{% readj example_yaml/enricher-propagator.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/enricher-propagator.yaml"
#### Custom Aggregating
@@ -36,9 +32,7 @@ from which to take sensors; in that mode you can specify `propagate` as a list o
Aggregates multiple sensor values (usually across a tier, esp. a cluster) and performs a supplied aggregation method to them to return an aggregate figure, e.g. sum, mean, median, etc.
-{% highlight yaml %}
-{% readj example_yaml/enricher-aggregator.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/enricher-aggregator.yaml"
There are a number of additional configuration keys available for the Aggregators:
@@ -54,9 +48,7 @@ There are a number of additional configuration keys available for the Aggregator
Joins a sensor whose output is a list into a single item joined by a separator.
-{% highlight yaml %}
-{% readj example_yaml/enricher-joiner.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/enricher-joiner.yaml"
There are a number of additional configuration keys available for the joiner:
@@ -81,9 +73,7 @@ Converts an absolute sensor into a delta sensor (i.e. the difference between the
Converts absolute sensor values into a difference over time. The `enricher.delta.period` indicates the measurement interval.
-{% highlight yaml %}
-{% readj example_yaml/enricher-time-weighted-delta.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/enricher-time-weighted-delta.yaml"
#### Rolling Mean
@@ -130,16 +120,14 @@ For example, if we consider the Transfomer from above, suppose that `enricher.so
is actually a sensor on a different entity called `load.balancer`. In this case, we would need to supply an
`enricher.producer` value.
-{% highlight yaml %}
-{% readj example_yaml/enricher-transformer.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/enricher-transformer.yaml"
It is important to note that the value supplied to `enricher.producer` must be immediately resolvable. While it would be valid
DSL syntax to write:
-{% highlight yaml %}
+```yaml
enricher.producer: brooklyn:entity($brooklyn:attributeWhenReady("load.balancer.entity"))
-{% endhighlight %}
+```
(assuming the `load.balancer.entity` sensor returns a Brooklyn entity), this will not function properly because `enricher.producer`
will unsuccessfully attempt to get the supplied entity immediately.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/entity-configuration.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/entity-configuration.md b/guide/blueprints/entity-configuration.md
index 25827ad..b956708 100644
--- a/guide/blueprints/entity-configuration.md
+++ b/guide/blueprints/entity-configuration.md
@@ -19,14 +19,14 @@ and also it does not work in all contexts such as for an enricher's configuratio
A simple example is shown below:
-{% highlight yaml %}
+```yaml
services:
- type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
brooklyn.config:
webapp.enabledProtocols: http
http.port: 9080
wars.root: http://search.maven.org/remotecontent?filepath=org/apache/brooklyn/example/brooklyn-example-hello-world-webapp/0.9.0/brooklyn-example-hello-world-webapp-0.9.0.war
-{% endhighlight %}
+```
If no config value is supplied, the default for that config key will be used. For example,
`http.port` would default to 8080 if not explicitly supplied.
@@ -44,7 +44,7 @@ blueprint (i.e. inside the `brooklyn.config` block).
It can also explicitly declare config keys, using the `brooklyn.parameters` block. The example
below illustrates the principle:
-{% highlight yaml %}
+```yaml
brooklyn.catalog:
items:
- id: entity-config-example
@@ -64,19 +64,19 @@ brooklyn.catalog:
echo "My example launch command: $MESSAGE"
checkRunning.command: |
echo "My example checkRunning command: $MESSAGE"
-{% endhighlight %}
+```
Once added to the catalog, it can be used with the simple blueprint below (substituting the location
of your choice). Because no configuration has been overridden, this will use the default value
for `custom.message`, and will use the given values for `launch.command` and `checkRunning.command`:
-{% highlight yaml %}
+```yaml
location: aws-ec2:us-east-1
services:
- type: entity-config-example
-{% endhighlight %}
+```
-For details of how to write and add catalog items, see [Catalog]({{ site.path.guide }}/blueprints/catalog/).
+For details of how to write and add catalog items, see [Catalog]({{ book.path.guide }}/blueprints/catalog/).
#### Config Key Constraints
@@ -91,7 +91,7 @@ can be any of:
This is illustrated in the example below:
-{% highlight yaml %}
+```yaml
brooklyn.catalog:
items:
- id: entity-constraint-example
@@ -121,18 +121,18 @@ brooklyn.catalog:
factoryMethod.name: lessThan
factoryMethod.args:
- 256.0
-{% endhighlight %}
+```
An example usage of this toy example, once added to the catalog, is shown below:
-{% highlight yaml %}
+```yaml
services:
- type: entity-constraint-example
brooklyn.config:
compulsoryExample: foo
addressExample: 1.1.1.1
numberExample: 2.0
-{% endhighlight %}
+```
### Inheriting Configuration
@@ -167,7 +167,7 @@ consider the `entity-config-example` added to the catalog in the section
[Configuration in a Catalog Item](#configuration-in-a-catalog-item).
We can override these values. If not overridden, then the existing values from the super-type will be used:
-{% highlight yaml %}
+```yaml
location: aws-ec2:us-east-1
services:
- type: entity-config-example
@@ -175,7 +175,7 @@ services:
custom.message: Goodbye
launch.command: |
echo "Sub-type launch command: $MESSAGE"
-{% endhighlight %}
+```
@@ -193,7 +193,7 @@ Configuration passed to an entity is inherited by all child entities, unless exp
In the example below, the `wars.root` config key is inherited by all TomcatServer entities created
under the cluster, so they will use that war:
-{% highlight yaml %}
+```yaml
services:
- type: org.apache.brooklyn.entity.group.DynamicCluster
brooklyn.config:
@@ -201,7 +201,7 @@ services:
dynamiccluster.memberspec:
$brooklyn:entitySpec:
type: org.apache.brooklyn.entity.webapp.tomcat.TomcatServer
-{% endhighlight %}
+```
In the above example, it would be better to have specified the `wars.root` configuration in the
`TomcatServer` entity spec, rather than at the top level. This would make it clearer for the reader
@@ -236,7 +236,7 @@ it retrievies the value of `exampleConfig` which is the DSL expression, and eval
context of the parent entity that declares it. Therefore `$brooklyn:config("ownConfig")` returns
the parent's `ownConfig` value, and the final result for `refExampleConfig` is set to "parentValue":
-{% highlight yaml %}
+```yaml
services:
- type: org.apache.brooklyn.entity.stock.BasicApplication
brooklyn.config:
@@ -248,7 +248,7 @@ services:
brooklyn.config:
ownConfig: childValue
refExampleConfig: $brooklyn:config("exampleConfig")
-{% endhighlight %}
+```
_However, the web-console also shows other misleading (incorrect!) config values for the child
entity. It shows the inherited config value of `exampleConfig` as "childValue" (because the
@@ -282,7 +282,7 @@ the section [Configuration in a Catalog Item](#configuration-in-a-catalog-item))
The environment variables will include the `MESSAGE`
set in the super-type and the `MESSAGE2` set here:
-{% highlight yaml %}
+```yaml
location: aws-ec2:us-east-1
services:
- type: entity-config-example
@@ -291,7 +291,7 @@ services:
MESSAGE2: Goodbye
launch.command: |
echo "Different example launch command: $MESSAGE and $MESSAGE2"
-{% endhighlight %}
+```
To explicitly remove a value from the super-type's map (rather than adding to it), a blank entry
can be defined.
@@ -311,7 +311,7 @@ In the example below, the VM will be provisioned with minimum 2G ram and minimum
also use the merged template options value of
`{placementGroup: myPlacementGroup, securityGroupIds: sg-000c3a6a}`:
-{% highlight yaml %}
+```yaml
location:
aws-ec2:us-east-1:
minRam: 2G
@@ -324,14 +324,14 @@ services:
minCores: 2
templateOptions:
securityGroupIds: sg-000c3a6a
-{% endhighlight %}
+```
The merging of `templateOptions` is shallow (i.e. maps within the `templateOptions` are not merged).
In the example below, the `userMetadata` value within `templateOptions` will be overridden by the
entity's value, rather than the maps being merged; the value used when provisioning will be
`{key2: val2}`:
-{% highlight yaml %}
+```yaml
location:
aws-ec2:us-east-1:
templateOptions:
@@ -343,7 +343,7 @@ services:
provisioning.properties:
userMetadata:
key2: val2
-{% endhighlight %}
+```
#### Re-inherited Versus not Re-inherited
@@ -368,7 +368,7 @@ and is co-located on the same VM as Tomcat. We don't want the Tomcat's configura
entity might re-execute the Tomcat's install command! Instead, the `install.command` config is
"consumed" by the Tomcat instance and is not re-inherited:
-{% highlight yaml %}
+```yaml
services:
- type: org.apache.brooklyn.entity.webapp.tomcat.Tomcat8Server
brooklyn.config:
@@ -378,14 +378,14 @@ services:
brooklyn.config:
logstash.elasticsearch.host: $brooklyn:entity("es").attributeWhenReady("urls.http.withBrackets")
...
-{% endhighlight %}
+```
"Not re-inherited" differs from "never inherited". The example below illustrates the difference,
though this use is discouraged (it is mostly for backwards compatibility). The `post.install.command`
is not consumed by the `BasicApplication`, so will be inherited by the `Tomcat8Server` which will
consume it. The config value will therefore not be inherited by the `logstash-child`.
-{% highlight yaml %}
+```yaml
services:
- type: org.apache.brooklyn.entity.stock.BasicApplication
brooklyn.config:
@@ -399,7 +399,7 @@ services:
brooklyn.config:
logstash.elasticsearch.host: $brooklyn:entity("es").attributeWhenReady("urls.http.withBrackets")
...
-{% endhighlight %}
+```
#### Never Inherited
@@ -470,7 +470,7 @@ Below is a (contrived!) example of inheriting the `example.map` config key. When
in a blueprint, the entity's config will be merged with that defined in the super-type, and the
parent entity's value will never be inherited:
-{% highlight yaml %}
+```yaml
brooklyn.catalog:
items:
- id: entity-config-inheritance-example
@@ -489,7 +489,7 @@ brooklyn.catalog:
brooklyn.config:
example.map:
MESSAGE: Hello
-{% endhighlight %}
+```
The blueprints below demonstrate the various permutations for setting configuration for the
config `example.map`. This can be inspected by looking at the entity's config. The config
@@ -499,7 +499,7 @@ config from the parent is not inherited because there is an explicit inheritance
so it just has the value `{MESSAGE: "Hello"}`; in app4 again the parent's config is ignored,
with the super-type and entity's config being merged to give `{MESSAGE: "Hello", MESSAGE_IN_CHILD: "InChild"}`.
-{% highlight yaml %}
+```yaml
location: aws-ec2:us-east-1
services:
- type: org.apache.brooklyn.entity.stock.BasicApplication
@@ -533,7 +533,7 @@ services:
brooklyn.config:
example.map:
MESSAGE_IN_CHILD: InChild
-{% endhighlight %}
+```
A limitations of `inheritance.parent` is when inheriting values from parent and grandparent
entities: a value specified on the parent will override (rather than be merged with) the
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/index.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/index.md b/guide/blueprints/index.md
index 01ab184..260fc2d 100644
--- a/guide/blueprints/index.md
+++ b/guide/blueprints/index.md
@@ -26,4 +26,4 @@ children:
---
-{% include list-children.html %}
+
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/archetype.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/archetype.md b/guide/blueprints/java/archetype.md
index f9acac8..8c112ad 100644
--- a/guide/blueprints/java/archetype.md
+++ b/guide/blueprints/java/archetype.md
@@ -14,9 +14,9 @@ developing a new Java entity, and generating the OSGi bundle for it.
#### Generating the Project
The archetype can be used interactively, by running:
-{% highlight bash %}
+```bash
$ mvn archetype:generate
-{% endhighlight %}
+```
The user will be prompted for the archetype to use (i.e. group "org.apache.brooklyn"
and artifact "brooklyn-archetype-quickstart"), as well as options for the project
@@ -25,8 +25,8 @@ to be created.
Alternatively, all options can be supplied at the command line. For example,
if creating a project named "autobrick" for "com.acme":
-{% highlight bash %}
-$ BROOKLYN_VERSION={{ site.brooklyn-version }}
+```bash
+$ BROOKLYN_VERSION={{ book.brooklyn-version }}
$ mvn archetype:generate \
-DarchetypeGroupId=org.apache.brooklyn \
-DarchetypeArtifactId=brooklyn-archetype-quickstart \
@@ -36,7 +36,7 @@ $ mvn archetype:generate \
-Dversion=0.1.0-SNAPSHOT \
-DpackageName=com.acme.autobrick \
-DinteractiveMode=false
-{% endhighlight %}
+```
This will create a directory with the artifact name (e.g. "autobrick" in the example above).
Note that if run from a directory containing a pom, it will also modify that pom to add this as
@@ -52,16 +52,16 @@ The `README.md` file within the project gives further guidance.
To build, run the commands:
-{% highlight bash %}
+```bash
$ cd autobrick
$ mvn clean install
-{% endhighlight %}
+```
#### Adding to the Catalog
The build will produce an OSGi bundle in `target/autobrick-0.1.0-SNAPSHOT.jar`, suitable for
-use in the [Brooklyn catalog]({{ site.path.guide }}/blueprints/catalog/) (using `brooklyn.libraries`).
+use in the [Brooklyn catalog]({{ book.path.guide }}/blueprints/catalog/) (using `brooklyn.libraries`).
To use this in your Brooklyn catalog you will first have to copy the target jar to a suitable location.
For developing/testing purposes storing on the local filesystem is fine.
@@ -72,7 +72,7 @@ The project comes with a `catalog.bom` file, located in `src/main/resources`.
Modify this file by adding a 'brooklyn.libraries' statement to the bom pointing to the jar.
For example:
-{% highlight yaml %}
+```yaml
brooklyn.catalog:
brooklyn.libraries:
- file:///path/to/jar/autobrick-0.1.0-SNAPSHOT.jar
@@ -82,13 +82,13 @@ brooklyn.catalog:
- id: com.acme.autobrick.MySample
item:
type: com.acme.autobrick.MySample
-{% endhighlight %}
+```
The command below will use the CLI to add this to the catalog of a running Brooklyn instance:
-{% highlight bash %}
+```bash
br catalog add catalog.bom
-{% endhighlight %}
+```
After running that command, the OSGi bundle will have been added to the OSGi container, and the
entity will have been added to your catalog. It can then be used in the same way as regular Brooklyn
@@ -96,10 +96,10 @@ entities.
For example, you can use the blueprint:
-{% highlight yaml %}
+```yaml
services:
- type: com.acme.autobrick.MySample
-{% endhighlight %}
+```
### Testing Entities
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/bundle-dependencies.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/bundle-dependencies.md b/guide/blueprints/java/bundle-dependencies.md
index 0f07fb6..a8e4732 100644
--- a/guide/blueprints/java/bundle-dependencies.md
+++ b/guide/blueprints/java/bundle-dependencies.md
@@ -28,7 +28,7 @@ is a convenient way of building OSGi bundles.
#### OSGi Bundles Declared in Catalog Items
-Within a [catalog item]({{ site.path.guide}}/blueprints/catalog/), a list of URLs can be supplied under
+Within a [catalog item]({{ book.path.guide}}/blueprints/catalog/), a list of URLs can be supplied under
`brooklyn.libraries`. Each URL should point to an OSGi bundle. This list should include the OSGi
bundle that has the Java code for your blueprint, and also the OSGi bundles that it depends
on (including all transitive dependencies).
@@ -37,8 +37,8 @@ It is vital that these jars are built correctly as OSGi bundles, and that all tr
dependencies are included. The bundles will be added to Karaf in the order given, so a bundle's
dependencies should be listed before the bundle(s) that depend on them.
-In the [GistGenerator example]({{ site.path.guide}}/blueprints/java/defining-and-deploying.html), the
-[catalog.bom file]({{ site.path.guide}}/blueprints/java/gist_generator/gist_generator.bom) included
+In the [GistGenerator example]({{ book.path.guide}}/blueprints/java/defining-and-deploying.html), the
+[catalog.bom file]({{ book.path.guide}}/blueprints/java/gist_generator/gist_generator.bom) included
the URL of the dependency `org.eclipse.egit.github.core`. It also (before that line) included
its transitive dependency, which is a specific version of `gson`.
@@ -64,7 +64,7 @@ using `./bin/client`, and add the bundles and features as desired.
Examples of some useful commands are shown below:
-{% highlight bash %}
+```bash
karaf@amp> bundle:install -s http://repo1.maven.org/maven2/org/apache/servicemix/bundles/org.apache.servicemix.bundles.egit.github.core/2.1.5_1/org.apache.servicemix.bundles.egit.github.core-2.1.5_1.jar
Bundle ID: 316
@@ -75,7 +75,7 @@ karaf@amp> bundle:headers org.apache.servicemix.bundles.egit.github.core
...
karaf@amp> bundle:uninstall org.apache.servicemix.bundles.egit.github.core
-{% endhighlight %}
+```
##### Karaf Deploy Folder
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/common-usage.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/common-usage.md b/guide/blueprints/java/common-usage.md
index 2c9d91b..3410a37 100644
--- a/guide/blueprints/java/common-usage.md
+++ b/guide/blueprints/java/common-usage.md
@@ -33,11 +33,11 @@ Configuration keys are typically defined as static named fields on the Entity in
define the configuration values that can be passed to the entity during construction. For
example:
-{% highlight java %}
+```java
public static final ConfigKey<String> ROOT_WAR = new ConfigKeys.newStringConfigKey(
"wars.root",
"WAR file to deploy as the ROOT, as URL (supporting file: and classpath: prefixes)");
-{% endhighlight %}
+```
If supplying a default value, it is important that this be immutable. Otherwise, it risks users
of the blueprint modifying the default value, which would affect blueprints that are subsequently
@@ -62,11 +62,11 @@ port starting from 8081 will be used.
Sensors are typically defined as static named fields on the Entity interface. These define
the events published by the entity, which interested parties can subscribe to. For example:
-{% highlight java %}
+```java
AttributeSensor<String> MANAGEMENT_URL = Sensors.newStringSensor(
"crate.managementUri",
"The address at which the Crate server listens");
-{% endhighlight %}
+```
### Declaring Effectors
@@ -79,23 +79,23 @@ be defined. Examples of each are given below.
A method on the entity interface can be annotated to indicate it is an effector, and to provide
metadata about the effector and its parameters.
-{% highlight java %}
+```java
@org.apache.brooklyn.core.annotation.Effector(description="Retrieve a Gist")
public String getGist(@EffectorParam(name="id", description="Gist id") String id);
-{% endhighlight %}
+```
#### Static Field Effector Declaration
A static field can be defined on the entity to define an effector, giving metadata about that effector.
-{% highlight java %}
+```java
public static final Effector<String> EXECUTE_SCRIPT = Effectors.effector(String.class, "executeScript")
.description("invokes a script")
.parameter(ExecuteScriptEffectorBody.SCRIPT)
.impl(new ExecuteScriptEffectorBody())
.build();
-{% endhighlight %}
+```
In this example, the implementation of the effector is an instance of `ExecuteScriptEffectorBody`.
This implements `EffectorBody`. It will be invoked whenever the effector is called.
@@ -107,7 +107,7 @@ An effector can be added to an entity dynamically - either as part of the entity
or as separate initialization code. This allows the implementation of the effector to be shared
amongst multiple entities, without sub-classing. For example:
-{% highlight java %}
+```java
Effector<Void> GET_GIST = Effectors.effector(Void.class, "createGist")
.description("Create a Gist")
.parameter(String.class, "id", "Gist id")
@@ -125,7 +125,7 @@ public static void CreateGistEffectorBody implements EffectorBody<Void>() {
public void init() {
getMutableEntityType().addEffector(CREATE_GIST, new CreateGistEffectorBody());
}
-{% endhighlight %}
+```
### Effector Invocation
@@ -172,12 +172,12 @@ marked as done until its queued sub-tasks are complete.
When creating tasks, the `TaskBuilder` can be used to create simple tasks or to create compound tasks
whose sub-tasks are to be executed either sequentially or in parallel. For example:
-{% highlight java %}
+```java
TaskBuilder.<Integer>builder()
.displayName("stdout-example")
.body(new Callable<Integer>() { public Integer call() { System.out.println("example"; } })
.build();
-{% endhighlight %}
+```
There are also builder and factory utilities for common types of operation, such as executing SSH
commands using `SshTasks`.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/defining-and-deploying.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/defining-and-deploying.md b/guide/blueprints/java/defining-and-deploying.md
index 11a2889..744dead 100644
--- a/guide/blueprints/java/defining-and-deploying.md
+++ b/guide/blueprints/java/defining-and-deploying.md
@@ -14,7 +14,7 @@ with an effector to create new gists.
## Project Setup
Follow the instructions to create a new Java project using the [archetype](archetype.html), and
-import it into your [favorite IDE]({{ site.path.guide }}/dev/env/ide/). This example assumes you
+import it into your [favorite IDE]({{ book.path.guide }}/dev/env/ide/). This example assumes you
used the groupId `com.acme` and artifact id `autobrick`.
First ensure you can build this project at the command line, using `mvn clean install`.
@@ -27,21 +27,19 @@ a dependency. Add the following to your `pom.xml` inside the `<dependencies>` se
(see [Maven](https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html)
for more details):
-{% highlight xml %}
+```xml
<dependency>
<groupId>org.eclipse.mylyn.github</groupId>
<artifactId>org.eclipse.egit.github.core</artifactId>
<version>2.1.5</version>
</dependency>
-{% endhighlight %}
+```
Create a new Java interface, `GistGenerator`, to describe the entity's interface (i.e. the
configuration options, sensors, and effectors). The code below assumes you have created this
in the package `com.acme` for `src/main/java`.
-{% highlight java %}
-{% readj gist_generator/GistGenerator.java %}
-{% endhighlight %}
+!CODEFILE "gist_generator/GistGenerator.java"
To describe each part of this:
@@ -63,9 +61,7 @@ discussed in the section [Dynamically Added Effectors](common-usage.html#dynamic
Next lets add the implementation. Create a new Java class named `GistGeneratorImpl`.
-{% highlight java %}
-{% readj gist_generator/GistGeneratorImpl.java %}
-{% endhighlight %}
+!CODEFILE "gist_generator/GistGeneratorImpl.java"
To describe each part of this:
@@ -109,9 +105,7 @@ We will create a similar Java-based test for this blueprint. Create a new Java c
You will need to substitute the github access token you generated in the previous section for
the placeholder text `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx`.
-{% highlight java %}
-{% readj gist_generator/GistGeneratorTest.java %}
-{% endhighlight %}
+!CODEFILE "gist_generator/GistGeneratorTest.java"
Similarly, we can write a test that uses the `GistGenerator` from a YAML blueprint.
Create a new Java class named `GistGeneratorYamlTest` in the package `com.acme`,
@@ -119,13 +113,10 @@ inside `src/test/java`.
Again you will need to substitute the github access token you generated in the previous section for
the placeholder text `xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx`. See the section on
-[externalised configuration]({{ site.path.guide }}/ops/externalized-configuration.html)
+[externalised configuration]({{ book.path.guide }}/ops/externalized-configuration.html)
for how to store these credentials more securely.
-{% highlight java %}
-{% readj gist_generator/GistGeneratorYamlTest.java %}
-{% endhighlight %}
-
+!CODEFILE "gist_generator/GistGeneratorYamlTest.java"
## Building the OSGi Bundle
@@ -145,20 +136,18 @@ Similar to the `sample.bom` entity that ships with the archetype, we will define
to add our `GistGenerator` to the catalog. Substitute the URL below for your own newly built
artifact (which will be in the `target` sub-directory after running `mvn clean install`).
-{% highlight yaml %}
-{% readj gist_generator/gist_generator.bom %}
-{% endhighlight %}
+!CODEFILE "gist_generator/gist_generator.bom"
-See [Handling Bundle Dependencies]({{ site.path.guide}}/blueprints/java/bundle-dependencies.html)
+See [Handling Bundle Dependencies]({{ book.path.guide}}/blueprints/java/bundle-dependencies.html)
for a description of the `brooklyn.libraries` used above, and for other alternative approaches.
The command below will use the `br` CLI to add this to the catalog of a running Brooklyn instance.
Substitute the credentials, URL and port for those of your server.
-{% highlight bash %}
+```bash
$ br login https://127.0.0.1:8443 admin pa55w0rd
$ br catalog add gist_generator.bom
-{% endhighlight %}
+```
## Using the blueprint
@@ -173,5 +162,5 @@ The YAML blueprint below shows an example usage of this blueprint:
Note the type name matches the id defined in the `.bom` file.
-You can now call the effector by any of the standard means - [web console]({{ site.path.guide }}/ops/gui/),
-[REST api]({{ site.path.guide }}/ops/rest.html), or [Client CLI]({{ site.path.guide }}/ops/cli/).
+You can now call the effector by any of the standard means - [web console]({{ book.path.guide }}/ops/gui/),
+[REST api]({{ book.path.guide }}/ops/rest.html), or [Client CLI]({{ book.path.guide }}/ops/cli/).
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/entities.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/entities.md b/guide/blueprints/java/entities.md
index 1e2623d..5dc23e4 100644
--- a/guide/blueprints/java/entities.md
+++ b/guide/blueprints/java/entities.md
@@ -74,7 +74,7 @@ Sensors at base entities are often retrieved by feeds which poll the entity's co
The ``SoftwareProcess`` provides a good example; by subclassing it and overriding the ``connectSensors()`` method
you could wire some example sensors using the following:
-{% highlight java %}
+```java
public void connectSensors() {
super.connectSensors()
@@ -95,7 +95,7 @@ protected void disconnectSensors() {
super.disconnectSensors();
if (httpFeed != null) httpFeed.stop();
}
-{% endhighlight %}
+```
In this example (a simplified version of ``JBoss7Server``), the url returns metrics in JSON.
We report the entity as up if we get back an http response code of 200, or down if any other response code or exception.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/entitlements.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/entitlements.md b/guide/blueprints/java/entitlements.md
index 91d8dac..f0c67d7 100644
--- a/guide/blueprints/java/entitlements.md
+++ b/guide/blueprints/java/entitlements.md
@@ -8,9 +8,11 @@ essentially permissions.
Any entitlement scheme can be implemented by supplying a class which implements one method on one class:
- public interface EntitlementManager {
- public <T> boolean isEntitled(@Nullable EntitlementContext context, @Nonnull EntitlementClass<T> entitlementClass, @Nullable T entitlementClassArgument);
- }
+```java
+public interface EntitlementManager {
+ public <T> boolean isEntitled(@Nullable EntitlementContext context, @Nonnull EntitlementClass<T> entitlementClass, @Nullable T entitlementClassArgument);
+}
+```
This answers the question who is allowed do what to whom, looking at the following fields:
@@ -24,19 +26,21 @@ This answers the question who is allowed do what to whom, looking at the followi
To set a custom entitlements manager to apply across the board, simply use:
- brooklyn.entitlements.global=org.apache.brooklyn.core.mgmt.entitlement.AcmeEntitlementManager
+```properties
+brooklyn.entitlements.global=org.apache.brooklyn.core.mgmt.entitlement.AcmeEntitlementManager
+```
The example above refers to a sample manager which is included in the test JARs of Brooklyn,
-which you can see [here]({{ site.brooklyn.url.git }}/core/src/test/java/org/apache/brooklyn/core/mgmt/entitlement/AcmeEntitlementManagerTest.java),
+which you can see [here]({{ book.brooklyn.url.git }}/core/src/test/java/org/apache/brooklyn/core/mgmt/entitlement/AcmeEntitlementManagerTest.java),
and include in your project by adding the core tests JAR to your `dropins` folder.
There are some entitlements schemes which exist out of the box, so for a simpler setup,
-see [Operations: Entitlements]({{ site.path.guide }}/ops/configuration/brooklyn_cfg.html#entitlements).
+see [Operations: Entitlements]({{ book.path.guide }}/ops/configuration/brooklyn_cfg.html#entitlements).
There are also more complex schemes which some users have developed, including LDAP extensions
which re-use the LDAP authorization support in Brooklyn,
allowing permissions objects to be declared in LDAP leveraging regular expressions.
For more information on this, ask on IRC or the mailing list,
and see
-{% include java_link.html class_name="EntitlementManager" package_path="org/apache/brooklyn/api/mgmt/entitlement" project_subpath="api" %}.
+[EntitlementManager](https://brooklyn.apache.org/v/latest/misc/javadoc/org/apache/brooklyn/api/mgmt/entitlement/EntitlementManager.html).
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/entity.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/entity.md b/guide/blueprints/java/entity.md
index 8b05d9c..72d41c4 100644
--- a/guide/blueprints/java/entity.md
+++ b/guide/blueprints/java/entity.md
@@ -13,9 +13,9 @@ There are several ways to write a new entity:
scripts.
* For composite entities, use YAML to compose exiting types of entities (potentially overwriting
parts of their configuration), and wire them together.
-* Use **[Chef recipes]({{site.path.guide}}/blueprints/chef)**.
-* Use **[Salt formulas]({{site.path.guide}}/blueprints/salt)**.
-* Use **[Ansible playbooks]({{site.path.guide}}/blueprints/ansible)**.
+* Use **[Chef recipes]({{book.path.guide}}/blueprints/chef)**.
+* Use **[Salt formulas]({{book.path.guide}}/blueprints/salt)**.
+* Use **[Ansible playbooks]({{book.path.guide}}/blueprints/ansible)**.
* Write pure-java, extending existing base-classes. For example, the `GistGenerator`
[example](defining-and-deploying.html). These can use utilities such as `HttpTool` and
`BashCommands`.
@@ -99,6 +99,6 @@ hierarchy; it is suggested to avoid these, looking at the ones below instead):
You might also find the following helpful:
-* **[Entity Design Tips]({{site.path.guide}}/dev/tips/index.html#EntityDesign)**
-* The **[User Guide]({{site.path.guide}})**
+* **[Entity Design Tips]({{book.path.guide}}/dev/tips/index.html#EntityDesign)**
+* The **[User Guide]({{book.path.guide}})**
* The **[Mailing List](https://mail-archives.apache.org/mod_mbox/brooklyn-dev/)**
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/feeds.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/feeds.md b/guide/blueprints/java/feeds.md
index 4c151de..e904db8 100644
--- a/guide/blueprints/java/feeds.md
+++ b/guide/blueprints/java/feeds.md
@@ -37,7 +37,7 @@ important that the entity's `rebind()` method recreates the feed.
An `HttpFeed` polls over http(s). An example is shown below:
-{% highlight java %}
+```java
private HttpFeed feed;
@Override
@@ -61,14 +61,14 @@ protected void disconnectSensors() {
super.disconnectSensors();
if (feed != null) feed.stop();
}
-{% endhighlight %}
+```
##### SSH Feed
An SSH feed executes a command over ssh periodically. An example is shown below:
-{% highlight java %}
+```java
private AbstractCommandFeed feed;
@Override
@@ -91,13 +91,13 @@ protected void disconnectSensors() {
super.disconnectSensors();
if (feed != null) feed.stop();
}
-{% endhighlight %}
+```
##### WinRm CMD Feed
A WinRM feed executes a windows command over winrm periodically. An example is shown below:
-{% highlight java %}
+```java
private AbstractCommandFeed feed;
//@Override
@@ -118,7 +118,7 @@ protected void disconnectSensors() {
super.disconnectSensors();
if (feed != null) feed.stop();
}
-{% endhighlight %}
+```
##### Windows Performance Counter Feed
@@ -131,7 +131,7 @@ This feed uses WinRM to invoke the windows utility <tt>typeperf</tt> to query fo
of performance counters, by name. The values are extracted from the response, and published to the
entity's sensors. An example is shown below:
-{% highlight java %}
+```java
private WindowsPerformanceCounterFeed feed;
@Override
@@ -147,7 +147,7 @@ protected void disconnectSensors() {
super.disconnectSensors();
if (feed != null) feed.stop();
}
-{% endhighlight %}
+```
##### JMX Feed
@@ -160,7 +160,7 @@ or it can be explicitly supplied.
An example is shown below:
-{% highlight java %}
+```java
private JmxFeed feed;
@Override
@@ -184,7 +184,7 @@ protected void disconnectSensors() {
super.disconnectSensors();
if (feed != null) feed.stop();
}
-{% endhighlight %}
+```
@@ -196,7 +196,7 @@ an in-line anonymous inner classes).
An example is shown below:
-{% highlight java %}
+```java
public static class ErrorCountRetriever implements Callable<Integer> {
private final Entity entity;
@@ -230,4 +230,4 @@ protected void disconnectSensors() {
super.disconnectSensors();
if (feed != null) feed.stop();
}
-{% endhighlight %}
+```
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/index.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/index.md b/guide/blueprints/java/index.md
index 1cd025e..71943a5 100644
--- a/guide/blueprints/java/index.md
+++ b/guide/blueprints/java/index.md
@@ -19,7 +19,7 @@ children:
Java blueprints are powerful, but also rather more difficult to write than YAML.
Advanced Java skills are required.
-{% include list-children.html %}
+
The main uses of Java-based blueprints are:
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/java/topology-dependencies.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/java/topology-dependencies.md b/guide/blueprints/java/topology-dependencies.md
index 93bbce3..29aa8a0 100644
--- a/guide/blueprints/java/topology-dependencies.md
+++ b/guide/blueprints/java/topology-dependencies.md
@@ -11,12 +11,10 @@ recommended.
The example below creates a three tier web service, composed of an Nginx load-balancer,
a cluster of Tomcat app-servers, and a MySQL database. It is similar to the [YAML policies
-example]({{ site.path.guide }}/start/policies.html), but also includes the MySQL database
+example]({{ book.path.guide }}/start/policies.html), but also includes the MySQL database
to demonstrate the use of dependent configuration.
-{% highlight java %}
-{% readj java_app/ExampleWebApp.java %}
-{% endhighlight %}
+!CODEFILE "java_app/ExampleWebApp.java"
To describe each part of this:
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/multiple-services.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/multiple-services.md b/guide/blueprints/multiple-services.md
index 955e2bd..b9baa94 100644
--- a/guide/blueprints/multiple-services.md
+++ b/guide/blueprints/multiple-services.md
@@ -12,9 +12,7 @@ services can be configured, composed, and combined.
We'll begin by using more key-value pairs to configure the JBoss server to run a real app:
-{% highlight yaml %}
-{% readj example_yaml/appserver-configured.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/appserver-configured.yaml"
(As before, you'll need to add the `location` info; `localhost` will work for these and subsequent examples.)
@@ -32,9 +30,7 @@ If you explored the `hello-world-sql` application we just deployed,
you'll have noticed it tries to access a database.
And it fails, because we have not set one up. Let's do that now:
-{% highlight yaml %}
-{% readj example_yaml/appserver-w-db.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/appserver-w-db.yaml"
Here there are a few things going on:
@@ -80,9 +76,7 @@ in superclasses and are portable across multiple implementations.
Here's an example deploying the same application but with different flavors of the components:
-{% highlight yaml %}
-{% readj example_yaml/appserver-w-db-other-flavor.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/appserver-w-db-other-flavor.yaml"
By changing two lines we've switched from JBoss and MySQL to Tomcat and MariaDB.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/policies.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/policies.md b/guide/blueprints/policies.md
index ff8d1f1..d5510d2 100644
--- a/guide/blueprints/policies.md
+++ b/guide/blueprints/policies.md
@@ -39,7 +39,7 @@ An AutoScaler policy can take any sensor as a metric, have its watermarks tuned
e.g. if the average request per second across a cluster of Tomcat servers goes over the high watermark, it will resize the cluster to bring the average back to within the watermarks.
-{% highlight yaml %}
+```yaml
brooklyn.policies:
- type: org.apache.brooklyn.policy.autoscaling.AutoScalerPolicy
brooklyn.config:
@@ -50,7 +50,7 @@ brooklyn.policies:
resizeDownStabilizationDelay: 1m
maxPoolSize: 3
-{% endhighlight %}
+```
#### ServiceRestarter Policy
@@ -62,12 +62,12 @@ Attaches to a SoftwareProcess or to anything Startable which emits `ha.entityFai
If there is a subsequent failure within a configurable time interval or if the restart fails,
this gives up and emits `ha.entityFailed.restart` for other policies to act upon or for manual intervention.
-{% highlight yaml %}
+```yaml
brooklyn.policies:
- type: org.apache.brooklyn.policy.ha.ServiceRestarter
brooklyn.config:
failOnRecurringFailuresInThisDuration: 5m
-{% endhighlight %}
+```
Typically this is used in conjunction with the FailureDetector enricher to emit the trigger sensor.
The [introduction to policies](../start/policies.html) shows a worked
@@ -204,24 +204,24 @@ Writing a policy is straightforward.
Simply extend [``AbstractPolicy``](https://brooklyn.apache.org/v/latest/misc/javadoc/org/apache/brooklyn/core/policy/AbstractPolicy.html),
overriding the [``setEntity``](https://brooklyn.apache.org/v/latest/misc/javadoc/org/apache/brooklyn/core/objs/AbstractEntityAdjunct.html#setEntity-org.apache.brooklyn.api.entity.EntityLocal-) method to supply any subscriptions desired:
-{% highlight java %}
+```java
@Override
public void setEntity(EntityLocal entity) {
super.setEntity(entity)
subscribe(entity, TARGET_SENSOR, this)
}
-{% endhighlight %}
+```
and supply the computation and/or activity desired whenever that event occurs:
-{% highlight java %}
+```java
@Override
public void onEvent(SensorEvent<Integer> event) {
int val = event.getValue()
if (val % 2 == 1)
entity.sayYoureOdd();
}
-{% endhighlight %}
+```
You'll want to do more complicated things, no doubt,
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/salt/index.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/salt/index.md b/guide/blueprints/salt/index.md
index 265e07f..b639602 100644
--- a/guide/blueprints/salt/index.md
+++ b/guide/blueprints/salt/index.md
@@ -13,4 +13,4 @@ Comments on this support and suggestions for further development are welcome.
This guide assumes you are familiar with the basics of [creating YAML blueprints](../).
-{% include list-children.html %}
+
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/setting-locations.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/setting-locations.md b/guide/blueprints/setting-locations.md
index 91efc5f..ea9138e 100644
--- a/guide/blueprints/setting-locations.md
+++ b/guide/blueprints/setting-locations.md
@@ -5,20 +5,16 @@ toc: ../guide_toc.json
categories: [use, guide, defining-applications]
---
-{% include fields.md %}
-
Brooklyn supports a very wide range of target locations.
With deep integration to [Apache jclouds](https://jclouds.apache.org), most well-known clouds
-and cloud platforms are supported. See the [Locations guide]({{ site.path.guide }}/locations/)
+and cloud platforms are supported. See the [Locations guide]({{ book.path.guide }}/locations/)
for details and more examples.
### Cloud Example
The following example is for Amazon EC2:
-{% highlight yaml %}
-{% readj example_yaml/simple-appserver-with-location.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/simple-appserver-with-location.yaml"
(You'll need to replace the `identity` and `credential` with the
"Access Key ID" and "Secret Access Key" for your account,
@@ -36,10 +32,7 @@ You can also specify pre-existing servers to use -- "bring-your-own-nodes".
The example below shows a pool of machines that will be used by the entities within the
application.
-{% highlight yaml %}
-{% readj example_yaml/simple-appserver-with-location-byon.yaml %}
-{% endhighlight %}
-
+!CODEFILE "example_yaml/simple-appserver-with-location-byon.yaml"
### Single Line and Multi Line Locations
@@ -48,11 +41,11 @@ configuration option per line (recommended for all but the simplest locations).
For example, the two examples below are equivalent:
-{% highlight yaml %}
+```yaml
location: byon(name="my loc",hosts="1.2.3.4",user="bob",privateKeyFile="~/.ssh/bob_id_rsa")
-{% endhighlight %}
+```
-{% highlight yaml %}
+```yaml
location:
byon:
name: "my loc"
@@ -60,7 +53,7 @@ location:
- "1.2.3.4"
user: "bob"
privateKeyFile: "~/.ssh/bob_id_rsa"
-{% endhighlight %}
+```
### Specific Locations for Specific Entities
@@ -71,9 +64,7 @@ well as, defining the location at the top-level of the blueprint).
The example below will deploy Tomcat and JBoss App Server to different Bring Your Own Nodes
locations:
-{% highlight yaml %}
-{% readj example_yaml/simple-appserver-with-location-per-entity.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/simple-appserver-with-location-per-entity.yaml"
The rules for precedence when defining a location for an entity are:
@@ -95,9 +86,7 @@ In the example below, it will create a cluster of app-servers in each location.
used for each `DynamicCluster`; all app-servers inside that cluster will obtain a machine from
that given location.
-{% highlight yaml %}
-{% readj example_yaml/fabric-with-multiple-locations.yaml %}
-{% endhighlight %}
+!CODEFILE "example_yaml/fabric-with-multiple-locations.yaml"
The entity hierarchy at runtime will have a `DynamicFabric` with two children, each of type
`DynamicCluster` (each running in different locations), each of which initially has three
@@ -113,14 +102,14 @@ The examples above have given all the location details within the application bl
It is also possible (and indeed preferred) to add the location definitions to the catalog
so that they can be referenced by name in any blueprint.
-For more information see the [Operations: Catalog]({{ site.path.guide }}/blueprints/catalog/) section of
+For more information see the [Operations: Catalog]({{ book.path.guide }}/blueprints/catalog/) section of
the User Guide.
### Externalized Configuration
For simplicity, the examples above have included the cloud credentials. For a production system,
-it is strongly recommended to use [Externalized Configuration]({{ site.path.guide }}/ops/externalized-configuration.html)
+it is strongly recommended to use [Externalized Configuration]({{ book.path.guide }}/ops/externalized-configuration.html)
to retrieve the credentials from a secure credentials store, such as [Vault](https://www.vaultproject.io).
@@ -128,5 +117,5 @@ to retrieve the credentials from a secure credentials store, such as [Vault](htt
An entity that represents a "software process" can use the configuration option
`provisioning.properties` to augment the location's configuration. For more information, see
-[Entity Configuration]({{ site.path.guide }}/blueprints/entity-configuration.html#entity-provisioningproperties-overriding-and-merging)
+[Entity Configuration]({{ book.path.guide }}/blueprints/entity-configuration.html#entity-provisioningproperties-overriding-and-merging)
details.
http://git-wip-us.apache.org/repos/asf/brooklyn-docs/blob/18c248c5/guide/blueprints/test/index.md
----------------------------------------------------------------------
diff --git a/guide/blueprints/test/index.md b/guide/blueprints/test/index.md
index 8b10f01..06862c4 100644
--- a/guide/blueprints/test/index.md
+++ b/guide/blueprints/test/index.md
@@ -30,4 +30,4 @@ TargetableTestComponents can be chained together, with the target being inherite
The following sections provide details on each test entity along with examples of their use.
-{% include list-children.html %}
+