To understand how variables work in WebSphere, let's consider a scenario where an application will be deployed to a few different application servers, where one application server is being used for development (dev), one is used for integration testing (int), and one is used for production (prod).

If the app has markup that is environment specific, this creates challenges and introduces risk, as the markup of the application would need to be modified for each environment. For example, the below markup includes "dev" for the development environment. 

private String username = "dev_username";
private String password = "dev_password";
private String jdbc     = "jdbc:mysql://dev.example.com:3306/dev_database"; 

Instead of putting environment specific markup in the app, there are a few options to consider. One option is to create a variable in the WebSphere application server that contains the application. This is a really good approach when the variable is unique to a single application server in the WebSphere cell.

However, this approach doesn't make much sense when you have numerous application servers, since each application server maintains it's own set of variables. In this design, you could easily end up with identical variables across multiple application servers.

Fortunately, IBM accounted for this challenge. What you can do is to create a name space binding at the cell scope, so that all of the application servers and applications in the cell can use the name space binding. A name space binding is like a variable, in that it is a key-value pair that can be used in a Java app to return a string.

It is also noteworthy that a properties file could be used, but it usually does not make much sense to use a properties file, since WebSphere can take care of this using variables or name space binding. Additionally, less markup is needed in the Java app when using WebSphere variables or name space binding.

Now, if you still find that it makes sense to create a variable in a WebSphere application server, read on.

Create the variable

1. In the WebSphere admin console, select Servers > Server Types > WebSphere application servers.
2. Select the JVM that contains the app.
3. Expand Java and Process Management and select process definition.
4. Select Java Virtual Machines.
5. Select Custom properties.
6. Select New.
7. Create the name and value of the variable and select OK.
8. Select Save.
9. Restart the JVM for this change to take effect.

In this example, a variable named ENV with a vaule of "dev" was created.

Configure your Java app to use the variable

In this example, a class named "Environment" contains the following markup. This class creates a variable named env, and the env variable gets the value of the ENV variable from WebSphere.

package com.example.main;

public class Environment {	
    public String env;

    public Environment() {
        env = System.getProperty("ENV");
    } 
}

You can now use the env variable in the class. One option would be to use the following markup, which would allow you to use the env variable in a JSP page.

    public String getEnvironment(){
        return env;
    }

Another option would be to use the env varialbe in the class.

private String username = env+"_username";
private String password = env+"_password";
private String jdbc     = "jdbc:mysql://"env+".example.com:3306/"env+"_database"; 

If you are going to be passing the env variable onto a JSP page, in the JSP page, you would import "com.sample.main.Environment". Then, create a new object (foo in this example). In Environment foo = new Environment();. The text "Environment" must be used since the class is named "Environment". Using foo, get the value of the env variable. Be careful to use "out.print" and not "out.println". 

<%@page import="com.sample.main.Environment"%>

<%
  Environment foo = new Environment();
  String env = foo.getEnvironment();
  out.print("Environment : " + env;
%>

Now, once the app has been deployed to WebSphere, the environment should be displayed.