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:
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. 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.
- 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.