You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Issue #144 - Add removal of named objects to the model
* Issue #144 - Add removal of named objects to create; improve logging
* Issue #144 - Use WLST name for delete
* Issue #144 - Add delete capabilities to JNDI properties and group parameters; updated documentation
* Refined logic for get_delete_item_name()
@@ -52,7 +53,7 @@ As new use cases are discovered, new tools will likely be added to cover those o
52
53
53
54
## The Metadata Model
54
55
55
-
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 datasource 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. In short, the `deployApps` tool supports an iterative deployment model so there is no need to change the model to remove pieces that were created in a previous deployment.
56
+
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.
56
57
57
58
The model structure, and its folder and attribute names, are based on the WLST 12.2.1.3 offline structure and names with redundant folders removed to keep the model simple. For example, the WLST path to the URL for a JDBC data source is `/JDBCSystemResource/<data-source-name>/JdbcResource/<data-source-name>/JDBCDriverParams/NO_NAME_0/URL`. In the model, it is `resources:/JDBCSystemResource/<data-source-name>/JdbcResource/JDBCDriverParams/URL` (where `resources` is the top-level model section where all WebLogic Server resources/services are described).
58
59
@@ -220,6 +221,36 @@ In the example above, the `Target` attribute is specified three different ways,
220
221
221
222
One of the primary goals of the WebLogic Deploy Tooling is to support a sparse model where the user can specify just the configuration needed for a particular situation. What this implies varies somewhat between the tools but, in general, this implies that the tools are using an additive model. That is, the tools add to what is already there in the existing domain or domain templates (when creating a new domain) rather than making the domain conform exactly to the specified model. Where it makes sense, a similar, additive approach is taken when setting the value of multi-valued attributes. For example, if the model specified the cluster `mycluster` as the target for an artifact, the tooling will add `mycluster` to any existing list of targets for the artifact. While the development team has tried to mark attributes that do not make sense to merge accordingly in our knowledge base, this behavior can be disabled on an attribute-by-attribute basis, by adding an additional annotation in the knowledge base data files. The development team is already thinking about how to handle situations that require a non-additive, converge-to-the-model approach, and how that might be supported, but this still remains a wish list item. Users with these requirements should raise an issue for this support.
222
223
224
+
### Declaring Named MBeans to Delete
225
+
226
+
With WebLogic Deploy Tooling release 1.3.0, you can specify named items in the model to be deleted using the Create Domain, Update Domain, and Deploy Applications Tools. Named items are those that have multiple instances that are distinguished by user-provided names, such as managed servers, data sources, and security realms. Items to be deleted are prepended with an exclamation point (!) in the model.
227
+
228
+
In this example, the managed server ```obsoleteServer``` will be deleted, and ```newServer``` will be created:
229
+
230
+
```yaml
231
+
Server:
232
+
!obsoleteServer:
233
+
newServer:
234
+
ListenAddress: 127.0.0.1
235
+
ListenPort: 9005
236
+
```
237
+
238
+
This feature can also remove items that were created by WebLogic Server templates. For example, the base template creates a default security realm called ```myrealm```. If a user chooses to declare a custom realm, ```myrealm``` is no longer needed. In this example, ```myrealm``` will be deleted, and the custom realm ```newrealm``` will be created, and declared as the default realm:
239
+
240
+
```yaml
241
+
SecurityConfiguration:
242
+
DefaultRealm: newrealm
243
+
Realm:
244
+
!myrealm:
245
+
newrealm:
246
+
AuthenticationProvider:
247
+
...
248
+
```
249
+
250
+
This feature does not apply to named security providers within a realm. These items follow a special set of rules that are required to maintain their ordering. See [Modeling Security Providers](site/security_providers.md) for detailed information.
251
+
252
+
This feature cannot be use to un-deploy applications or remove libraries.
253
+
223
254
### Using Multiple Models
224
255
225
256
The Create Domain, Update Domain, Deploy Applications, and Validate Model Tools allow the specification of multiple models on the command line. For example:
0 commit comments