You can use WebSphere variables to provide settings for any of the string data type
attributes that are contained in the product configuration files.
Before you begin
Because applications cannot directly access WebSphere variables, if you define a WebSphere
variable inside of an application, an error message, such as "Unknown variable," is returned. If you
must reference a WebSphere variable from within an application, include the following method in the
application to expand the string that uses the WebSphere variable.
Avoid trouble: Expanding WebSphere variables requires you to have
administrative privileges.
private String expandVariable(String s) throws
javax.management.JMException {
com.ibm.websphere.management.AdminService as =
com.ibm.websphere.management.AdminServiceFactory.getAdminService
();
String server = as.getProcessName();
java.util.Set result = as.queryNames(new javax.management.ObjectName("*:*,type=AdminOperations,process="
+ server), null);
return (String)as.invoke((javax.management.ObjectName)
result.iterator().next(),"expandVariable",new Object[]
{"${"+s+"}"}, new String[] {"java.lang.String"});
Similarly, you can include the following lines of code in a script file if you want to use a
script command to expand WebSphere variables.
- Using
Jacl:
set mbean [$AdminControl completeObjectName WebSphere:*,type=AdminOperations]
$AdminControl invoke $mbean expandVariable {{"${APP_INSTALL_ROOT}"}}
- Using
Jython:
AdminOperations = AdminControl.completeObjectName('WebSphere:*,type=AdminOperations')
print AdminControl.invoke(AdminOperations, 'expandVariable', '${APP_INSTALL_ROOT}')
About this task
WebSphere variables are usually used to specify file paths. The "Variable settings" topic
supplies further details about specifying variables and highlights further details about product
components that use them.
WebSphere variables are also used to configure:
- Product path names, such as JAVA_HOME, and APP_INSTALL_ROOT.
- Configure certain cell-wide or cluster-wide customization values.
- The location service.
- Environment variables.
The variable scoping mechanism for WebSphere variables enables you to define a
variable at the node, cluster, or cell level, as well as at the server level. This mechanism enables
you to specify a setting for all of the servers in a node, cluster, or cell, instead of individually
specifying the setting for each server.
To define a new variable, change the value of an existing variable, or delete an existing
variable complete the following steps, as appropriate.
Procedure
-
Click in the administrative console
-
Select the scope of the variable from the list of available scopes.
If you create a new variable, it will be created at the selected scope. If you define the same
variable at multiple levels, the more granular definition overrides the higher level setting. For
example, if you specify the same variable on a cell level and at a node level, the node level
setting overrides the cell level setting.
Scoping variables is particularly important if you are testing data source objects. Variable
scoping can cause a data source to fail the test connection, but to succeed at run time, or to pass
the test connection, but fail at run time.
-
Create a new variable.
-
Click New.
-
Specify a name, a value, and, optionally, a description for the variable.
The application server uses WebSphere® Application Server
internal variables for its own purposes. The prefixes that indicate that a variable is internal are
WAS_DAEMON_<server custom property>, WAS_DAEMON_ONLY_<server custom
property>, and WAS_SERVER_ONLY_<server custom property>. Any
variables with these tags are not intended for your use. They are reserved exclusively for use by
the server run time. Modifying these variables can cause unexpected errors.
You can use WebSphere variables to modify the daemon configuration. By appending a
server custom property onto a daemon tag, you can designate that variable specifically for that
daemon. Enter DAEMON_<server custom property> in the Name field. For example,
if you enter DAEMON_ras_trace_outputlocation in the Name field and SYSOUT in the
Value field, you can direct that particular daemon's trace output to SYSPRINT.
You can create WebSphere variables that support substitution. For example, if you enter
${<variable name>} in the Name field, the value of <variable
name> becomes the name of your new WebSphere variable. For example if you enter
${JAVA_HOME} as the name of your variable, the name of the WebSphere variable that is
created is the Java™ home directory.
-
Click OK.
-
Click in the administrative console navigation, and verify that the variable is displayed
in the list of variables for the selected scope.
The administrative console does not pick up typing errors. The variable is ignored if it is
referred to incorrectly.
-
Modify the setting for an existing variable.
-
Click on the name of the variable that you want to change.
-
Modify the content of the Values field.
The Values field for some of the variables that are already defined when you install the product
are read-only because changing the values that are specified for those variables might cause product
processing errors.
-
Click OK.
-
Delete an existing variable.
-
Select the variable that you want to delete.
-
Click Delete.
-
Click OK.
-
Verify that this variable was removed from the list of variables for the selected scope.
-
Save your configuration.
-
Stop the affected servers and start those servers again to put the variable configuration
change into effect.
If the change you made affects a node, you must stop and restart all of the servers on that node.
Similarly if the change you made affects a cell, you must stop and restart all of the servers in
that cell.