Merge pull request #248 from oracle/rmarano

review and edits

Author: ddsharpe

README.md

@@ -72,11 +72,11 @@ The model is written in YAML (or optionally, JSON).  The YAML parser, built into
 All assignment statements must have one or more spaces between the colon and the value.  All comments must have a space after the pound sign (also known as hash) to be considered a comment.  YAML doesn't allow comments in all locations.  While the YAML parser used by the framework does not try to enforce these restrictions, it is likely that putting comments in some locations may cause parse errors since YAML is a difficult language to parse due to its complex indention rules.
 
 ##### Top-Level Model Sections
-The tooling has 4 top-level model sections:
+The tooling has four top-level model sections:
 
 - `domainInfo`     - The location where special information not represented in WLST is specified (for example, the libraries that go in `$DOMAIN_HOME/lib`).
 - `topology`       - The location where servers, clusters, machines, server templates, and other domain-level configuration is specified.
-- `resources`      - The location where resources and services are specified (for example, data sources, JMS, WLDF)
+- `resources`      - The location where resources and services are specified (for example, data sources, JMS, WLDF).
 - `appDeployments` - The location where shared libraries and applications are specified.
 
 ##### Simple Example
@@ -180,7 +180,7 @@ As the example above shows, the `SecurityConfiguration` element has no named sub
 
 When modeling configuration attributes that can have multiple values, the WebLogic Deploy Tooling tries to make this as painless as possible.  For example, the `Target` attribute on resources can have zero or more clusters and/or servers specified.  When specifying the value of such list attributes, the user has freedom to specify them as a list or as a comma-delimited string (comma is the only recognized delimiter for lists).  For attributes where the values can legally contain commas, the items must be specified as a list.  Examples of each are shown below.
 
-```$yaml
+```yaml
 resources:
     JDBCSystemResource:
         MyStringDataSource:
@@ -217,7 +217,7 @@ One of the primary goals of the WebLogic Deploy Tooling is to support a sparse m
 #### Modeling Security Providers
 One place where the semantics are different is for WebLogic security providers.  Because provider ordering is important, and to make sure that the ordering is correctly set in the newly created domain, the Create Domain Tool will look for security providers of each base type (for example, Authentication Providers, Credential Mappers, and such) to see if any are included in the model.  If so, the tool will make sure that  the providers only listed for a type are present in the resulting domain so that the providers are created in the necessary order.  For example, if the model specified an `LDAPAuthenticator` and an `LDAPX509IdentityAsserter` similar to what is shown below, the `DefaultAuthenticator` and `DefaultIdentityAsserters` will be deleted.  If no providers for a base type are listed in the model, then the default providers will be left untouched.
 
-```$yaml
+```yaml
 topology:
     SecurityConfiguration:
         Realm:
@@ -259,7 +259,7 @@ topology:
 
 To keep the `DefaultAuthenticator` and `DefaultIdentityAsserter`, simply add the default names and types in the correct positions in the model's `AuthenticationProvider` list.  If desired, settings on the default providers can be changed, as shown below.
 
-```$yaml
+```yaml
 topology:
     SecurityConfiguration:
         Realm:

site/create.md

@@ -131,7 +131,7 @@ To create more complex domains with clusters of different types, it is necessary
 
 Then, use the `ServerGroupTargetingLimits` map in the `domainInfo` section to limit the targeting of the Web Services Manager, SOA, and OSB server groups to the `soa_cluster` or `osb_cluster`, as appropriate.  In the example below, notice that the `JRF-MAN-SVR` server group is not listed; therefore, it will use the default targeting and be targeted to all managed servers.  The value of each element in this section is a logical list of server and/or cluster names.  As shown in the example, the value for each server group can be specified as a list, a comma-separated string, or a single-valued string.  There is no semantic difference between listing a cluster's member server names versus using the cluster name; the example uses these simply to show what is possible.
 
-```$yaml
+```yaml
 domainInfo:
     AdminUserName: weblogic
     AdminPassword: welcome1

site/discover.md

@@ -9,5 +9,4 @@ To run the Discover Domain Tool, simply provide the domain location and the name
 When creating the archive, the tool will try to gather all binaries, scripts, and required directories referenced by the domain configuration with the following caveats.
 
 1. Any binaries referenced from the `ORACLE_HOME` will not be gathered, as they are assumed to exist in any target domain to which model-driven operations will be applied.  Doing this is key to allowing the model to be WebLogic Server version independent.
