You can use WebSphere variables to provide settings for
any of the string data type attributes that are contained in the product
configuration files.
About this task
WebSphere variables are typically used to specify file
paths. However, some system components also support the use of these
variables. 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.
When you define variables on the Environment >
WebSphere Variables administrative console page, specify the name
of the variable in the Name field, and the value for the variable
in the Value field. Do not include an equal sign in either the Name
or the Value field.
Avoid trouble: Do not define WebSphere variables
in terms of themselves, directly or indirectly. Variable substitution
takes place recursively, not sequentially as is the case in a shell
script. Therefore a variable defined in terms of itself causes a recursion
failure.
gotcha
To define a new variable, change the value of an
existing variable, or delete an existing variable complete the following
steps, as appropriate.
- Click Environment > WebSphere Variables in the administrative
console to define a new variable.
-
Specify the scope of the variable.
Declare the
new variable for the Cell, Cluster, Node, or Server and
click Apply.
The variable exists at the level you specify.
Define a variable at multiple levels to use multiple values. The more
granular definition overrides the higher level setting.
For
instance, if you specify the same variable on a node and a server,
the server setting overrides the node setting. Similarly, a cluster
level setting overrides a node or cell setting.
Scoping variables
is particularly important when 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.
- Click New on the WebSphere Variables page.
- Specify a name, a value, and a description on the Variable
page. Click OK.
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 Application Server 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. The name
of a variable can be formed by substituting the value of another variable.
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.
- Verify that the variable is displayed in the list of variables.
The administrative console does not pick up typing errors. The variable
is ignored if it is referred to incorrectly.
- Save your configuration.
- Stop the server and start the server again to put the variable
configuration change into effect.
What to do next
If you need to reference a WebSphere variable from within
an application, include the following method in the application to
expand the string that uses the WebSphere variable. Applications cannot
directly access WebSphere variables. Therefore, if you define a WebSphere
variable inside of an application, an error message, such as "Unknown
variable," is returned.
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}')