How it was in the Old Days (pre-V3)

We needed a way to be able to specify special directories and booleans that applied to the entire installation. E.g. where are Ant files? Where is the JDK? A complicated procedure was worked out.

asenv.bat and asenv.conf

• asadmin would always run a script from within the asadmin script before starting its JVM. These scripts were named asenv.bat or asenv.conf depending on the platform and lived in the install-root/config directory.
• The asenv script contained platform-dependent commands to set environmental variables.
• These environmental variables were mainly for specifying paths to interesting components. There was one variable that had a true or false value (AS_NATIVE).

How was it used?

• The asadmin script ran the asenv script itself in order to get some required values for use in the JVM invocation line.
• Meantime the server and runtime CLI would not use these environmental variables. Instead it went through the painful process of parsing and coaxing the values out of the 2 types of platform-specific asenv scripts.
• Then a laborious mapping was maintained between names of environmental variables and the names of the corresponding System Properties. E.g. AS_INSTALL – com.sun.aas.installDir. At runtime the values of the System Properties were set from the environmental variables. THough they aren't really environmental variables – just strings parsed out of the asenv script.

So what's wrong with this procedure?

• System Properties suck! They are the most thread-hostile common data source that I know of. Our goal should be to rarely, if ever, use them. Let the JVM work with its System Properties, and we'll work with our own thread-safe internal data structures!
• Clients and Servers have different (and partially duplicated) ways of working with the same information in the script.
• Environmental variables are supported but are not part of Java. They are part of operating systems. They are undesirable for the purpose of organizing installation-wide configuration data, but are handy for other uses. E.g. they are quite handy at runtime for running special code or diagnostics.
• Full paths are wired into asenv files. There is no support for relative paths. Also we ended up with ugly embarassing paths like this: c:\jdk\jre/../bin. It also makes the installation totally non-relocatable.
• The installation directory has to be specified inside the asenv file as an environmentl variable.
• An installer was required in order to set the directory where the JVM lives.

How are we changing it in V3?

• asenv is not a script but rather a pure configuration file with the standard Properties File format.
  • All V3 apps, sub-apps, servers, clients are Java. Thus they can all access the configuration information in the file via well-known classes.
  • The install directory and, thus, the location of asenv can always be calculated very very early simply by figuring out the path to the jar containing the class that is executing.
  • An asenv manager class will be developed that will be the one and only source of this configuration information at runtime. Zero bootstrapping information or parameters are required.
• Since environmental variables are not used the syntax is simple:

runtime-prop-name=some-value

The value can be:

• An absolute path e.g. C:/glassfish/domains
• An absolute path with annoying dots e.g. c:/glassfish/modules/../lib/../../glassfish/domains
• A relative path e.g. ./../domains
• A string e.g. true
• A string with tokens %MY_DOMAINS_DIR% or ~UWC_TOKEN_START~1278579877561~UWC_TOKEN_END{MY_DOMAINS_DIR}
• A string with multiple tokens e.g. ~UWC_TOKEN_START~1278579877562~UWC_TOKEN_END{MY_ROOT}/ant/~UWC_TOKEN_START~1278579877563~UWC_TOKEN_END{LIB}