Enterprise Manager logoEM: App Deployment > Applications

Overview and Background

In BBj 19.20 and higher, BBj offers users two options for deploying their applications from a BBjServices server to a client computer. These App Deployments are set up and managed through the Enterprise Manager, where BBj applications can be configured as a Web App for execution in a browser as a Browser User Interface (BUI) deployment, as a Desktop App for execution as a BBj thin client deployment (replacing Java Web Start), or as both. Both Web Apps and Desktop Apps can be run from hyperlinks that are found on BBj’s Jetty Home Page.

Web Apps have been available in BBj for a number of years, and rely upon the BUI technology in BBj. Web Apps are truly zero deployment—the only technology or installation needed on a client computer is a compatible web browser; no Java or BBj is required there.

Starting in BBj 19.20, Desktop Apps provide a near-zero deployment strategy for running BBj applications on a client desktop computer. Since Java Web Start is no longer supported in Java 11+, Desktop Apps are intended to replace Java Web Start (JNLP) Applications for deploying desktop applications. They provide a straightforward system for deploying BBj applications that overcomes many of the limitations of Java Web Start.

In Desktop Apps, the client-side experience is particularly streamlined, with no configuration necessary on the desktop to run the app. The client computer does not even need a BBj installation! MacOS and Linux clients do require Java, while Windows clients do not need either BBj or Java. The URL for a Desktop App provides a download of a small, self-contained launcher program that connects to the server, downloads the Java Runtime Engine (JRE) required by the server, downloads the BBj program and any necessary BBj classes, launches the BBj program, and updates as necessary each time the program is run.

The server-side App Deployment experience is also streamlined. Web Apps (BUI) and Desktop Apps are configured for a single application via the Enterprise Manager. Each application offers configuration properties that apply generally to both Web and Desktop Apps, as well as properties that are specific to one or the other. The Java Runtime Engine (JRE) list gives you full control over which JRE your app should use, and JREs can be added for Windows, Linux, and macOS clients. The URLs for each enabled application appear on the Jetty Home Page, and can also be provided to users directly.

For additional information, see the App Deployment Tutorial.

Location

Enterprise Manager logoEM Navigator → Web → App Deployment → Applications

Toolbar

Button Function
Adds a new entry and opens new application.
Modifies the configuration or details of a selected application.
Duplicates the configuration or data of a selected application.
Removes/deletes selected application(s) or files from the system.
refresh button Refreshes the displayed list of applications and their status.
Navigates up one level to the parent directory from the current folder.
Creates a new folder within the currently displayed directory.
Enables to choose a folder/file from your local system.

Desktop Apps

Comparison to Java Web Start

Java Web Start was a generic solution designed to work for many different use cases, so it was not always optimal for BBj. Because Desktop Apps are designed with BBj Applications in mind, they are able to provide several advantages over Java Web Start, and overcome some of Web Start’s limitations. The table below compares the Java Web Start and Desktop App technologies.

Comparison of Java Web Start and Desktop Apps Solutions Table

Java Web Start Limitations

Desktop Apps Solutions
Web Start required the creation and management of the JNLP, which could be complicated and included many settings that are not needed or used for BBj applications.  Desktop Apps only expose settings that BBj applications may need, and can share some application specifications with Web Apps.
A Web Start security certificate had to be generated and included when running the application. A Web Start security certificate is no longer needed.
JARs had to be signed before being downloaded to client. JARs are no longer sent to the client (just classes), so there is no longer a requirement for JAR signing.
Clients needed a Java Web Start (javaws) program, which was installed as part of Java 8 and earlier. No existing launch program necessary, just Java.
Invalid client configuration could prevent application from working. No client configuration needed.
Cache could prevent execution, and had to be cleared on client. No cache for the user to clear.
Application startup included validation of JARs in cache and downloading JARs from server. Desktop Apps utilizes the new ClassLoader to optimize the download of necessary classes (not JARs) and files at run time.

Comparison to JNLPExePacker

The JNLPExePacker was designed to be an interim solution to mitigate the loss of Java Web Start until the final Desktop Apps solution could be developed. It is a BBj program, installed and run via the pluginmanager program, which creates a native Windows/macOS/Linux application given a JNLP application and a JRE. It takes advantage of the new ClassLoader in BBj 19.10 and higher to dynamically download needed classes and files to the client.