-2. In its current form, the discover domain Tool will only gather binaries and scripts that are accessible from the local machine.  Warnings will be generated for any binaries or scripts that cannot be found but the configuration for those binaries will still be collected, where possible.  It is the user's responsibility to add those missing files to the archive in the appropriate locations and edit the the model, as needed, to point to those files inside the archive using the relative path inside the archive (for example, `wlsdeploy/applications/myapp.ear`).
-
+2. In its current form, the Discover Domain Tool will only gather binaries and scripts that are accessible from the local machine.  Warnings will be generated for any binaries or scripts that cannot be found but the configuration for those binaries will still be collected, where possible.  It is the user's responsibility to add those missing files to the archive in the appropriate locations and edit the the model, as needed, to point to those files inside the archive using the relative path inside the archive (for example, `wlsdeploy/applications/myapp.ear`).

site/tool_filters.md

@@ -2,9 +2,9 @@
 
 WebLogic Deploy Tooling supports the use of model filters to manipulate the domain model. The Create Domain, Update Domain, and Deploy Applications Tools apply filters to the model after it is read, before it is validated and applied to the domain. The Discover Domain Tool applies filters to the model after it has been discovered, before the model is validated and written.
 
-Model filters are written in Jython, and must be compatible with the version used in the corresponding version of WLST. A filter must implement the method filter_model(model), which accepts as a single argument the domain model as a Jython dictionary. This method can make any adjustments to the domain model that are required. Filters can be stored in any directory, as long as they can be accessed by WebLogic Deploy Tooling.
- 
-The following filter example (fix-password.py) sets the password for two attributes in the SecurityConfiguration WLST folder.
+Model filters are written in Jython, and must be compatible with the version used in the corresponding version of WLST. A filter must implement the method `filter_model(model)`, which accepts as a single argument the domain model as a Jython dictionary. This method can make any adjustments to the domain model that are required. Filters can be stored in any directory, as long as they can be accessed by WebLogic Deploy Tooling.
+
+The following filter example (`fix-password.py`) sets the password for two attributes in the `SecurityConfiguration` WLST folder.
 
 ```python
 def filter_model(model):
@@ -17,9 +17,9 @@ def filter_model(model):
 			print 'SecurityConfiguration not in the model'
 ```
 
-Model filters are configured by creating a model_filters.json file in the WLSDEPLOY_HOME/lib directory. This file has separate sections for filters to be applied for specific tools.
- 
-This example configures two filters for the Create Domain Tool: fix-password.py and no-mail.py, and one filter for the Discover Domain tool.
+Model filters are configured by creating a `model_filters.json` file in the `WLSDEPLOY_HOME/lib` directory. This file has separate sections for filters to be applied for specific tools.
+
+This example configures two filters for the Create Domain Tool: `fix-password.py` and `no-mail.py`, and one filter for the Discover Domain tool.
 
 ```json
 {
@@ -36,4 +36,3 @@ This example configures two filters for the Create Domain Tool: fix-password.py
   ]
 }
 ```
-

site/update.md

@@ -1,6 +1,6 @@
 ## The Update Domain Tool
 
-The Update Domain Tool uses a model, the archive, and WLST to update the configuration of an existing WebLogic Server domain, and to deploy applications and resources into the domain in either WLST online or offline mode.  The update tool will add or re-configure elements from the `topology` section of the model, and deploy applications and resources from the `resources` and `appDeployments` sections, as described in the Deploy Applications tool.
+The Update Domain Tool uses a model, the archive, and WLST to update the configuration of an existing WebLogic Server domain, and to deploy applications and resources into the domain in either WLST online or offline mode.  The update tool will add or re-configure elements from the `topology` section of the model, and deploy applications and resources from the `resources` and `appDeployments` sections, as described in the Deploy Applications Tool.
 
 The Update Domain Tool will only add or update elements in the specified model. It will not attempt to remove any missing elements that were present in a previous model.
 
@@ -14,7 +14,7 @@ In WLST online mode, simply add the information on how to connect to the WebLogi
 
 As usual, the tool will prompt for the password (it can also be supplied by piping it to standard input of the tool).
 
-Unlike the Create Domain Tool, the full domain home directory is specified, rather than the domain's parent directory, since the domain has already been established.
+Unlike the Create Domain Tool, the full domain home directory is specified, rather than the domain's parent directory, because the domain has already been established.
 
 The Update Domain Tool will not attempt to recreate or add schemas for the RCU database, for domain types that use RCU.
 
@@ -23,4 +23,3 @@ When running the tool in WLST online mode, the update operation may require serv
 - `101` - The domain needs to be restarted and the Update Domain Tool needs to be re-invoked with the same arguments.
 - `102` - The servers impacted by the update operation need to be restarted, in a rolling fashion, starting with the Administration Server, if applicable.
 - `103` - The entire domain needs to be restarted.
-