KEYCLOAK-6342 changed references to variable

authorization_services/topics/example-overview.adoc

@@ -31,5 +31,5 @@ Here is a brief description of each example:
 | A simple application based on HTML5+AngularJS+JAX-RS that demonstrates how to enable fine-grained permissions to RESTFul based services and HTML5 clients.
 
 | https://github.com/keycloak/keycloak/tree/{project_version}/examples/authz/servlet-authz[servlet-authz]
-| A simple Servlet-based application that demonstrates how to enable fine-grained authorization to a JBoss/Wildfly Servlet Application.
+| A simple Servlet-based application that demonstrates how to enable fine-grained authorization to a {appserver_name} Servlet Application.
 |===

server_development/topics/providers.adoc

@@ -185,7 +185,7 @@ If you are creating a custom SPI you will need to deploy it as a module, otherwi
 ==== Using the Keycloak Deployer
 
 If you copy your provider jar to the Keycloak `deploy/` directory, your provider will automatically be deployed.
-Hot deployment works too.  Additionally, your provider jar works similarly to other components deployed in a JBoss/Wildfly
+Hot deployment works too.  Additionally, your provider jar works similarly to other components deployed in a {appserver_name}
 environment in that they can use facilities like the `jboss-deployment-structure.xml` file.  This file allows you to
 set up dependencies on other components and load third-party jars and modules.
 
@@ -269,7 +269,7 @@ The can be packaged within any Java EE component so long as you set up the `META
 file correctly to point to your providers.  For example, if your provider needs to use third party libraries, you
 can package up your provider within an ear and store these third pary libraries in the ear's `lib/` directory.
 Also note that provider jars can make use of the `jboss-deployment-structure.xml` file that EJBs, WARS, and EARs
-can use in a JBoss/Wildfly environment.  See the JBoss/Wildfly documentation for more details on this file.  It
+can use in a {appserver_name} environment.  See the {appserver_name} documentation for more details on this file.  It
 allows you to pull in external dependencies among other fine grain actions.
 
 `ProviderFactory` implementations are required to be plain java objects.  But, we also currently support

server_development/topics/user-storage/javaee.adoc

@@ -5,7 +5,7 @@ The user storage providers can be packaged within any Java EE component if you s
 file correctly to point to your providers. For example, if your provider needs to use third-party libraries, you
 can package up your provider within an EAR and store these third-party libraries in the `lib/` directory of the EAR.
 Also note that provider JARs can make use of the `jboss-deployment-structure.xml` file that EJBs, WARS, and EARs
-can use in a JBoss/Wildfly environment. For more details on this file, see the JBoss/Wildfly documentation. It
+can use in a {appserver_name} environment. For more details on this file, see the {appserver_name} documentation. It
 allows you to pull in external dependencies among other fine-grained actions.
 
 Implementations of `UserStorageProviderFactory` are required to be plain java objects. But we also currently support
@@ -83,7 +83,7 @@ WARNING: When using JPA any additional datasource must be an XA datasource. The
          is not an XA datasource. If you interact with two or more non-XA datasources in the same transaction, the server returns
          an error message. Only one non-XA resource is permitted in a single transaction.
 
-See the JBoss/Wildfly manual for more details on deploying an XA datasource.
+See the {appserver_name} manual for more details on deploying an XA datasource.
 
 CDI is not supported.
 

server_development/topics/user-storage/packaging.adoc

@@ -1,7 +1,7 @@
 
 === Packaging and Deployment
 
-User Storage providers are packaged in a JAR and deployed or undeployed to the {project_name} runtime in the same way you would deploy something in the JBoss/Wildfly application server. You can either copy the JAR directly to the `deploy/` directory of the server, or use the JBoss CLI to execute the deployment.
+User Storage providers are packaged in a JAR and deployed or undeployed to the {project_name} runtime in the same way you would deploy something in the {appserver_name} application server. You can either copy the JAR directly to the `deploy/` directory of the server, or use the JBoss CLI to execute the deployment.
 
 In order for {project_name} to recognize the provider, you need to add a file to the JAR: `META-INF/services/org.keycloak.storage.UserStorageProviderFactory`. This file must contain a line-separated list of fully qualified classnames of the `UserStorageProviderFactory` implementations:
 

server_development/topics/user-storage/simple-example.adoc

@@ -257,7 +257,7 @@ The class files for our provider implementation should be placed in a jar.  You
 org.keycloak.examples.federation.properties.FilePropertiesStorageFactory
 ----
 
-Once you create the jar you can deploy it using regular JBoss/Wildfly means: copy the jar into the `deploy/` directory or using the JBoss CLI.
+Once you create the jar you can deploy it using regular {appserver_name} means: copy the jar into the `deploy/` directory or using the JBoss CLI.
 
 ==== Enabling the Provider in the Administration Console
 

upgrading/topics/keycloak/changes.adoc

@@ -540,7 +540,7 @@ Facebook admin console).
 === Migrating from 1.0 Alpha 1 to Alpha 2
 
 * DB Schema has changed.  We don't have any data migration utilities yet as of Alpha 2.
-* JBoss and Wildfly adapters are now installed via a JBoss/Wildfly subsystem.  Please review the adapter
+* JBoss and Wildfly adapters are now installed via a {appserver_name} subsystem.  Please review the adapter
   installation documentation.  Edits to standalone.xml are now required.
 * There is a new credential type "secret".  Unlike other credential types, it is stored in plain text in
   the database and can be viewed in the admin console.