The JNLPExePacker had several limitations. The JNLP application had to exist before native application generation, which is problematic because JNLP and Web Start apps are going away. Additionally, any update in the JNLP, BBj, or JRE required regeneration and redeployment of the native applications.

Creating a Desktop App

To deploy a Desktop App, first open the Enterprise Manager. Expand the Web > App Deployment > Applications nodes in the navigator, then double-click Applications. Figure 1 shows resulting Applications tab in the EM.

Figure 1: Desktop Apps Configuration in Enterprise Manager

Applications Properties

Column Description
Name Displays the application's name, often click-able to view more details.
BUI Web App Status Displays the current status of the application when accessed via Browser User Interface (BUI).
DWC Web App Status Displays the current status of the application when accessed via Dynamic Web Client(DWC).
Desktop App Status Displays if desktop applications are running, stopped, or not deployed.
Modified Displays when an application was last changed, allowing you to sort and find recently updated ones.

Application Launch Details Properties

Column Description
Type Displays the category or main way to launch an application, such as Web URL or Desktop Shortcut.
URL Displays the direct web address or link needed to access or launch the application.

The icons, located in the Enterprise Manager UI's Applications and Properties action bar, provide quick, consistent control for managing your application portfolio, including adding, modifying, duplicating, removing, refreshing, navigating, and adding folder.

Click button at the top right of the section to add a new App. This will open Applications properties window as shown in Figure 2, which you can proceed to fill in.

Figure 2: Creating a new Desktop App, General Properties

Enter a unique name for your App, and select the BBj program file to run. Optionally, you may specify a Config File, Working Directory, the application's Interpreter User, Classpath, along with any Program Arguments needed.

BBj will publish this app as a Desktop App if Desktop App Enabled is checked. Similarly, it will publish this app as a Web App (runnable in a browser) if Web App (BUI) Enabled is checked.

If you selected Web App (BUI) Enabled, expand the Web App Only section to review the settings that are specific to Web Apps (as shown in Figure 3).

The settings under the General category apply to both Web and Desktop Apps (See Figure 2).

General App Deployment Properties

Setting Description

Application Name

Displays name of the application, this name must be unique in order to create a unique URL for the App. It should not contain any special characters that affect URL parsing, such as spaces, slashes, curly brackets, %’s, or #’s.

Program File

Displays the main executable or program file for the application. Click to browse and select the file from your local system.

Config File

Displays the config file that the application should use. Leave blank to use the default config.bbx. Else click to select file from your local system, or click to create a new folder .

Working Directory

Displays the server directory in which BBj will start. Leave blank to use the default working directory. Click to select file from your local system, or click to create new folder. See: command line.
Use Default Interpreter User

  • When Unchecked, this enables you to manually specify a different user account in the Interpreter User (-u) field for the application to run under.

  • When Checked, the application will automatically use the current desktop user's credentials or context as the interpreter user.

Interpreter User (- u)

Enables you to specify a particular user account under which the application's interpreter will run.
Host Override

Displays the host used by the desktop application client to connect to Jetty. If undefined, the host will be the Hostname defined for the Web server. To manage servers, select BBjServices > Servers.
Port Override

Displays the port number used by the desktop application client to connect to Jetty. If undefined, the port will be the HTTP Port defined for the Web server. To manage servers, select BBjServices > Servers.

Classpath

Displays the session-specific classpath, which tells the Java Virtual Machine (JVM) where to find necessary class files and libraries for the application. Users can select <default> to use the system's global settings, or choose from other predefined options like addon,barista, basisdemos, and bbj_default to apply specific library paths. See: BBjServices > Java Settings

Value Description
<default> Uses the system's pre-configured global classpath settings for the application.
addon Classpath includes addon components or extensions for the application.
barista Classpath containing libraries or resources specific to a barista framework or application.
basisdemos Classpath includes files or examples provided by BASIS.
bbj_default Sets the default classpath specifically tailored for BBj applications.

Program Arguments

