cleanup

rosemarymarano · rosemarymarano · commit 37cc9c78ebb9 · 2021-04-29T19:07:50.000-04:00
diff --git a/documentation/1.9/content/concepts/model.md b/documentation/1.9/content/concepts/model.md
@@ -5,6 +5,18 @@ draft: false
 weight: 1
 ---
 
+### Contents
+
+- [Overview](#overview)
+- [Top-Level Sections](#top-level-model-sections)
+- [Simple Example](#simple-example)
+- [Model Names](#model-names)
+- [Model Tokens](#model-tokens)
+- [Model Semantics](#model-semantics)
+- [Declaring Named MBeans to Delete](#declaring-named-mbeans-to-delete)
+- [Using Multiple Models](#using-multiple-models)
+
+### Overview
 
 The metadata model (or model, for short) is a version-independent description of a WebLogic Server domain configuration.  The tools are designed to support a sparse model so that the model need only describe what is required for the specific operation without describing other artifacts.  For example, to deploy an application that depends on a JDBC data source into an existing domain that may contain other applications or data sources, the model needs to describe only the application and the data source in question.  If the data source was previously created, the `deployApps` tool will not try to recreate it but may update part of that data source's configuration if the model description is different than the existing values.  If the application was previously deployed, the `deployApps` tool will compare the binaries to determine if the application needs to be redeployed or not.
 
@@ -31,15 +43,6 @@ 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.
 
-### Contents
-
-- [Top-Level Sections](#top-level-model-sections)
-- [Simple Example](#simple-example)
-- [Model Names](#model-names)
-- [Model Tokens](#model-tokens)
-- [Model Semantics](#model-semantics)
-- [Declaring Named MBeans to Delete](#declaring-named-mbeans-to-delete)
-- [Using Multiple Models](#using-multiple-models)
 
 ### Top-Level Model Sections
 The tooling has five top-level model sections:
diff --git a/documentation/1.9/content/concepts/target_env.md b/documentation/1.9/content/concepts/target_env.md
@@ -32,7 +32,7 @@ $WLSDEPLOY_HOME/lib/target/<target-name>/target.json
 ```
 The `<target-name>` value corresponds to the value of the `-target` argument on the tool's command line. The WLS installation includes two pre-defined targets:
  - [Weblogic Kubernetes Operator](#the-weblogic-kubernetes-operator-target) (named `k8s`)
- - [Verrazzano](#the-verrazzano-target) (named `vz`).
+ - [Verrazzano](#the-verrazzano-target) (named `vz`)
 
 You can define a new or extended target environment with a new `target-name` in the above location, or using a [Custom Configuration]({{< relref "/concepts/tool_configuration#custom-configuration" >}}) directory, such as `$WDT_CUSTOM_CONFIG/target/<my-target-name>/target.json`.
 
diff --git a/documentation/1.9/content/concepts/use_cases.md b/documentation/1.9/content/concepts/use_cases.md
@@ -326,7 +326,8 @@ weight: 3
  ```
  #### Trust Service Identity Asserter
 
- **NOTE:** The Trust Identity Asserter Security Provider is installed by JRF in 12c versions and newer.
+{{% notice note %}} The Trust Identity Asserter Security Provider is installed by JRF in 12c versions and newer.
+{{% /notice %}}
 
  The JRF installed Trust Identity Asserter does not supply a schema file by default.  Before you can configure this asserter with WLST offline or WDT offline, you must first build the schema file using the `prepareCustomProvider` script.
 
@@ -343,7 +344,8 @@ weight: 3
 
  #### Custom Security Providers
 
- **NOTE:** Creating and updating domains with custom security providers is limited to WebLogic version 12.1.2 and newer.
+{{% notice note %}} Creating and updating domains with custom security providers is limited to WebLogic version 12.1.2 and newer.
+{{% /notice %}}
 
  Prior to using this tooling to create or update a domain with a custom security provider, there are several prerequisites.  First, WebLogic Server requires the custom MBean JAR to be in the Oracle Home directory before it can be configured, `WLSERVER/server/lib/mbeantypes`.  Second, WebLogic Scripting Tool, WLST, requires that the schema JAR be placed in the Oracle Home directory before WLST offline can be used to discover it or configure it, `ORACLEHOME/oracle_common/lib/schematypes`.  Generating an MBean JAR documentation can be found in the WebLogic Server [documentation](https://docs.oracle.com/en/middleware/standalone/weblogic-server/14.1.1.0/devsp/generate_mbeantype.html).  Generating the schema JAR can be done with the `prepareCustomProvider` script provided in the WebLogic Server installation.
 
@@ -366,10 +368,10 @@ weight: 3
 
 
  ### Modeling WebLogic Users, Groups, and Roles
- WebLogic Server has the ability to establish a set of users, groups, and global roles as part of the WebLogic domain creation. The WebLogic global roles become part of the WebLogic role mapper (i.e. `XACMLRoleMapper`) and are specified under `domainInfo` in the `WLSRoles` section. The users and groups become part of the Embedded LDAP server (i.e. `DefaultAuthenticator`) and are specified under `topology` in the `Security` section.
+ WebLogic Server has the ability to establish a set of users, groups, and global roles as part of the WebLogic domain creation. The WebLogic global roles become part of the WebLogic role mapper (for example, `XACMLRoleMapper`) and are specified under `domainInfo` in the `WLSRoles` section. The users and groups become part of the Embedded LDAP server (for example, `DefaultAuthenticator`) and are specified under `topology` in the `Security` section.
 
  #### WebLogic Global Roles
- The model allows for the definition of WebLogic roles that can augment the well known WebLogic global roles (e.g. `Admin`, `Deployer`, `Monitor`, ...) in addition to defining new roles. When updating the well known WebLogic roles, an `UpdateMode` can be specified as `{ append | prepend | replace }` with the default being `replace` when not specified. Also, when updating the well known roles, the specified `Expression` will be a logical `OR` with the default expression. The `Expression` value for the role is the same as when using the WebLogic `RoleEditorMBean` for a WebLogic security role mapping provider.
+ The model allows for the definition of WebLogic roles that can augment the well known WebLogic global roles (for example, `Admin`, `Deployer`, `Monitor`, ...) in addition to defining new roles. When updating the well known WebLogic roles, an `UpdateMode` can be specified as `{ append | prepend | replace }` with the default being `replace` when not specified. Also, when updating the well known roles, the specified `Expression` will be a logical `OR` with the default expression. The `Expression` value for the role is the same as when using the WebLogic `RoleEditorMBean` for a WebLogic security role mapping provider.
 
  For example, the `WLSRoles` section below updates the well known `Admin`, `Deployer` and `Monitor` roles while adding a new global role with `Tester` as the role name:
 
@@ -394,7 +396,7 @@ weight: 3
  In addition, the `Expression` value can use the variable placeholder syntax specified when running the [Create Tool]({{< relref "/userguide/tools/create.md" >}}) as shown in the above example.
 
  #### WebLogic Users and Groups
- The model allows for the definition of a set of users and groups that will be loaded into the WebLogic Embedded LDAP Server (i.e. `DefaultAuthenticator`). New groups can be specified and users can be added as members of the new groups or existing groups such as the `Administrators` group which is defaulted to be in the WebLogic `Admin` global role. Please see Known Limitations below for additional information on users and groups.
+ The model allows for the definition of a set of users and groups that will be loaded into the WebLogic Embedded LDAP Server (for example, `DefaultAuthenticator`). New groups can be specified and users can be added as members of the new groups or existing groups such as the `Administrators` group which is defaulted to be in the WebLogic `Admin` global role. Please see Known Limitations below for additional information on users and groups.
 
  The user password can be specified with a placeholder or encrypted with the [Encrypt Tool](encrypt.md). An example `Security` section that adds an additional group `AppMonitors`, adds two new users and places the users into groups is as follows:
 
@@ -415,9 +417,9 @@ weight: 3
 
  #### Known Limitations
 
- - The processing of users, groups, and roles will only take place when using the [Create Domain Tool]({{< relref "/userguide/tools/create.md" >}})
- - WebLogic global roles are only supported with WebLogic Server version 12.2.1 or greater
- - WebLogic global roles are only updated for the WebLogic security XACML role mapping provider (i.e. `XACMLRoleMapper`)
+ - The processing of users, groups, and roles will only take place when using the [Create Domain Tool]({{< relref "/userguide/tools/create.md" >}}).
+ - WebLogic global roles are only supported with WebLogic Server version 12.2.1 or greater.
+ - WebLogic global roles are only updated for the WebLogic security XACML role mapping provider (for example, `XACMLRoleMapper`).
  - The user and group processing is not complete, currently, users cannot be assigned to groups. Users created using the `Security` section are automatically added to the `Administrators` group and are not added to the groups specified. See [Known Issues]({{< relref "/release-notes#assigning-security-groups-to-users" >}}) for information about a patch for this issue.
 
  ### Modeling WebLogic User Password Credential Mapping
diff --git a/documentation/1.9/content/developer/buildWDT.md b/documentation/1.9/content/developer/buildWDT.md
@@ -19,7 +19,7 @@ Execution of the unit tests requires a WebLogic Server installation, because the
 
 The WLST directory can be specified in one of two ways:
 
-- Specify the `-Dunit-test-wlst-dir=<wlst-directory>` on the mvn command line.
+- Specify the `-Dunit-test-wlst-dir=<wlst-directory>` on the `mvn` command line.
 
 - Create a file `.mvn/maven.config` file in the project directory, containing a single line with the `-Dunit-test-wlst-dir=<wlst-directory>` value. The `.mvn` directory contains a `maven.config-template` file that can be copied and used as a starting point.
 
diff --git a/documentation/1.9/content/userguide/install.md b/documentation/1.9/content/userguide/install.md
@@ -19,7 +19,8 @@ The following table specifies the supported WebLogic Server versions, along with
 
  To create a domain with the proper JDK (particularly if the `JAVA_HOME` is different from the one which will be used by the target domain), set the domain `JavaHome` attribute in the domain model.
 
- **Note**: The WDT Encryption Model Tool used to encrypt and decrypt clear text passwords in the model and variable files, requires WDT to run with a minimum JDK version of 1.8.
+{{% notice note %}} The WDT Encryption Model Tool used to encrypt and decrypt clear text passwords in the model and variable files, requires WDT to run with a minimum JDK version of 1.8.
+{{% /notice %}}
 
   | WebLogic Server Version | Tool JDK Version |
   |--------------------------|-------------------|
diff --git a/documentation/1.9/content/userguide/tools/compare.md b/documentation/1.9/content/userguide/tools/compare.md
@@ -14,7 +14,7 @@ To use the Compare Model Tool, simply run the `compareModel` shell script with t
 
 For example, comparing the following models.  
 
-##### New Model
+#### New Model
 
 ```yaml
 domainInfo:
@@ -108,7 +108,7 @@ resources:
                         JNDIName: jms/myUDQ
 ```
 
-##### Old Model
+#### Old Model
 
 ```yaml
 domainInfo:
diff --git a/documentation/1.9/content/userguide/tools/create.md b/documentation/1.9/content/userguide/tools/create.md
@@ -3,7 +3,7 @@ title: "Create Domain Tool"
 date: 2019-02-23T17:19:24-05:00
 draft: false
 weight: 1
-description: "Understands how to create a domain and populate the domain with all resources and applications specified in the model."
+description: "Creates a domain and populates the domain with all the resources and applications specified in the model."
 ---
 
 
diff --git a/documentation/1.9/content/userguide/tools/deploy.md b/documentation/1.9/content/userguide/tools/deploy.md
@@ -3,7 +3,7 @@ title: "Deploy Applications Tool"
 date: 2019-02-23T17:19:24-05:00
 draft: false
 weight: 3
-description: "Understands how to add resources and applications to an existing domain, either in offline or online mode."
+description: "Adds resources and applications to an existing domain, either in offline or online mode."
 ---
 
 
diff --git a/documentation/1.9/content/userguide/tools/discover.md b/documentation/1.9/content/userguide/tools/discover.md
@@ -41,7 +41,7 @@ An example of using the domain type argument:
 
     weblogic-deploy\bin\discoverDomain.cmd -oracle_home c:\wls12213 -domain_home domains\DemoDomain -archive_file DiscoveredDemoDomain.zip -model_file DiscoveredDemoDomain.yaml -domain_type RestrictedJRF
 
-Before the model is persisted to the model file, any variable injectors or model filters are run, in that order. The final step is validation, which validates the contents of the model, archive and variable file. If the validation is successful, the model is persisted. For more information on these three topics, go to:
+Before the model is persisted to the model file, any variable injectors or model filters are run, in that order. The final step is validation, which validates the contents of the model, archive and variable file. If the validation is successful, the model is persisted. For more information on these three topics, see:
 
  - [Variable Injection]({{< relref "/userguide/tools/variable_injection.md" >}})
  - [Model Filters]({{< relref "/concepts/tool_configuration#model-filters" >}})
@@ -68,10 +68,10 @@ Total:       WARNING :     1    SEVERE :     0
 ### Environmental Variables
 The following environment variables may be set.
 
--  JAVA_HOME             The location of the JDK. This must be a valid Java 7 or later JDK.
--  WLSDEPLOY_HOME        The location of the WebLogic Deploy Tooling installation. By default, the location is calculated
+-  `JAVA_HOME`             The location of the JDK. This must be a valid Java 7 or later JDK.
+-  `WLSDEPLOY_HOME`        The location of the WebLogic Deploy Tooling installation. By default, the location is calculated
                          from the location of the discoverDomain script.
--  WLSDEPLOY_PROPERTIES  System properties that will be passed to WLST.
+-  `WLSDEPLOY_PROPERTIES`  System properties that will be passed to WLST.
 
 ### Opening an Issue against Discover Domain
 
diff --git a/documentation/1.9/content/userguide/tools/encrypt.md b/documentation/1.9/content/userguide/tools/encrypt.md
@@ -7,7 +7,8 @@ description: "Encrypts the passwords in a model (or its variable file) using a u
 ---
 
 
-**NOTE: To meet Oracle's security standards, the encryption algorithms require JDK 8 to execute.**
+{{% notice note %}} To meet Oracle's security standards, the encryption algorithms require JDK 8 to execute.
+{{% /notice %}}
 
 Models contain WebLogic Server domain configuration.  Certain types of resources and other configurations require passwords; for example, a JDBC data source requires the password for the user establishing the database connection.  When creating or configuring a resource that requires a password, that password must be specified either in the model directly or in the variable file.  Clear-text passwords are not conducive to storing configurations as source, so the Encrypt Model Tool gives the model author the ability to encrypt the passwords in the model and variable file using passphrase-based, reversible encryption.  When using a tool with a model containing encrypted passwords, the encryption passphrase must be provided, so that the tool can decrypt the password in memory to set the necessary WebLogic Server configuration (which supports its own encryption mechanism based on a domain-specific key).  While there is no requirement to use the WebLogic Deploy Tooling encryption mechanism, it is highly recommended because storing clear text passwords on disk is never a good idea.
 
diff --git a/documentation/1.9/content/userguide/tools/kubernetes.md b/documentation/1.9/content/userguide/tools/kubernetes.md
@@ -3,7 +3,7 @@ title: "Extract Domain Resource Tool"
 date: 2019-02-23T17:19:24-05:00
 draft: false
 weight: 9
-description: "Generates a domain resource YAML for use with the WebLogic Kubernetes Operator."
+description: "Generates a domain resource YAML file for use with the WebLogic Kubernetes Operator."
 ---
 
 
@@ -15,7 +15,8 @@ This is especially useful when making configuration changes to the domain that a
 
 More information about the WebLogic Kubernetes Operator can be found [here](https://oracle.github.io/weblogic-kubernetes-operator).
 
-**NOTE**: The Extract Domain Resource Tool is available with WDT releases 1.7.0 and later.
+{{% notice note %}} The Extract Domain Resource Tool is available with WDT releases 1.7.0 and later.
+{{% /notice %}}
 
 Here is an example command line for the Extract Domain Resource Tool:
 ```
diff --git a/documentation/1.9/content/userguide/tools/prepare.md b/documentation/1.9/content/userguide/tools/prepare.md
@@ -18,7 +18,7 @@ The Prepare Model Tool prepares WDT model files for deploying to specific target
 
 To use the Prepare Model Tool, simply run the `prepareModel` shell script with the correct arguments.  To see the list of valid arguments, simply run the shell script with the `-help` option (or with no arguments) for usage information.
 
-For example, to prepare model files for use with Oracle Weblogic Server Kubernetes Operator, run the tool with `-target wko` as follows:
+For example, to prepare model files for use with WebLogic Kubernetes Operator, run the tool with `-target wko` as follows:
 ```
 $WLSDEPLOY_HOME/bin/prepareModel.sh -oracle_home /u01/wls12213 -model_file model1.yaml, model2.yaml -target wko -output_dir $HOME/wko-output
 ```
diff --git a/documentation/1.9/content/userguide/tools/update.md b/documentation/1.9/content/userguide/tools/update.md
@@ -3,7 +3,7 @@ title: "Update Domain Tool"
 date: 2019-02-23T17:19:24-05:00
 draft: false
 weight: 2
-description: "Understands how to update an existing domain and populate the domain with all resources and applications specified in the model, either in offline or online mode."
+description: "Updates an existing domain and populates the domain with all the resources and applications specified in the model, either in offline or online mode."
 ---
 
 
diff --git a/documentation/1.9/content/userguide/tools/variable_injection.md b/documentation/1.9/content/userguide/tools/variable_injection.md
@@ -15,7 +15,8 @@ Another option is to configure variable injection in a [Custom Configuration]({{
 
 A keyword points to an injector directive file. The tool applies the directives to the attributes in a model, and if the directive matches an attribute, then a property token with a unique variable name is injected into the model and replaces the attribute value. The variable name and model attribute value are placed into the external variable properties file.
 
-**NOTE**: Variable injection on an attribute is only performed once. The property token is not replaced by any subsequent matches.
+{{% notice note %}} Variable injection on an attribute is only performed once. The property token is not replaced by any subsequent matches.
+{{% /notice %}}
 
 If variable injection is enabled, the Discover Domain Tool calls the variable injector after the model has been discovered and after all filters run, but before model validation.
 
@@ -29,7 +30,8 @@ The supported keywords are as follows:
    This includes server, machine and Node Manager ports, credentials and listen addresses, and cluster messaging modes, addresses and ports.
 - `URL` - All MBean URL attribute values in the model are injected with a variable.
 
-**NOTE**: The directives used by each pre-defined keyword are defined in an injector JSON file that is located in the `<WLSDEPLOY>/lib/injectors` folder. These files should not be changed, but could be used as is.
+{{% notice note %}} The directives used by each pre-defined keyword are defined in an injector JSON file that is located in the `<WLSDEPLOY>/lib/injectors` folder. These files should not be changed, but could be used as is.
+{{% /notice %}}
 
 Here is an example of a `model_variable_injector.json` file using the PORT keyword.
 
