Deploying Applications
The following sections are included:
Oracle Forms Services in Action
This section describes the steps to run Forms Services in Oracle Fusion Middleware and how the configuration files are used, with the assumption that the Forms servlet is used to generate the initial HTML page.
Be aware that if you run an out-of-the-box Forms URL with no arguments the user will be shown the default test-form, which displays the Forms version number information. If it is desired that this information not be displayed, the administrator can simply modify the [default] config section in their environment so that a different form is specified (or no form is specified at all, in which case users will get an error message when they try that URL rather than seeing the form that includes the version number). For example, assume the WebLogic Managed Server is running on port 7777 on a computer called example.com. Also assume no modifications have been made to the standard configuration created during the Oracle Fusion Middleware installation process.
When a user runs an Oracle Forms Services application, the following sequence of events occur:
-
The user calls Forms using a URL:
http://example.com:7777/forms/frmservlet?config=myapp&form=hrapp
In this example, the top level form module to be run is called hrapp using the configuration section called myapp.
-
Oracle HTTP Server listener receives the request. It finds
/forms
path in the URL and forwards the request to the correct Oracle WebLogic Managed Server based on the WebLogic handler mappings. The mapping is defined informs.conf
.Note:
Using Oracle HTTP Server (OHS) in front of WebLogic Server is optional. Choosing to do so will require that forms.conf be configured post installation. The included example within the file can be used as an example of appropriate settings. Once settings have been saved, the file should be moved to the OHS configuration file directory that contains other .conf files, see Enabling Oracle HTTP Server with Oracle Forms Services.
-
Oracle WebLogic Managed Server maps the request to the Oracle Forms Services application that has a context root named
/forms
. It maps the request to the Forms servlet using the frmservlet mapping specified in theapplication.xml
file. -
The Forms servlet running on the Oracle WebLogic Managed Server processes the request. The Forms servlet:
-
Opens the servlet configuration file (
formsweb.cfg
by default), which is located in$DOMAIN_HOME/config/fmwconfig/servers/WLS_FORMS/applications/formsapp_12.2.1/config
. -
Determines which configuration section to use in the
formsweb.cfg
file. In this example, the URL contains the query parameterconfig=myapp
, therefore, the [myapp
] section is used. -
Determines which baseHTML or basejnlp file to use, based on (a) what browser (user-agent) made the request, (b) what platform the browser is running on, and (c) the settings of various parameters in the
formsweb.cfg
file. -
Reads the baseHTML file, and returns the contents as an HTML (or JNLP) page to the user's Web browser or Forms Standalone Launcher (FSAL), after performing variable substitutions as follows:
Whenever a variable (like
%myParam%
) is encountered, the Forms servlet looks for a matching URL query parameter (for example,&myParam=xxx
), or, failing that, looks for a matching parameter in theformsweb.cfg
file. If a matching parameter is found, the variable (%myParam%
) is replaced with the parameter value.In this example, the baseHTML file contains the text
%form%
. This is replaced with the value "hrapp".
-
-
Depending on which baseHTML file the Forms servlet selected, the HTML page returned to the client contains an applet, object embed, or jnlp tag to start the Forms applet. The Forms client runs in the JVM environment provided by Oracle Java plug-in, Web Start, or standalone Java executable, depending on the request type.
-
To start the Forms applet, its Java code must first be loaded. The location of the applet is specified by the applet codebase and archive parameters.
The virtual path definition in the
weblogic.xml
file for/forms/java
allows the applet code to be loaded from the Web server.Note: The Forms applet code is only loaded over the network the first time the user runs an Oracle Forms Services application or if a newer version of Oracle Forms Services is installed on the Web server. Otherwise, it is loaded from the Java cache on the local disk.
-
Once the Oracle Forms Services applet is running, it starts a Forms session by contacting the Forms Listener servlet at URL
http://example.com:7777/forms/lservlet
. -
The Oracle HTTP Server listener receives the request. It forwards the request to Oracle WebLogic Managed Server, since the path
/forms/lservlet
matches a servlet mapping in theweb.xml
file (the one for the Forms Listener servlet). -
The Forms Listener servlet (lservlet) starts a Forms run-time process (
frmweb.exe
orfrmweb
) for the Forms session. -
Communication continues between the Forms applet and the Forms run-time process, through the Listener Servlet, until the Forms session ends.
-
The attribute value in a URL (such as the name of the form to run) is passed to the Forms run-time process. Part of the serverArgs value in the baseHTML file is
%form%
, which is replaced by "hrapp". Therefore, the run-time process runs the form in the file "hrapp.fmx".This file must be present in any of the directories named in the
FORMS_PATH
environment setting, which is defined in the environment file (default.env
by default). -
The Forms sessions end when either of the following occurs:
-
The top-level form is exited (for example, by the PL/SQL trigger code which calls the "exit_form" built-in function). The user is prompted to save changes if there are unsaved changes.
exit_form(no_validate)
exits the form without prompting. -
If the user quits the session without first saving pending changes, all changes will be lost.
-
Application Deployment
Once you have created your application in Forms Developer, you are ready for application Web deployment. Oracle Forms Services accesses an application in Oracle Fusion Middleware through a specified URL.
The URL then accesses the HTTP Listener, which communicates with the Listener Servlet. The Listener Servlet starts a Forms run-time process (frmweb.exe
on Windows or frmweb
on UNIX and Linux) for each Forms Services session.
For information about how Forms Services run, see Oracle Forms Services in Action.
The following section are included:
Deploying Your Application
To deploy a basic form with the default parameters set up by Oracle Fusion Middleware Config Wizard:
Specifying Parameters
There are two ways to predefine parameter values for your Oracle Forms Services applications. You can define parameters by:
-
Editing your application settings in the default section of the Web Configuration page of Fusion Middleware Control. The default configuration section displays the default values that are used by Oracle Forms Services.
-
Managing (adding, editing, copying, deleting) other system and user parameter values in the named application configuration section (see Creating Configuration Sections in Fusion Middleware Control). For example, in the configuration section you create for
myApp
, you can add or change these parameters and their values, as shown in the following table.Table -3 Example Configuration Section: Parameter Values for myApp
Parameter Name Parameter Value baseHTML
mybase.htm
baseHTMLjpi
mybasejpi.htm
form
hrapp.fmx
userid
scott/tiger@orcl
Note:
Parameters specified in the named configuration section of a Web Configuration override the settings in the default section.
Note:
System Parameters cannot be overridden in the URL, while user parameters can.
Creating Configuration Sections in Fusion Middleware Control
Within the configuration sections you created in step 2 of Deploying Your Application, you can specify parameters for your Oracle Forms Services applications. You can specify any application and system parameters that are available in the default section for Web Configuration page.
For example, you can set the look and feel of the application to the Oracle look and feel by setting the lookAndFeel
parameter to the value of oracle
and clicking Apply.
You can also override the default parameter values in the named configuration section. For example, to predefine the connect information of an application to <username>/<password>@orcl
, the parameter value for userid
must be set in the named configuration section by changing the parameter value of userid
to <username>/<password>@orcl
.
For other parameters that you can edit, see Forms Configuration Parameters.
Editing the URL to Access Oracle Forms Services Applications
You can directly type parameters in the URL that accesses your Oracle Forms Services application. Using the previous example, instead of specifying the form
parameter in your configuration file, you could also type it into the URL as follows:
http://example.com:9001/forms/frmservlet?config=my_application&form=hrapp
You can use the ampersand (&) to call a combination of a form and named configuration parameters. In the above example, you are calling the form "hrapp" with the parameter settings you specified in "my_application".
Note:
Parameters specified in the URL override the parameters set in the configuration section, see Managing URL Security for Applications.
Specifying Special Characters in Values of Runform Parameters
Certain considerations apply if values passed to runform parameters contain special characters. This section describes these considerations, and compares the default behavior in this release with the behavior in prior releases.
Runform parameters are those that are specified in the serverArgs applet parameter of the template HTML file. The value specified for the serverArgs parameter in the template HTML file, after variable substitution, is sometimes referred to as the command-line parameters string. It consists of a series of blank-separated name=value
pairs. The name must consist solely of alphanumeric or underscore characters. The value portion of a name=value pair can be an arbitrary string.
Default Behavior in the Current Release
The value of a runform parameter can be specified in one of three places:
-
In the value of the
serverArgs
parameter in the template HTML file (for example, base.htm). -
In the value of a variable specified in the configuration file (for example,
formsweb.cfg
), which is substituted (directly or recursively) for a variable reference in (1). Such values are typically maintained using Fusion Middleware Control; see Configuring Forms Services. -
As an attribute value in a URL, which is substituted directly for a variable reference in (1) or (2).
For case (3), URL syntax rules (as enforced by the browser and the application server) require that certain characters be entered as URL escape sequences ('%' followed by 2 hexadecimal digits representing the ASCII value of the character, for a total of three characters).
This requirement includes the %
character itself (which must be entered as %25
). In addition, Oracle Forms Services currently requires that the quote character ('"') be entered as %22
, even if the browser and the application server allow a quote to be entered without escaping.
URL syntax rules also allow a space to be entered as a +
(as an alternative to the URL escape sequence %20
). However in the value of the otherparams
configuration parameter, a +
is treated specially; it separates name=value pairs as opposed to indicating a space embedded in the value of a runform parameter.
For example, if a runform application has user parameters param1
and param2
, and you want to assign them the values 'a b' and 'c d', you do so by incorporating the following into a URL:
&otherparams=param1=a%20b+param2=c%20d
When specifying runform parameters in the template HTML files or in the configuration files (cases (1) and (2)), Forms requires URL escape sequences in some circumstances, allows them in others, and forbids them in still others.
Outside of the values of runform parameters, URL escape sequences must not be used. For example, the =
in a name=value pair must always be specified simply as =
, and the space that separates two adjacent name=value pairs must always be specified simply as " " (a single space character).
Within the value of a runform parameter, space (' ') must be specified as a URL escape sequence (%20
). The HTML delimiter character (specified in the configuration file) must also be specified as a URL escape sequence. And when the runform parameter is specified in the template HTML file (case (1)), quote ('"') must also be specified as a URL escape sequence (%22).
Any other 7-bit ASCII character may also be specified as a URL escape sequence, although this is not required (except possibly for %
, as noted below). Certain additional restrictions apply to the %
character. These include:
-
If the HTML delimiter is
%
(the default), then an occurrence of%
within the value of a runform parameter must be escaped (specified as%25
). (This actually follows from the requirement stated above, that the HTML delimiter character be escaped). Furthermore, variable names must never begin with two hexadecimal digits that represent a 7-bit ASCII value (that is, two hexadecimal digits, the first of which is in the range 0-7). -
If the HTML delimiter is not
%
, then an occurrence of%
must be escaped if it is immediately followed by an octal digit and then a hexadecimal digit. It is recommended that other occurrences of '%' also be escaped; but this is not a requirement.
(You might choose to ignore this recommendation if you have existing template HTML files or configuration files created in prior releases, which use an HTML delimiter other than '%', and which contain '%' in runform parameter values).
Behavior in Previous Releases
Release 9.0.4 and later behave the same as the current release except that a quote must be escaped (%22) within the value of a runform parameter in a configuration file, and in the template HTML file.
Releases before 9.0.4 did not allow URL escape sequences in runform parameter values specified in the template HTML file or the configuration file (cases (1) and (2) above). In all three cases, it was difficult or impossible to specify certain special characters, notably space, quote, and apostrophe. Also, certain transformations were applied to the parameter value before passing it to runform. Most notably, if a value began and ended with an apostrophe, these were typically stripped off. However, these transformations were not well-defined, and they differed between the Web and client/server environments.
Obtaining the Behavior of Prior Releases in the Current Release
If your applications are dependent on the behavior of prior releases, you can obtain that behavior in the current release, by simply setting the value of the escapeparams
variable to False
in the configuration file (this can be accomplished using Fusion Middleware Control).
If you want to obtain the old behavior only for selected applications, you can specify different values for the escapeparams
variable in different configuration sections. Applications that require the old behavior can specify a configuration section in which the escapeparams
variable is set to False
; applications that require (or tolerate) the behavior in the current release can specify a configuration section in which the escapeparams
variable is set to True
.
Considerations for Template HTML Files
If you are creating your own template HTML files, consider the following:
It is recommended that a reference to the escapeparams
variable (the string %escapeparams%
, if '%
' is the HTML delimiter character) appear at the beginning of the value of the serverArgs
applet parameter, followed by a space. See the shipped base.htm file for an example.
References to the escapeparams
variable must appear nowhere else in the template HTML file. If you choose to enclose the value of the serverArgs
applet parameter in apostrophes instead of quotes, then within the value of a runform parameter in your template HTML file, apostrophes must be escaped (%27). Quotes do not require escape sequences.
It is permissible to omit the reference to the escapeparams
variable from the beginning of the value of the serverArgs
applet parameter. This results in the behavior of prior releases, regardless of the value specified in the configuration file for the escapeparams
variable.
Considerations for Static HTML Pages
Note:
The use of static HTML or JNLP is not recommended. It is recommended that all calls to Forms applications be routed through the Forms Servlet (frmservlet
). Not doing so may result in unpredictable behavior.
The basic rule is that your static HTML must look like the HTML generated by the Forms servlet. Specifically, the value of the serverArgs
applet parameter must begin with the string escapeparams=true
(case-insensitive).
Also, in the value portion of each name=value pair, in the value of the serverArgs
applet parameter, certain characters must be specified by a URL escape sequence, as listed in the following table.
Table -4 URL Escape Sequences for Static HTML pages
Characters that must be escaped | URL Escape Sequence |
---|---|
newline ' \n ' |
%0a |
space ' ' |
%20 |
quote ' " ' |
%22 |
percent ' % ' |
%25 |
apostrophe ' ' ' |
%27 |
left parenthesis ' ( ' |
%28 |
right parenthesis ' ) ' |
%29 |
It is also permissible to escape other 7-bit ASCII characters in the value portion of a name=value
pair.
Here's an example of what the serverArgs
applet parameter might look like in static HTML. This is for a form named "my form" (quotes not included), which is being passed the value "foo'bar" (quotes again not included) to the user-defined parameter named myparam
.
<PARAM NAME="serverArgs" VALUE="escapeparams=true module=my%20form userid=scott/tiger@mydb myparam=foo%27bar">
Client Configurations
Oracle Forms offers multiple client configuration options. Select an option based on your requirements.
formsweb.cfg
file.
Also, review Browser Considerations for information on browsers supported for the client configuration options.
Java Applet Embedded in HTML
This is the default configuration and gives the appearance that the Forms application (applet) is embedded in a web page.
This helps when the HTML content surrounding the Forms application contains related or integrated information. This can also be helpful when using the Forms JavaScript integration feature. Single sign-on and single sign-off are supported in this configuration.
To use this configuration, you require a Java Plug-in and a certified browser that supports the Java Plug-in.
Enter a URL in the browser, such as https://example.com/forms/frmservlet or https://example.com/forms/frmservlet?config=default.
Table -5 Parameters for Java Applet Embedded in HTML
Type | Parameters |
---|---|
Non-WebUtil Enabled Forms |
|
WebUtil Enabled Forms |
|
JNLP Embedded in HTML
Embedded JNLP is very similar to embedded Applet, however the application is treated more like a Java Web Start application although embedded within a web page.
Note:
Base-64 encoding is not a security mechanism.; it is used by Java and helps to improve delivery performance from server to client.For this configuration, you require a Java Plug-in and a certified browser that supports the Java Plug-in.
jnlp
) or create your own. https://example.com/forms/frmservlet?config=jnlp
Table -6 Parameters for JNLP Embedded in HTML
Type | Parameters |
---|---|
Non-WebUtil Enabled Forms |
|
WebUtil Enabled Forms |
|
Note:
When using Embedded JNLP, if the application uses custom jar files, for examplejacob.jar
, icons.jar
, or example.jar
add these to the extensions.jnlp
file. The file is stored in the ORACLE_HOME\forms\java
directory. Open this file in a text editor and add the needed entries based on the example included in the file. Each entry should be added on its own line.
Java Web Start
Java Web Start is considered a semi-browserless configuration.
The use of Java Web Start (JWS) gives an Oracle Forms application the appearance of a natively-installed application rather than a web app. This is because when running, the application is not contained within the boundaries of the browser. This is often desirable with Point of Sale applications where the only application used on the device is the POS application or in cases where the application is designed to use the full screen. Because this is typically a browser-less configuration,single sign-off events are not supported when using this configuration.
JavaScript integration support for JWS does not exist by default. However, JS integration can be enabled with a provided add-on and a third party library (Eclipse/Jetty). For more information, refer to Forms and JavaScript Integration for Java Web Start and Forms Standalone Launcher.
Unlike the functionality provided by the use of separateFrame=true
(available in the JNLP Embedded in HTML and Java Applet Embedded in HTML configurations only), the use of Web Start allows you to close the browser window used to call the application after it has started or not use a browser at all. Oracle Forms’ use of Java Web Start allows applications to be called from a browser using a hyperlink or by directly entering a URL. Alternatively, the application can be run from a JNLP file stored on the end-user machine. This method eliminates the need for a browser, except when the application is single sign-on protected. Java Web Start can also be used to call an Oracle Forms application from the command line. Although there are several variations of how Java Web Start can be used, if the application requires the use of single sign-on, it must be called from a browser. Attempts to call an SSO-protected application from a static JNLP file or the command line fail.
If calling from a browser, this configuration requires the Java Plug-in installed . If not calling from a browser, either the Java Plug-in or Java Development Kit (JDK) installation is required. A browser is optional and needed only if single sign-on is used.
To use this configuration, either use the provided example configuration (named webstart
) or create your own. The application can be called from a browser or you can use the command line or custom script.
jnlps://example.com/forms/frmservlet?config=webstart
https://example.com/forms/frmservlet?config=webstart
javaws “https://example.com/forms/frmservlet?config=webstart”
Note:
Thejnlp
and jnlps
protocols used in the examples are supported with Java 8u92+ on Microsoft Windows. Also, SSO is not supported when launching with the JNLP://
or JNLPS://
protocols.
Table -7 Parameters for Java Web Start
Type | Parameters |
---|---|
Non-WebUtil Enabled Forms |
|
WebUtil Enabled Forms |
|
Note:
When using Java Web Start, if the application uses custom jar files, for examplejacob.jar
, icons.jar
, or example.jar
add these to the extensions.jnlp
file. The file is located in the ORACLE_HOME\forms\java
directory. Open this file in a text editor and add the needed entries based on the example included in the file. Each entry should be added on its own line.
Forms Standalone Launcher
The Forms Standalone Launcher (also referred to as Standalone or FSAL) offers an alternative way for end-users to run Forms 12c applications. It provides a browser-less and modern interface.
Using FSAL provides the appearance and power of a native application. The application runs in its own window and is hosted on a centralized application server (for example, WebLogic Server). This ensures that the Forms application modules are securely stored on this remote middle tier server. Although the user does not have direct access to the Forms modules, such as FMX, MMX, PLX which are on the remote server, they can run these applications using a URL.
The use of FSAL offers the same functionality that is available when running a form in the browser, except event-driven single sign-off support is available when using a browser.
JavaScript integration support for FSAL does not exist by default. However, JS integration can be enabled with a provided add-on and a third party library (Eclipse/Jetty). For more information, refer to Forms and JavaScript Integration for Java Web Start and Forms Standalone Launcher.
Requirements
frmsal.jar
- This file is the Forms Standalone Launcher and should be stored on the end-user machine, preferably in the user’s home directory. Alternatively, the file can be stored in any other directory on the user’s machine as long the user has access to the directory. The file is staged on the server in theORACLE_HOME\forms\java
directory. The file can be transferred to the end-user machine using any suitable method (for example, web download, email, or ftp).This file is version-specific and cannot be used with other Forms versions or patch levels. A checksum is used to ensure that the launcher (
frmsal.jar
) file is properly matched to the server and its Forms’ version and that it has not been accidentally or maliciously replaced. As a result, you cannot use thefrmsal.jar
that was downloaded from a Windows server and use it to run an application against a UNIX server.FSAL can be used on Windows, Unix, Linux, or Apple Mac. Essentially, any platform that supports running Oracle Java.
All installations come with a usage page that illustrates how to use the launcher, as well as providing a download link for the
frmsal.jar
file. Administrators can disable, remove, or edit this page, as needed. Navigate tohttps://example.com/forms/html/fsal.htm
to display the page.- Java - FSAL is a Java application and therefore Oracle Java is required on the user’s machine. FSAL supports using any Oracle Java distribution that supports running a Java application and was certified with your version of Forms. Review the Fusion Middleware Certification Guide to ensure that the version you want to use is certified for use with the Forms version you are using.
Several possible Java distribution types are available for use. Depending on the application’s needs, the distribution you choose may vary. We recommend that you review the contents of the Oracle Java installation you choose and test your application thoroughly before moving to production. Here are distributions available for most common end-user platforms and can be used to run FSAL:
- JRE (Java Runtime Environment) - JRE installs most components needed for typical end-users. It includes everything needed to run a local Java application, as well as the Java deployment components, such as Java Web Start and Java Plug-in. Java deployment components may not be available in releases later than Java 8.
- JDK (Java Development Kit) - JDK is most appropriate for Java developers and typically includes more components than what a user needs. JDK includes JRE and other tools for developing, debugging, and monitoring Java applications.
- Server JRE (Java 8 only) - Server JRE is primarily used for deploying Java applications on servers. It includes tools for JVM monitoring and server applications, but does not include browser integration (the Java Plug-in), Java Web Start, auto-update, or an installer. This distribution is delivered as a zip file that needs to be manually extracted.
Running FSAL
To use this configuration, either use the provided example configuration (named standaloneapp
) or create your own. The application can be called from the command line or custom script. FSAL, like a browser, needs to know the location of the application you want to run. You must know the complete Forms application URL.
Note:
If using Java 11 with FSAL and the application uses the Forms audio support, addition configuration is required. On the user's machine complete the following steps:
- Download Java FX version 11+ from this page and extract the file.
- To run FSAL with audio support modify the start up command. Here is an example.
java --module-path <PATH TO JFX\lib> --add-modules=javafx.media,javafx.swing --add-exports=java.desktop/sun.swing=javafx.swing -jar frmsal.jar -url "<http://SERVER:PORT/forms/frmservlet?config=standaloneapp>"
Currently, the use of URL redirects or rewrites is not supported, but may be technically possible depending on the server configuration. FSAL expects to receive a fully qualified URL that points to the Forms environment. You can use a desktop shortcut, script file, or batch file instead of a hyperlink to start the application.
- Open a shell, for example DOS on Microsoft Windows and verify the needed Java version is installed.
java –version
The result should indicate the required Java version. If not, check if the system’s PATH is properly set.
- Switch to the user's home directory (or to the directory where the
frmsal.jar
file is stored) and execute the following command.java -jar frmsal.jar -url "https://<server>/forms/frmservlet?config=standaloneapp"
In the command, substitute <server> with your server details. Here is an example.
java –jar frmsal.jar –url “https://example.com/forms/frmservlet?config=standaloneapp” –t 30000
If the server is not running SSL and uses HTTP, you can omit http:// from the URL entry, as it will be assumed.
The application associated with the configuration section titledstandaloneapp
runs. You can use any configuration section that contains the entries found in the provided example.Note:
If using SSL/TLS, it may be necessary to import the certificate into the user's Java keystore before the application will run. - Output appears in the shell used to start the application. Ensure you keep the shell open through the life of the session because closing this shell will terminate the application.
Note:
This behavior can be altered to accommodate your needs using various shell commands and associated switches. Refer to the operating system documentation for information on using the command shell on your platform.
Command Line Arguments
Argument | Description |
---|---|
-url |
Represents the fully-qualified web address to the Forms environment, to include the configuration name. If config is not included, the default configuration will be used. Make sure you specify the URL within quotes (""). This is a required argument. |
-t |
Specifies the amount of time (in milliseconds) the launcher should wait for the server to respond before timing out. The value must be a whole number. This is an optional argument. Default: |
-showConfig |
Specifies whether to display the config parameters received from the server on the console.
This is an optional argument. Default: |
Browser Considerations
The following links provide information about client browser, Java version and the latest supported platforms. You can also view the Oracle Forms applications using Oracle Java Plug-in.
-
For Oracle Support, see
https://support.oracle.com
. -
For product certification requirement documents, see Oracle Fusion Middleware Supported System Configurations page.
-
For system requirement information, see Oracle Fusion Middleware System Requirements and Specifications document.
When a user requests an Oracle Forms application from a browser (for example, by clicking a link to the application's URL), the Forms servlet:
-
Detects which browser is being used.
-
Selects the appropriate baseHTML file using the following table:
Table -8 baseHTML file descriptions
Detected Browser Base HTML file used Internet Explorer
basejpi.htm
Mozilla FireFox
basejpi.htm
All other browsers and Macintosh clients
base.htm
-
Replaces variables (%variablename%) in the baseHTML file with the appropriate parameter values specified in the Forms
servlet.initArgs
file,formsweb.cfg
file, and from query parameters in the URL request (if any). -
Sends the HTML file to the user's browser.
Note:
Because only Internet Explorer supports the use of Java Plugin it offers the only client configuration that allows running Forms applications embedded in the browser. Other browsers can be used for launching applications configured to use Java Web Start.