User-defined command line arguments, accessed with ARGC and ARGV().Click the button to add and click button to remove program arguments.

Shortcut Name

Displays the name for the application's shortcut, typically appearing on a desktop or in a menu. It provides a user-friendly label for quick access.

Shortcut Description

Enables adding a brief explanation or descriptive text for the application's shortcut.

Shortcut Image

Enables selecting a custom icon file to visually represent the application's shortcut. The dropdown offers predefined images, while the icon allows uploading new ones. See: Resources.

Note: Large images can negatively affect load time.

Load Image

Enables to select an image to be displayed as a splash screen or loading indicator when the application starts. Clicking button enables to upload new images. Resources.

Note: Large images can negatively affect load time.

Quite

  • When unchecked, user prompts and interactions are displayed during application installation or execution.

  • When checked, enables silent mode, suppressing all user interaction and prompts during installation or execution. See: command line.

BUI Web App Enabled

  • When unchecked, the application cannot be accessed through the Browser User Interface (BUI).

  • When checked, enables application access and deployment via the Browser User Interface (BUI).
DWC Web App Enabled

  • When unchecked, the application cannot be accessed through the Dynamic Web Client (DWC).

  • When checked, enables the application's deployment and access via the Dynamic Web Client (DWC), allowing it to run in a supported web browser.
Desktop App Enabled

  • When unchecked, the application cannot be installed or executed as a desktop application.

  • When checked, enables the application to be installed and run directly on a desktop operating system.

Figure 3: Web App Only

Web App Only

The Web App Only section contains settings specific to browser-based BBj applications. These options allow developers to control browser behavior, user experience, and application styling during Web App deployment. Properties like Show Browser Warning, Show Confirm Close Dialog, and Manage Browser History help manage how users interact with the app in a browser. Other settings, such as Omit BASIS CSS and CSS, provide control over the app's visual presentation. Additionally, network and security configurations like Secure TC Connection, Remote Host, and Remote Port help define the app's runtime environment.

Web App Only Properties

Setting Description

Show Browser Warning

Displays whether a warning message is displayed within the browser for the web application, alerting users to specific conditions or behaviors.

Value Description
<default> Uses the system's pre-configured global setting for showing a browser warning.
false Explicitly disables any browser warning messages for the application.
true Explicitly enables the display of a browser warning message for the application.

Show Confirm Close Dialog

Displays whether a confirmation prompt appears before closing an application window or tab, preventing accidental data loss.

Value Description
<default> Configures the application to use its pre-defined, standard behavior for displaying a close confirmation dialog.
false Disables the confirmation dialog, allowing the application or window to close immediately without a prompt.
true Enables the confirmation dialog, requiring user confirmation before the application or window closes.

Manage Browser History

BUI apps tend to be stateful; data can be lost if the user accidentally presses the browser 'back' button. When this mode is set, BUI manages browser history and the 'back' button.

See: BBjAppServer::setManageBrowserHistory.

Value Description
<default> Configures the application to use its pre-defined, standard behavior for managing browser history.
false Disables the application's management of browser history, browsing activity will not be recorded.
true Enables the application to manage browser history, allowing it to record and utilize browsing activity.

Disallow Console

Disallow console access. This is recommended for end-user applications.

Value description
<default> Displays that the console's accessibility or output behavior is determined by the system's pre-configured settings.
false Permits full access to the console and enables its functionality.
true Restricts access to the console or disables its output.

Terminal

The alias of a terminal specified in the configuration file. FID(0) will return this alias in the Thin Client program. See: command line.

Development Mode

BUI normally suppresses the default browser handling for function keys F1-F12. When development mode is set, BUI allows the normal browser handling for those keys to take effect. See: BBjAppServer::setDevelopmentMode.

Value Description
<default> Displays that the application's behavior for Development Mode is determined by its pre-configured system settings.
false Optimizing the application for production use by prioritizing performance and security while minimizing debugging features.
true Activating features designed for rapid iteration, testing, and debugging, which may impact performance and security.

Omit BASIS CSS

