An EGL-generated Java™ program
uses a set of properties that provide information at runtime. Most
of these Java runtime properties
are set using build descriptor options, that you assign values to
by editing the build descriptor part in the EGL Build Parts Editor.
Note: EGL-generated Java VGWebTransaction
programs represent a special case. The determination of whether they
run in a J2EE or non-J2EE environment depends on the setting of program
property enableJ2EE. (The default value
is NO.) If you are reading this topic because you are working with
a VGWebTransaction program, do as follows whenever you read a reference
to the build descriptor option j2ee: consider
the value of program property enableJ2EE instead.
During generation, the build descriptor options' values are stored
in the corresponding Java runtime
properties, which are then listed in one of the following files:
- If you are deploying your output in a J2EE environment, the properties
are stored in the J2EE deployment descriptor.
- If you are deploying your output in a non-J2EE environment, the
properties are stored in a program properties file.
- If you have set the j2ee build descriptor
option to YES and have specified a directory for the genDirectory build
descriptor option, then the Java runtime
properties are stored in a J2EE environment file. A J2EE environment
file is also created if you have set the j2ee build
descriptor option to YES and have set the genProject build
descriptor option to a non-J2EE project.
You can then go into either the J2EE deployment descriptor or the Java properties file, and edit any
of the values of the runtime properties without having to generate
your code again.
In order for EGL to use build descriptor options to create runtime
properties, you must set the genProperties build
descriptor option to either PROGRAM or GLOBAL.
Build descriptors and program properties
If
you are generating Java runtime
properties, they will be created and stored according to one of the
following scenarios:
- To generate Java runtime
properties to the J2EE deployment descriptor, follow these steps:
- Set the j2ee build descriptor option
to YES.
- Set the genProperties build descriptor
option to PROGRAM or GLOBAL.
- Generate your code into a J2EE project.
- To generate properties into a J2EE environment file, follow these
steps:
- Set the j2ee build descriptor option
to YES.
- Set the genProperties build descriptor
option to PROGRAM or GLOBAL.
- Do either one of the following:
- Generate into a directory, in which case you use the genDirectory build
descriptor option rather than genProject;
or
- Generate into a non-J2EE project.
Note that the properties stored in the J2EE environment file
will not be automatically updated when you generate.
- To generate a program properties file, with the same name as the
program being generated, follow these steps:
- Set the j2ee build descriptor option
to NO.
- Set the genProperties build descriptor
option to PROGRAM.
- Do either one of the following:
- Generate into a directory, in which case you use the genDirectory build
descriptor option rather than genProject;
or
- Generate into a non-J2EE project.
- To generate a program properties file named rununit.properties,
follow these steps:
- Set the j2ee build descriptor option
to NO.
- Set the genProperties build descriptor
option to GLOBAL.
- Do either one of the following:
- Generate into a directory, in which case you use the genDirectory build
descriptor option rather than genProject;
or
- Generate into a non-J2EE project.
- To avoid generating properties, set genProperties to
NO.
In a J2EE environment
If you are generating
a Java program that will run
in a J2EE environment, the Java runtime
properties can be created in one of the following ways:
- You can follow the steps in the first scenario in the previous
section, to generate the Java runtime
properties directly into a J2EE deployment descriptor. In this case,
EGL overwrites properties that already exist and appends properties
that do not exist. The generated Java program
accesses the J2EE deployment descriptor at run time.
- Alternatively, you can follow the steps in the second scenario
of the previous section, to generate the runtime properties into a
J2EE environment file. You can customize the properties in that file,
then copy them into the J2EE deployment descriptor.
- You can also follow the fifth scenario from the previous section,
and set the genProperties build descriptor
option to NO, to avoid generating the runtime properties at all. In
this case, you must write any needed Java runtime
properties by hand.
In a J2EE module, every program has the same runtime properties
because all code in the module shares the same J2EE deployment descriptor.
For
J2EE servers, properties are specified as env-entry tags in the web.xml
file that is associated with the web project, as in these examples:
<env-entry>
<env-entry-name>vgj.nls.code</env-entry-name>
<env-entry-value>ENU</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>
<env-entry>
<env-entry-name>vgj.nls.number.decimal</env-entry-name>
<env-entry-value>.</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>
</env-entry>
In a non-J2EE environment
If you are generating
a Java program that will run
outside of a J2EE environment, you can set the genProperties build
descriptor option to either PROGRAM or GLOBAL, which causes EGL to
generate the runtime properties into a program properties file; or
you can code the program properties file by hand. The program properties
file provides the kind of information that is available in the deployment
descriptor, but the format of the properties is different.
In
a non-J2EE Java environment,
runtime properties can be specified in any of several properties files,
which are searched in this order:
- user.properties
- A file named as follows:
programName.properties
where programName is
the first program in the run unit.
- rununit.properties
Using user.properties is appropriate
when you specify properties that are specific to a user. EGL does
not generate content for this file.
Using
rununit.properties is
especially appropriate when the first program of a run unit does not
access a file or database, but calls programs that do. For example:
- When generating the calling program, you can generate a program
properties file named for the generated program, and the content might
include no database- or file-related properties.
- When you generate the called program, you can generate rununit.properties,
and the content would be available for both programs.
None of the properties files are mandatory, and simple
programs do not need any.
Rules for deploying non-J2EE code
At deployment
time, the following rules apply:
If you generate output to a Java project,
EGL places the properties files (other than user.properties)
in the appropriate folders.
For details on accessing runtime properties in your EGL code, see
the topics "getProperty()" and "Run unit" in the EGL Language
Reference.