Merge branch 'master' into janan07/apply-security-config-reorg-to-2.18

docs/extend/extend-desktop/mvd-logutility.md

@@ -2,22 +2,6 @@
 
 The `zlux-shared` repository provides a logging utility for use by dataservices and web content for an application plug-in.
 
-1. [Logging Objects](#logging-objects)
-1. [Logger IDs](#logger-ids)
-1. [Accessing Logger Objects](#accessing-logger-objects)
-    1. [Logger](#logger)
-        1. [App Server](#app-server)
-        1. [Web](#web)
-    1. [Component Logger](#component-logger)
-        1. [App Server](#app-server-1)
-1. [Logger API](#logger-api)
-1. [Component Logger API](#component-logger-api)
-1. [Log Levels](#log-levels)
-1. [Logging Verbosity](#logging-verbosity)
-    1. [Configuring Logging Verbosity](#configuring-logging-verbosity)
-        1. [Server Startup Logging Configuration](#server-startup-logging-configuration)
-1. [Using log message IDs](#using-log-message-ids)
-
 
 ## Logging objects
 
@@ -57,7 +41,6 @@ Component loggers are created from the core logger object, but when working with
 
 See **Router Dataservice Context** in the topic [Dataservices](mvd-dataservices.md).   
 
-
 ## Logger API
 
 The following constants and functions are available on the central logging object.
@@ -105,8 +88,11 @@ An enum, `LogLevel`, exists for specifying the verbosity level of a logger. The
 | FINER | 4
 | TRACE | 5
 
-**Note:** The default log level for a logger is **INFO**.
+:::note
 
+The default log level for a logger is **INFO**.
+
+:::
 
 ## Logging verbosity
 
@@ -123,9 +109,10 @@ The application plug-in framework provides ways to specify what component logger
 
 #### Server startup logging configuration
 
-[The server configuration file](https://github.com/zowe/zlux/wiki/Configuration-for-zLUX-App-Server-&-ZSS) allows for specification of default log levels, as a top-level attribute `logLevel`, which takes key-value pairs where the key is a regex pattern for component IDs, and the value is an integer for the log levels.
+[The server configuration file](mvd-server-config.md) allows for specification of default log levels, as a top-level attribute `logLevel`, which takes key-value pairs where the key is a regex pattern for component IDs, and the value is an integer for the log levels.
 
 For example:
+
 ```  
 "logLevel": {
     "com.rs.configjs.data.access": 2,
@@ -138,9 +125,11 @@ For example:
     //"_unp.dsauth": 2
   },
 ```
+
 For more information about the server configuration file, see [Zowe Application Framework (zLUX) configuration](../../user-guide/mvd-configuration#configuration-file).
 
 ## Using log message IDs
+
 To make technical support for your application easier, create IDs for common log messages and use substitution to generate them. When you use IDs, people fielding support calls can identify and solve problems more quickly. IDs are particularly helpful if your application is translated, because it avoids users having to explain problems using language that the tech support person might not understand.
 
 To use log message IDs, take the following steps:
@@ -178,7 +167,7 @@ To use log message IDs, take the following steps:
    ```
    DATE TIME:TIME:TIME.TIME <ZWED:> username INFO (org.zowe.app.name,:) A001 - Приложение создано.
    ```
-   
+
 ### Message ID logging examples
 
 Server core: https://github.com/zowe/zlux-server-framework/blob/v2.x/master/plugins/config/lib/assets/i18n/log/messages_en.json

docs/extend/extend-desktop/mvd-server-config.md

@@ -1,19 +1,25 @@
 # Advanced Server Configuration
 
 The Zowe's App Server and ZSS rely on many required or optional parameters to run, which includes setting up networking, deployment directories, plugin locations, and more. 
-These parameters can be specified in two ways: configuration files, or environment variables.
-
-Every configuration option and requirement is documented within the application framework [json-schema file](https://github.com/zowe/zlux-app-server/blob/v3.x/staging/schemas/app-server-config.json)
 
 ## Configuration file
 
-In Zowe's server configuration file, app-server parameters can be specified within `components.app-server` as shown in the component [json-schema file](https://github.com/zowe/zlux-app-server/blob/v3.x/staging/schemas/zowe-schema.json), or `components.zss` for ZSS.
+The servers use a YAML file for configuration. The [global schema](https://github.com/zowe/zowe-install-packaging/blob/v2.x/staging/schemas/zowe-yaml-schema.json) describes the parts of configuration that are common between servers.
+
+The App Server specifically is configured by the `components.app-server` section of the YAML, and that section follows [this App-server schema](https://github.com/zowe/zlux-app-server/blob/v2.x/staging/schemas/app-server-config.json).
+
+ZSS is instead configured by the `components.zss` section, following [the ZSS schema](https://github.com/zowe/zss/blob/v2.x/staging/schemas/zss-config.json).
+
+The App server can additionally use environment variables to override the YAML file.
 
-## Environment variables
+## Environment variables (app-server only)
 
+CLI arguments take precedence over the configuration file, but are overridden by the CLI arguments.
 The format is `ZWED_key=value`, where `ZWED_` is a prefix for any configuration object.
 
-The key maps to a YAML object attribute, so to set the value of a nested object, such as the https configuration, you need multiple values.
+The attributes specified will be put within the `components.app-server` subsection of the Zowe configuration.
+
+The key maps to a JSON object attribute, so to set the value of a nested object, such as the https configuration, you need multiple values.
 
 For example:
 
@@ -45,29 +51,31 @@ ZWED_logLevels_org____zowe____terminal____tn3270_x2e_x2a:5
 ```
 
 **The key names are syntax sensitive.**
-* They are case-sensitive
-* All ascii characters except " are allowed in the object attribute names.
-    * An encoding scheme is used for many symbols because environment variables can only have names with the characters A-Z, a-z, 0-9, `_`, `.`, and `-`
-    * The scheme is _x followed by 2 hex numbers will be converted to the corresponding ASCII character, such as _x41 mapping to `A`
-* _ is used as the object separator, so an escape sequence is used if `_` is actually needed for the key.
-    * Single leading and trailing _ are treated as literal `_`
-    * __ will be maps to literal `_`
-    * ___ maps to literal `-`
-    * ____ maps to literal `.`
+* They are case-sensitive.
+* All ASCII characters except `"` are allowed in the object attribute names.
+    * An encoding scheme is used for many symbols because environment variables can only have names with the characters `A`-`Z`, `a`-`z`, `0`-`9`, `_`, `.`, and `-`.
+    * The scheme is _x followed by 2 hex numbers will be converted to the corresponding ASCII character, such as _x41 mapping to `A`.
+* `_` is used as the object separator, so an escape sequence is used if `_` is actually needed for the key.
+    * Single leading and trailing _ are treated as literal `_`.
+    * `__` will be maps to literal `_`
+    * `___` maps to literal `-`
+    * `____` maps to literal `.`
 
 **The types of the values are syntax-sensitive.**
 * Numbers are treated as numbers, not strings. 
-* false & true are treated as boolean.
-* commas are for arrays. An array of length 1 has a comma at the end
-* strings can have quotes, but otherwise everything that isnt an array, boolean, or number is a string
-* objects are never values. They are the keys.
+* `false` and `true` are treated as boolean.
+* Commas are for arrays. An array of length 1 has a comma at the end.
+* Strings can have quotes, but otherwise everything that is not an array, boolean, or number is a string.
+* Objects are never values, they are the keys.
+
 
 ## Parameter details
 Below is some more detail on certain parameters than can be covered within the json-schema.
 
 ### Configuration directories
 
 When running, the App Server will access the server's settings and read/modify the contents of its resource storage.
+
 All of this data is stored within a hierarchy of a few folders, which is correspond to scopes:
 - Product: The contents of this folder are not meant to be modified, but used as defaults for a product.
 - Site: The contents of this folder are intended to be shared across multiple App Server instances, perhaps on a network drive.
@@ -85,12 +93,12 @@ These directories dictate where the [Configuration Dataservice](https://github.c
   "instanceDir":"/home/myuser/.zowe/workspace/app-server",
   "groupsDir":"/home/myuser/.zowe/workspace/app-server/groups",
   "usersDir":"/home/myuser/.zowe/workspace/app-server/users",
-
 ```
 
 ### App configuration
 
 This section does not cover any dynamic runtime inclusion of Apps, but rather Apps defined in advance.
+
 In the configuration file, a directory can be specified which contains JSON files which tell the server what App is to be included and where to find it on disk. The backend of these Apps use the Server's Plugin structure, so much of the server-side references to Apps use the term Plugin.
 
 To include Apps, be sure to define the location of the Plugins directory in the configuration file, via the top-level attribute *pluginsDir*
@@ -116,18 +124,11 @@ For more information, see [Logging Utility](mvd-logutility.md).
 
 ### ZSS Configuration
 
-When running ZSS, it will require a configuration file similar or the same as the one used for the App Server. The attributes that are needed for ZSS, at minimum, are: *productDir*, *siteDir*, *instanceDir*, *groupsDir*, *usersDir*, *pluginsDir* and **agent**. All of these attributes have the same meaning as described above for the App server, but if the App server and ZSS are not run from the same location, then these directories may be different if desired.
+ZSS is configured by the same Zowe YAML file used by the App server, within the `components.zss` section of the file. The [ZSS schema for components.zss be found here](https://github.com/zowe/zss/blob/v2.x/staging/schemas/zss-config.json). More information about the configuration can be found in its [README file](https://github.com/zowe/zss/#quick-run-how-to-start-zss).
 
-#### ZSS Networking
+#### Connecting ZSS to App Server
 
-The attributes that control ZSS exclusively are within the **agent** object. ZSS uses HTTPS by default, but AT-TLS can also be used by setting `zowe.network.server.tls.attls` or `components.zss.zowe.network.server.tls.attls` to `true`.  The value `agent.https.port` tells ZSS which ports to bind to and where the app-server can find ZSS. The values `agent.host` is used to tell app-server where to find ZSS as well, though `zowe.network.server.listenAddresses` or `components.zss.zowe.network.server.listenAddresses` tell ZSS which addresses to bind to. For addresses, at this time only the first value of that array is used, and it may either be a hostname or an ipv4 address.
+The App Server can connect to ZSS either directly or through the API Mediation Layer Gateway when that is running.
 
-Example of the agent body:
+The connection information is stored within the object `components.app-server.agent`, which describes whether the Gateway is involved, or if not, on which host and port can ZSS be found. For more information, see the [agent section of the schema](https://github.com/zowe/zlux-app-server/blob/c22105381e129bd999c47e838b424679eba26aa6/schemas/app-server-config.json#L262)
 
-```
-  agent: 
-    host: localhost
-    https: 
-      port: 7557
-    
-```

sidebars.js

@@ -805,6 +805,7 @@ module.exports = {
           type: "category",
           label: "Developing for Zowe Application Framework",
           items: [
+            "extend/extend-desktop/mvd-server-config",
             "extend/extend-desktop/mvd-extendingzlux",
             "extend/extend-desktop/mvd-plugindefandstruct",
             "extend/extend-desktop/mvd-buildingplugins",