Run BUI apps without the default BASIS CSS. By default, BUI apps are deployed with a complex CSS file defining detailed rules for each BBjControl. When this mode is set, that default CSS file is omitted, and the developer is responsible for providing all necessary CSS rules.  See: BBjAppServer::setOmitBasisCSS.

Value description
<default> Uses the system's pre-configured global setting for omitting BASIS CSS.
false Explicitly ensures that the default BASIS CSS is included in the application.
true Explicitly omits (excludes) the default BASIS CSS from the application.

CSS

The optional custom CSS file for the Web App (BUI) to use. This custom CSS is applied last, providing the ability to override CSS entries in either the GWT or BASIS CSS files. See: Resources

Client Response Timeout

Sets the length of time in seconds a non-responsive BUI session will be considered active. If the session expires without response, the web tier will send a NET_DROPPED error back to the server. A value of -1 means no timeout. The default value is 300.

Context

Specifies the operational context or environment in which the web application will run, with root being a common default. See: Context Configuration.

Value Description
root Sets the application to the default or base web context, making it accessible directly from the server's root URL.
GoldMine Sets the application's context to GoldMine, indicating it will be accessed via a URL path segment of that name.
htdocs Sets the application's context to htdocs.
BBJSP Sets the application's context to BBJSP, typically used for applications utilizing BASIS BBj Server Pages.
Secure TC Connection

Enables to set the application's Thin Client (TC) communication to use the system's pre-configured global setting (<default>), explicitly disable it false, or explicitly enable a secure encrypted connection true. See: BBjAppServer::setSecure

Value Description
<default> Enables system's pre-configured global setting for establishing a secure Thin Client Connection.
false Disables a Secure Thin Client Connection for the application.
true Enables a secure encrypted Thin Client Connection for the application.
Remote Host The hostname or IP address of a remote server that the web application connects.
Remote Port Displays the port number on the remote host that the web application will use for its connection.

Figure 4: Desktop App Only Properties

Desktop App Only

The Desktop App Only section provides configuration options specific to deploying and running BBj desktop applications. It allows you to define Java Arguments, select platform-specific JREs (Linux, Windows, macOS), and configure network settings such as Remote Host and Ports. Options like Standalone JVM, Socket Compression, and Look and Feel give further control over how the desktop app runs and communicates. Additionally, settings like Create Shortcut, Display Load Image, and Display Run Message enhance the end-user experience during app startup. These configurations ensure the desktop application is optimized, portable, and tailored for the target platform and network environment.

Desktop App Only properties

Setting Description

Java Arguments

Enables passing additional parameters to the Java Virtual Machine (JVM) when the application runs. The and icons enable adding or removing/deleting arguments.

Terminal

Enables the alias of a terminal specified in the configuration file. FID(0) will return this alias in the Thin Client program. See: command line.

Linux x64 JRE

Enables selecting Java Runtime Environment (JRE) version for the application to run on 64-bit Linux systems. The icon enables adding new JRE configurations.

Windows x64 JRE

Enables selecting Java Runtime Environment (JRE) version for the application to run on 64-bit Windows systems. The icon enables adding new JRE configurations.

macOS x64 JRE

Enables selecting Java Runtime Environment (JRE) version for the application to run on 64-bit macOS systems. The icon enables adding new JRE configurations.
macOS aarch64 JRE Enables selecting Java Runtime Environment (JRE) version for the application to run on 64-bit macOS (Apple Silicon) systems. The icon enables adding new JRE configurations.

Name (-a)

Associates text with SysConsole settings so that window size, font, and position are saved when the session ends and restored when the SysConsole is launched using the same text. Equivalent to using the Application User (-n) setting. See: command line.

Application User (-n)

Associates arbitrary text with the SysConsole settings, saving window size, font, and position at session end and restoring them when the SysConsole is launched with the same text. Equivalent to using the Name (-a) setting. See: command line.
Secure TC Connection

Enables to set the application's Thin Client TC communication to use the system's pre-configured global setting (<default>), explicitly disable it false, or explicitly enable a secure encrypted connection true. See: BBjAppServer::setSecure

Value Description
<default> Uses the system's pre-configured global setting for establishing a secure Thin Client Connection.
false Disables a secure Thin Client Connection for the application.
true Enables a secure encryptedThin Client Connection for the application.

