Skip to content

Commit 5bce69e

Browse files
rosemarymaranorosemarymarano
committed
rearrange reference topics to user guide
1 parent 835eec2 commit 5bce69e

File tree

11 files changed

+132
-129
lines changed

11 files changed

+132
-129
lines changed

‎documentation/1.9/content/reference/_index.md

Lines changed: 0 additions & 9 deletions
This file was deleted.

‎documentation/1.9/content/samples/ohs-model.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ Starting with WDT 1.8.0, you can configure and update Oracle HTTP Server (OHS) u
1212

1313
In order to configure and use OHS, it must be installed in the Oracle Home directory used to create the domain. You can download OHS [here](https://www.oracle.com/middleware/technologies/webtier-downloads.html).
1414

15-
The OHS template must be present in the WDT domain type definition file used to create or update the domain. For more information on creating a custom definition, see [Domain type definitions]({{< relref "/reference/tool_configuration#domain-type-definitions" >}}).
15+
The OHS template must be present in the WDT domain type definition file used to create or update the domain. For more information on creating a custom definition, see [Domain type definitions]({{< relref "/userguide/tools-config/domain_def.md" >}}).
1616

1717
You create a copy of an existing domain type definition file, add the template to that file, and then reference that file on the WDT command line. For example, if you want to create a domain with Oracle HTTP Server based on a Restricted JRF domain, then you would first create a copy of the file `WLSDEPLOY_HOME/lib/typedefs/RestrictedJRF.json` in the same directory, such as `WLSDEPLOY_HOME/lib/typedefs/HttpServer.json`. In this example, you would change the existing `extensionTemplates` section to include the additional OHS template. The original value is:
1818
```

‎documentation/1.9/content/userguide/target_env.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ weight: 2
99
The [Discover Domain]({{< relref "/userguide/tools/discover.md" >}}) and [Prepare Model]({{< relref "/userguide/tools/prepare.md" >}}) Tools allow you to customize the model and other files produced to be compatible with a specific target environment. Options for a target environment may include:
1010
- Using model tokens for some attributes in the model. See [Model tokens]({{< relref "/concepts/model#model-tokens" >}}).
1111
- Using Kubernetes secrets for credentials in the model.
12-
- Applying filters to the model. See [Model filters]({{< relref "/reference/tool_configuration#model-filters" >}}).
12+
- Applying filters to the model. See [Model filters]({{< relref "/userguide/tools-config/model_filters.md" >}}).
1313
- Creating additional configuration files for the target system.
1414

1515
### Specifying a target environment
@@ -34,7 +34,7 @@ The `<target-name>` value corresponds to the value of the `-target` argument on
3434
- [Weblogic Kubernetes Operator](#the-weblogic-kubernetes-operator-target) (named `k8s`)
3535
- [Verrazzano](#the-verrazzano-target) (named `vz`)
3636

37-
You can define a new or extended target environment with a new `target-name` in the above location, or using a [Custom configuration]({{< relref "/reference/tool_configuration#custom-configuration" >}}) directory, such as `$WDT_CUSTOM_CONFIG/target/<my-target-name>/target.json`.
37+
You can define a new or extended target environment with a new `target-name` in the above location, or using a [Custom configuration]({{< relref "/userguide/tools-config/custom_config.md" >}}) directory, such as `$WDT_CUSTOM_CONFIG/target/<my-target-name>/target.json`.
3838

3939
Here is an example of a target environment file:
4040
```
@@ -55,7 +55,7 @@ Each of the fields in this example is optional, and can be customized.
5555

5656
#### `model_filters`
5757

58-
This field specifies the filters to be applied to the resulting model. This follows the same format and rules as the [Model filters]({{< relref "/reference/tool_configuration#model-filters" >}}) configuration. The `discover` type should always be used here.
58+
This field specifies the filters to be applied to the resulting model. This follows the same format and rules as the [Model filters]({{< relref "/userguide/tools-config/model_filters.md" >}}) configuration. The `discover` type should always be used here.
5959

6060
The `@@TARGET_CONFIG_DIR@@` token can be used to indicate that the specified filter is in the same directory as the target configuration file.
6161

‎documentation/1.9/content/userguide/tools-config/_index.md

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
+++
2+
title = "Tools configuration"
3+
date = 2019-02-22T15:27:54-05:00
4+
weight = 3
5+
+++

‎documentation/1.9/content/userguide/tools-config/custom_config.md

Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
1+
---
2+
title: "Custom configuration"
3+
date: 2019-02-23T17:19:24-05:00
4+
draft: false
5+
weight: 3
6+
---
7+
8+
9+
WDT allows you to create or extend the pre-installed type definitions, model filters, variable injectors, and target environments. Starting with WDT 1.10.0, these additional configuration files can be stored outside the `$WLSDEPLOY_HOME/lib` directory. This allows the files to remain in place if the WDT installation is moved or upgraded to a new version.
10+
11+
To use a separate configuration directory, set the `WDT_CUSTOM_CONFIG` environment variable to the directory to be used for configuration. For example:
12+
```
13+
export WDT_CUSTOM_CONFIG=/etc/wdtconfig
14+
```
15+
16+
The customized configuration files should be named and organized the same way they would be under the `$WLSDEPLOY_HOME/lib` directory. For example:
17+
```
18+
/etc/wdtconfig
19+
injectors
20+
*.json (injector files)
21+
typedefs
22+
*.json (typedef files)
23+
targets
24+
my-target
25+
target.json
26+
*.py (filter files)
27+
model_filters.json
28+
model_variable_injector.json
29+
variable_keywords.json
30+
```
31+
This is a full set of files that can be configured. You will need only to add the files you have created or extended. Details for each configuration type are found at:
32+
- [Tool property file]({{< relref "/userguide/tools-config/tool_prop.md" >}})
33+
- [Model filters]({{< relref "/userguide/tools-config/model_filters.md" >}})
34+
- [Type definitions]({{< relref "/userguide/tools-config/domain_def.md" >}}) (See the following [Extending a type definition](#example-extending-a-type-definition) example.)
35+
- [Variable injection]({{< relref "/userguide/tools/variable_injection.md" >}})
36+
- [The Prepare Model Tool]({{< relref "/userguide/tools/prepare.md" >}}); see [Target environments]({{< relref "/userguide/target_env.md" >}}).
37+
38+
The WDT tools will look for each configuration file under `$WDT_CUSTOM_CONFIG` if specified, then under `$WLSDEPLOY_HOME/lib`.
39+
40+
#### Example: Extending a type definition
41+
42+
To extend the `WLS` type definition, follow these steps:
43+
- Create a directory to use for custom configurations, such as `/etc/wdtconfig`.
44+
- Define the `WDT_CUSTOM_CONFIG` environment variable to point to that directory.
45+
- Copy the file `$WLSDEPLOY_HOME/lib/typedefs/WLS.json` to the `$WDT_CUSTOM_CONFIG/typedefs` directory and rename it, for example `MY_WLS.json`.
46+
- Edit `MY_WLS.json` with any required changes.
47+
- Run the tool referencing the name of the new type definition, for example:
48+
```
49+
createDomain.cmd -oracle_home /wls12213 -domain_type MY_WLS ...
50+
```

‎documentation/1.9/content/reference/tool_configuration.md renamed to ‎documentation/1.9/content/userguide/tools-config/domain_def.md

Lines changed: 2 additions & 112 deletions
Original file line numberDiff line numberDiff line change
@@ -1,75 +1,11 @@
11
---
2-
title: "Tools Configuration"
2+
title: "Domain type definitions"
33
date: 2019-02-23T17:19:24-05:00
44
draft: false
55
weight: 2
66
---
77

88

9-
#### Contents
10-
- [Tool property file](#tool-property-file)
11-
- [Model filters](#model-filters)
12-
- [Domain type definitions](#domain-type-definitions)
13-
- [Custom configuration](#custom-configuration)
14-
15-
### Tool property file
16-
You can configure or tune WebLogic Deploy Tooling tools using the tool property file. This property file is installed as `<weblogic-deploy>/lib/tool.properties`. You may change the value of any of the properties in this file to tune the WDT tool. Another option is to configure the tool properties in a Custom Configuration directory. Create the `tool.properties` file in the `$WDT_CUSTOM_CONFIG` directory.
17-
18-
If a property is removed from the file, or a property value is incorrectly formatted, a `WARNING` message is logged and an internal default value used instead of the missing or bad value.
19-
20-
| Property | Description |
21-
| -------- | ----- |
22-
| `connect.timeout` | The number of milliseconds that WLST waits for the online `connect` command to complete. A value of 0 means the operation will not timeout. |
23-
| `activate.timeout` | The number of milliseconds that WLST waits for the activation of configuration changes to complete. A value of -1 means the operation will not timeout. |
24-
| `deploy.timeout` | The number of milliseconds that WLST waits for the undeployment process to complete. A value of 0 means the operation will not timeout. |
25-
| `redeploy.timeout` | The number of milliseconds that WLST waits for the redeployment process to complete. A value of 0 means the operation will not timeout. |
26-
| `start.application.timeout` | The number of milliseconds that WLST waits for the start application process to complete. A value of 0 means the operation will not timeout. |
27-
| `stop.application.timeout` | The number of milliseconds that WLST waits for the stop application process to complete. A value of 0 means the operation will not timeout. |
28-
| `set.server.groups.timeout` | Specifies the amount of time the set server groups connection can be inactive before the connection times out. |
29-
30-
### Model filters
31-
32-
WebLogic Deploy Tooling supports the use of model filters to manipulate the domain model. The Create Domain, Update Domain, and Deploy Applications Tool 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.
33-
34-
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.
35-
36-
The following filter example (`fix-password.py`) sets the password for two attributes in the `SecurityConfiguration` WLST folder.
37-
38-
```python
39-
def filter_model(model):
40-
if model and 'topology' in model:
41-
if 'SecurityConfiguration' in model['topology']:
42-
model['topology']['SecurityConfiguration']['CredentialEncrypted'] = 'welcome1'
43-
model['topology']['SecurityConfiguration']['NodeManagerPasswordEncrypted'] = 'welcome1'
44-
print 'Replaced SecurityConfiguration password'
45-
else:
46-
print 'SecurityConfiguration not in the model'
47-
```
48-
49-
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.
50-
51-
Another option is to configure model filters in a [Custom configuration](#custom-configuration) directory. Create the `model_filters.json` file in the `$WDT_CUSTOM_CONFIG` directory.
52-
53-
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.
54-
55-
```json
56-
{
57-
"create": [
58-
{ "name": "fixPassword", "path": "/home/user/fix-password.py" },
59-
{ "name": "noMail", "path": "/home/user/no-mail.py" }
60-
],
61-
"deploy": [
62-
],
63-
"discover": [
64-
{ "name": "noMail", "path": "/home/user/no-mail.py" }
65-
],
66-
"update": [
67-
]
68-
}
69-
```
70-
71-
### Domain type definitions
72-
739
WebLogic Deploy Tooling has an extensible domain type system. The three built-in domain types (`WLS`, `RestrictedJRF`, and `JRF`) are defined in JSON files of the same name in the `WLSDEPLOY_HOME/lib/typedefs` directory. For example, the `JRF` domain type is defined in the `WLSDEPLOY_HOME/lib/typedefs/JRF.json` file with similar content, as shown below.
7410

7511
```json
@@ -150,7 +86,7 @@ def filter_model(model):
15086

15187
New domain types can be defined by creating a new JSON file with the same structure in the `WLSDEPLOY_HOME/lib/typedefs` directory.
15288

153-
Another option is to create this file in the [Custom configuration](#custom-configuration) directory `$WDT_CUSTOM_CONFIG/typedefs`.
89+
Another option is to create this file in the [Custom configuration]({{< relref "/userguide/tools-config/custom_config.md" >}}) directory `$WDT_CUSTOM_CONFIG/typedefs`.
15490

15591
For example, to define a `SOA` domain type for 12.2.1.3, add the `typedefs/SOA.json` file with similar content, as shown below.
15692

@@ -234,49 +170,3 @@ def filter_model(model):
234170
```
235171

236172
The `targeting` attribute is not valid for WebLogic Server versions 12.2.1 and up.
237-
238-
239-
### Custom configuration
240-
241-
WDT allows you to create or extend the pre-installed type definitions, model filters, variable injectors, and target environments. Starting with WDT 1.10.0, these additional configuration files can be stored outside the `$WLSDEPLOY_HOME/lib` directory. This allows the files to remain in place if the WDT installation is moved or upgraded to a new version.
242-
243-
To use a separate configuration directory, set the `WDT_CUSTOM_CONFIG` environment variable to the directory to be used for configuration. For example:
244-
```
245-
export WDT_CUSTOM_CONFIG=/etc/wdtconfig
246-
```
247-
248-
The customized configuration files should be named and organized the same way they would be under the `$WLSDEPLOY_HOME/lib` directory. For example:
249-
```
250-
/etc/wdtconfig
251-
injectors
252-
*.json (injector files)
253-
typedefs
254-
*.json (typedef files)
255-
targets
256-
my-target
257-
target.json
258-
*.py (filter files)
259-
model_filters.json
260-
model_variable_injector.json
261-
variable_keywords.json
262-
```
263-
This is a full set of files that can be configured. You will need only to add the files you have created or extended. Details for each configuration type are found at:
264-
- [Tool property file](#tool-property-file)
265-
- [Model filters](#model-filters)
266-
- [Type definitions](#domain-type-definitions) (See the following [Extending a type definition](#example-extending-a-type-definition) example.)
267-
- [Variable injection]({{< relref "/userguide/tools/variable_injection.md" >}})
268-
- [The Prepare Model Tool]({{< relref "/userguide/tools/prepare.md" >}}); see [Target environments]({{< relref "/userguide/target_env.md" >}}).
269-
270-
The WDT tools will look for each configuration file under `$WDT_CUSTOM_CONFIG` if specified, then under `$WLSDEPLOY_HOME/lib`.
271-
272-
#### Example: Extending a type definition
273-
274-
To extend the `WLS` type definition, follow these steps:
275-
- Create a directory to use for custom configurations, such as `/etc/wdtconfig`.
276-
- Define the `WDT_CUSTOM_CONFIG` environment variable to point to that directory.
277-
- Copy the file `$WLSDEPLOY_HOME/lib/typedefs/WLS.json` to the `$WDT_CUSTOM_CONFIG/typedefs` directory and rename it, for example `MY_WLS.json`.
278-
- Edit `MY_WLS.json` with any required changes.
279-
- Run the tool referencing the name of the new type definition, for example:
280-
```
281-
createDomain.cmd -oracle_home /wls12213 -domain_type MY_WLS ...
282-
```

‎documentation/1.9/content/userguide/tools-config/model_filters.md

Lines changed: 46 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,46 @@
1+
---
2+
title: "Model filters"
3+
date: 2019-02-23T17:19:24-05:00
4+
draft: false
5+
weight: 1
6+
---
7+
8+
9+
WebLogic Deploy Tooling supports the use of model filters to manipulate the domain model. The Create Domain, Update Domain, and Deploy Applications Tool 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.
10+
11+
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.
12+
13+
The following filter example (`fix-password.py`) sets the password for two attributes in the `SecurityConfiguration` WLST folder.
14+
15+
```python
16+
def filter_model(model):
17+
if model and 'topology' in model:
18+
if 'SecurityConfiguration' in model['topology']:
19+
model['topology']['SecurityConfiguration']['CredentialEncrypted'] = 'welcome1'
20+
model['topology']['SecurityConfiguration']['NodeManagerPasswordEncrypted'] = 'welcome1'
21+
print 'Replaced SecurityConfiguration password'
22+
else:
23+
print 'SecurityConfiguration not in the model'
24+
```
25+
26+
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.
27+
28+
Another option is to configure model filters in a [Custom configuration]({{< relref "/userguide/tools-config/custom_config.md" >}}) directory. Create the `model_filters.json` file in the `$WDT_CUSTOM_CONFIG` directory.
29+
30+
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.
31+
32+
```json
33+
{
34+
"create": [
35+
{ "name": "fixPassword", "path": "/home/user/fix-password.py" },
36+
{ "name": "noMail", "path": "/home/user/no-mail.py" }
37+
],
38+
"deploy": [
39+
],
40+
"discover": [
41+
{ "name": "noMail", "path": "/home/user/no-mail.py" }
42+
],
43+
"update": [
44+
]
45+
}
46+
```

‎documentation/1.9/content/userguide/tools-config/tool_prop.md

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
---
2+
title: "Tool property file"
3+
date: 2019-02-23T17:19:24-05:00
4+
draft: false
5+
weight: 4
6+
---
7+
8+
9+
You can configure or tune WebLogic Deploy Tooling tools using the tool property file. This property file is installed as `<weblogic-deploy>/lib/tool.properties`. You may change the value of any of the properties in this file to tune the WDT tool. Another option is to configure the tool properties in a Custom Configuration directory. Create the `tool.properties` file in the `$WDT_CUSTOM_CONFIG` directory.
10+
11+
If a property is removed from the file, or a property value is incorrectly formatted, a `WARNING` message is logged and an internal default value used instead of the missing or bad value.
12+
13+
| Property | Description |
14+
| -------- | ----- |
15+
| `connect.timeout` | The number of milliseconds that WLST waits for the online `connect` command to complete. A value of 0 means the operation will not timeout. |
16+
| `activate.timeout` | The number of milliseconds that WLST waits for the activation of configuration changes to complete. A value of -1 means the operation will not timeout. |
17+
| `deploy.timeout` | The number of milliseconds that WLST waits for the undeployment process to complete. A value of 0 means the operation will not timeout. |
18+
| `redeploy.timeout` | The number of milliseconds that WLST waits for the redeployment process to complete. A value of 0 means the operation will not timeout. |
19+
| `start.application.timeout` | The number of milliseconds that WLST waits for the start application process to complete. A value of 0 means the operation will not timeout. |
20+
| `stop.application.timeout` | The number of milliseconds that WLST waits for the stop application process to complete. A value of 0 means the operation will not timeout. |
21+
| `set.server.groups.timeout` | Specifies the amount of time the set server groups connection can be inactive before the connection times out. |

‎documentation/1.9/content/userguide/tools/create.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@ To have the Create Domain Tool run RCU, simply add the `-run_rcu` argument to th
2828

2929
It is also possible to specify the connection information in the model instead of using the command-line arguments. This is especially easier for databases that require complex database connection string and extra parameters, such as RAC or Oracle Autonomous Transaction Processing Cloud Service database. For information on how to use it, refer to [Specifying RCU connection information in the model]({{< relref "/content/rcuinfo.md" >}}).
3030

31-
To create more complex domains, it may be necessary to create a custom domain type. This is useful for cases where the domain has custom templates, or templates for other Oracle products. For more information, refer to [Domain type definitions]({{< relref "/reference/tool_configuration#domain-type-definitions" >}}).
31+
To create more complex domains, it may be necessary to create a custom domain type. This is useful for cases where the domain has custom templates, or templates for other Oracle products. For more information, refer to [Domain type definitions]({{< relref "/userguide/tools-config/domain_def.md" >}}).
3232

3333
### Using an encrypted model
3434

0 commit comments

Comments
 (0)