Remote Host

Specifies the machine name or IP address of the server on which the ThinClientServer (TCS) or SecureThinClientServer (STCS) if using the -SC argument resides. The BBj process connects to the ThinClientProxyServer (TCPS) on the local machine (refer to -LP<local port number>). The TCPS connects to the TCS (or STCS) on the machine specified by this argument using either the default port or the port specified with the option -RP<remote port number>.

Remote Port

Specifies the ThinClientServer's (TCS) port on the remote machine. The BBj process connects to the ThinClientProxyServer (TCPS) on the local machine (see -LP<local port number>). The TCPS makes the connection to the remote machine (specified with the -RH<host name> argument) using the remote port number. If no remote port number is specified, the default port, 2003, is used. When using the -SC flag, the TCPS connects to the SecureThinClientServer (STCS). The STCS default port is 2103. The ports used by TCS and STCS can be changed using Enterprise Manager.

Local Port

Specifies the Port Request Server's (PRS) port. The BBj process connects to the PRS to get the appropriate port to use to connect to the ThinClientProxyServer. By default, the PRS uses port 2008. The PRS's port may be changed using the Enterprise Manager.

Look and Feel

Specifies the look and feel the BBj session uses. Valid options are:

  • default - uses the look and feel of the native operating system; Windows look and feel when running Windows; Mac look and feel running on a Mac, "cross" for cross-platform, etc. For example: bbj -Lfdefault
  • cross - uses the default Java look and feel; "ocean" in JVMs 1.5 and higher, and "metal" in JVMs prior to 1.5.
  • none - do not attempt to set or change the look and feel in any way. This is intended for use with a launcher program such as skinit, which sets the look and feel before BBj is started.
  • skinlf:theme (deprecated) - use the skinlf.jar look and feel.

    You may use a filename or a URL to specify the specific theme, but you must use forward slashes for the path separator regardless of platform. For example, to use a file:

    bbj -LFskinlf:themepack.zip

    To use a URL:

    bbj -LFskinlf:http://mydomain.com/themepack.zip

  • vpro5 - emulates the Visual PRO/5 look and feel on all platforms, regardless of operating system.
Standalone JVM

  • When unchecked, the Desktop Application will share JVMs with other Desktop Application and BBj Thin Clients.

  • When checked, a new JVM will be started for the Desktop Application.

TCPS Preload

  • When unchecked, The BBj process does not perform a TCPS Preload.

  • When checked, BBj checks for a PortRequestServer or ThinClientProxyServer on the specified user/host/display. If none is found, it starts a TCPS process without launching an interpreter or checking out a license.

TCPS Timeout

If the TCPS is started by this invocation of the BBj process, this value is passed to the TCPS as the "death wait" timeout.

The death wait timeout is how long the TCPS stays up with no clients connected before terminating.

This can be used to keep the TCPS up and running so it is not restarted each time a new BBj session is started.

This overrides the property com.basis.bbj.comm.ThinClientProxyServer.waitTime

found in the BBj.properties file. This allows the timeout to be set differently for individual TCPS's.

The wait time for the first client connection is 5 minutes and 1 millisecond, even if this value is set to a shorter time. If this value is higher than 5 minutes and 1 millisecond, the higher value is used.

TCPS Heartbeat

In BBj 17.00 and higher, if the TCPS is started by this invocation of the BBj process, this value is passed to the TCPS as the "heartbeat" timeout.

The heartbeat timeout is used by the TCPS to check the status of the ProxyManagerServer (PMS). If the PMS goes down, then the TCPS shuts down. Normally, the PMS is started as part of BBjServices, so when BBjServices is shutdown the PMS is also shutdown.
Debug

  • When unchecked, debugging is disabled; the application runs without additional diagnostic output.

  • When checked: enables debugging mode, providing extended logging for development and issue resolution.
Create Shortcut

  • When unchecked, no desktop shortcut is created during application installation.

  • When checked, automatically creates a desktop shortcut for the application upon installation.
Display Load Image

  • When unchecked, the loading image is not displayed during application startup, resulting in no visual feedback.

  • When checked, screen or loading image is displayed, providing users with visual feedback while the application initializes.
Displayed Load Text

  • When unchecked, no loading text is shown during the application's startup.

  • When checked, displays message that provide feedback during the application's loading process.
Display Run Message

  • When unchecked, runtime status messages are not shown during application execution.

  • When checked, displays messages reflecting the application's runtime activity.
Use Socket Compression

  • When unchecked, socket communication occurs without data compression.

  • When checked, enables GZIP compression for socket communication to reduce bandwidth usage and improve transmission efficiency

Running a Desktop App

Every BBj installation includes a Jetty Start Page, which now includes a list of Web and Desktop Apps. The Jetty Start Page can be accessed with the following URL, replacing localhost:8888 with the appropriate host and port number if BBj is not running locally:

http://localhost:8888/basisindex.html

The Jetty Home Page displays a list of all available Web and Desktop Apps, as shown in Figure 5:

Jetty Home page

Figure 5: Web and Desktop Apps on the Jetty Home Page

Clicking the hyperlinked app name will run or download the app.

These URLs can also be found by selecting the app name under Web > App Deployment > Applications as shown in Figure 6:

Figure 6: Web and Desktop App URLs in the Enterprise Manager

Each Web App URL runs the browser-based version of an application, and abides by the Web App Only settings.

Each Desktop App URL downloads a single executable JAR called <appname>launcher.jar, which is a self-contained launcher program. It contains the launcher Java program, the JRE information, and the Desktop app information. 

When the launcher JAR is run, it creates a native application to run the BBj program which is used for subsequent Desktop App invocations (either a Windows native EXE, a macOS Mac App, or a Linux shell script). It then runs the native application.

When it creates the native application, it creates an install directory under <User Home> on Windows and Linux or under /Applications on macOS. It then downloads and extracts the specified JRE for the App into the installation directory. Note that because one app per client is the norm with Desktop Apps, JRE sharing is not supported. 

The native application will be created in the following format:

OS Format

Windows

<userhome>\<appname>\bin\<appname>.exe

Linux

<userhome>/<appname>/bin/<appname>.sh

macOS

/Applications/<appname>.app

Other settings

Some less common Desktop App settings can be set via the following environment variables on the client machine:

Other Settings Table

Environment Variable Description
BBJ_CACHE_DIR

Set this to a directory to use the specified directory for the cache, rather than the default directory.

The default cache locations for different platforms are listed below:

  • Windows: From the environment LOCALAPPDATA , or APPDATA in the Local subdirectory. If these are not set, then the default is: ~/AppData/Local

  • Mac: ~/Library/Caches

  • Other: ~/.cache
BBJ_CACHE_SHARED

In BBj 22.00 and higher, this setting can set the permissions on the cache files to be readable and writable by all users, allowing multiple users to share a cache directory. This can help save disk space if multiple users are using desktop apps on the same machine.

  • true = Creates and stores the cache in a directory named remoteclassloader-shared.

  • false = Stores the cache in a directory named remoteclassloader-<user>. This is the behavior by default.
BBJ_PRELOAD_JAR_DIR

Defines a preload JAR directory for the internal classpath. The Desktop App classloader looks for JARs in this directory and preferentially uses any classes that are already on the client before dynamically downloading them from the server to cache separately.

When using an SSCP, the classloader looks in this directory for a subdirectory with the same name as the SSCP, and uses that directory as the preload JAR directory.

The default location for this directory is remotelauncher.<user>/jars.
BBJ_REMOTE_CLASSLOADER_LOGGING=cache Setting this environment variable will enable logging for when classes are loaded, and whether they come from "PRELOAD JAR" or "CACHE".

Summary

As of BBj 19.20, Deployment Apps offer you two choices of how to deploy your BBj programs to client computers:

  • Web Apps (for GUI BBj programs running in a web browser as BUI apps)

  • Desktop Apps (as BBj thin client programs, replacing the Java Web Start remote deployment)

These deployment options are managed from the Enterprise Manager, under Web > App Deployment.

See Also

BBjAdminBase

EM: App Deployment > Desktop App JREs

EM: App Deployment > Global Settings

EM: App Deployment > Demos