EM: App Deployment > Applications
Overview and Background
In BBj 25.10 and higher, BBj offers users four options for deploying their applications from a
BBjServices server to a client computer. These deployment options—BUI Web Apps, DWC Web Apps, Desktop Apps, and now WebUI—are managed through the Enterprise Manager.
BUI Web Apps run in a browser using the BBj Browser User Interface (BUI).
DWC Web Apps run in a browser using the BBj Dynamic Web Client (DWC).
Desktop Apps run as thin client deployments through the BBj runtime.
WebUI, introduced in BBj 25.10, provides a modern, browser-based framework for delivering BBj applications with enhanced performance, session control, and streamlined configuration.
BUI Web Apps, DWC Web Apps, and WebUI are truly zero-deployment—the only technology or installation needed on a client computer is a compatible web browser; no Java or BBj installation is required there.
Starting in BBj 19.20, Desktop Apps provided 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 replaced 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 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 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. BUI Web Apps, DWC Web Apps, Desktop Apps, and WebUI applications are configured for a single interface via the Enterprise Manager. Each application offers configuration properties that apply generally to all deployment types, as well as properties specific to one or more. 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 App Deployment Tutorial.
Location
EM Navigator →
Web →
App Deployment →
Applications
Toolbar
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 EM : Web > App Deployment > Applications nodes in the navigator, then double-click Applications, the Applications pane shows on the right.
Applications
The Applications pane in Enterprise Manager provides a centralized interface for managing and monitoring deployed BBj web and desktop applications. It lists all registered application contexts along with their corresponding deployment types and operational statuses, including BUI Web App Status, DWC Web App Status, WebUI App Status, and Desktop App Status. Administrators can review application launch details, verify deployment states, access URLs, and confirm modification timestamps. Integrated with the App Deployment framework, this pane facilitates streamlined visibility into application availability, runtime behavior, and service connectivity across all BBjServices instances.
Applications Properties List
Application Launch Details Properties
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, which you can proceed
to fill in.
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 multiple versions of this app based on checked selections among BUI Web App Enabled, DWC Web App Enabled, WebUI App Enabled, and Desktop App Enabled.
The settings under the General category apply to all deployment options.
The settings under BUI/DWC Only, Desktop Only, and WebUI Only apply to specific deployment options.
General App Deployment
The General App Deployment controls core launch/runtime for a shortcut: Application Name, Program/Config files, Working Directory, default or explicit Interpreter User (-u), Host/Port overrides, Classpath, Program Arguments, Shortcut Name/Description/Image/Load Image, Quiet mode, and enablement flags for BUI, DWC, WebUI, and Desktop apps.
General App Deployment Properties List
| Settings | Description | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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. |
|||||||||||||
|
Displays the main executable or program file for the application. Click |
|||||||||||||
|
Displays the config file that
the application should use. Leave blank to use the default config.bbx. Else click |
|||||||||||||
|
Displays the server
directory in which BBj will start. Leave blank to use the default
working directory. Click |
|||||||||||||
| Use Default Interpreter User |
|
||||||||||||
|
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 |
||||||||||||
| 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 |
||||||||||||
|
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
|
|||||||||||||
|
User-defined command line arguments, accessed with ARGC and ARGV().Click the |
|||||||||||||
|
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. |
|||||||||||||
|
Enables adding a brief explanation or descriptive text for the application's shortcut. |
|||||||||||||
|
Enables selecting a custom icon file to visually represent the application's shortcut. The dropdown offers predefined images, while the Note: Large images can negatively affect load time. |
|||||||||||||
|
Enables to select an image to be displayed as a splash screen or loading indicator when the application starts. Clicking Note: Large images can negatively affect load time. |
|||||||||||||
|
|||||||||||||
|
|||||||||||||
| DWC Web App Enabled |
|
||||||||||||
| WebUI App Enabled |
Note: WebUI is a premium, licensed feature and isn’t available by default. |
||||||||||||
| Desktop App Enabled |
|
BUI/DWC Only
The BUI/DWC Only section contains configuration properties specific to BUI and DWC applications in the browser.
BUI/DWC Only Properties List
| Settings | Description | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Note: This setting is Obsolete. |
|||||||||||||
|
Displays whether a confirmation prompt appears before closing an application window or tab, preventing accidental data loss.
Note: Desktop browsers only show this warning if the user has interacted with the page. Mobile browsers never show this warning. See: beforeunload event. |
|||||||||||||
|
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.
|
|||||||||||||
|
Disallow console access. This is recommended for end-user applications.
|
|||||||||||||
|
The alias of a terminal specified in the configuration file. FID(0) will return this alias in the Thin Client program. See: command line. |
|||||||||||||
|
BUI normally suppresses the default browser handling for function keys F1-F24. When development mode is set, BUI allows the normal browser handling for those keys to take effect. See: BBjAppServer::setDevelopmentMode.
|
|||||||||||||
|
Run BUI Web 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.
Note: This setting is intended for specialized applications. Significant BUI behavior is controlled by the default CSS; omitting it will break most applications. |
|||||||||||||
|
The optional custom CSS file for the BUI Web App to apply interface styling. Clicking the |
|||||||||||||
|
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. |
|||||||||||||
|
Specifies the operational context or environment in which the web application will run, with root being a common default. See: Context Configuration.
|
|||||||||||||
| 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
|
||||||||||||
| 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. | ||||||||||||
| End Action |
Dropdown selecting termination action: NONE, DEFAULT, URL, APP, MESSAGE. DEFAULT follows configuration. URL redirects to address, APP launches app, MESSAGE shows text, NONE does nothing. See: BBjBuiCloseAction. |
||||||||||||
| End Application | Designates the application-name to launch when End Action: APP is selected; if blank, no additional application executes at session end. | ||||||||||||
| End Message | Specifies the text to present to the user when End Action: MESSAGE is selected, replacing the standard termination outcome with that message. | ||||||||||||
| End URL | Specifies the redirect address when End Action: URL is selected; the session navigates to this URL after termination. | ||||||||||||
| Error Action |
Controls how the BUI/DWC session behaves when an error occurs, inherit default action, perform no action, redirect, launch application, or display a message. See: BBjBuiCloseAction.
|
||||||||||||
| Error Application | Specifies the application to launch when Error Action: APP is selected; if left blank, no application will be triggered upon error. | ||||||||||||
| Error Message | Provides the custom text shown to the user when Error Action: MESSAGE is selected, replacing the default error notification display. | ||||||||||||
| Error URL | Specifies the web address for redirection when Error Action: URL is selected; session ends and client navigates to that URL. |
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 List
| Setting | Description | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
Enables passing additional parameters to the Java Virtual Machine (JVM) when the application runs. The |
|||||||||
| 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. |
||||||||
|
Enables selecting the Java Runtime Environment (JRE) version for applications running on 64-bit Linux systems. The <default>, indicating that the system uses the globally configured JRE if no custom package is assigned. Clicking the |
|||||||||
|
Enables selecting the Java Runtime Environment (JRE) version for applications running on 64-bit Windows systems. The <default>, indicating that the system uses the globally configured JRE if no custom package is assigned. Clicking the |
|||||||||
|
Enables selecting the Java Runtime Environment (JRE) version for applications running on 64-bit macOS systems. The <default>, indicating that the system uses the globally configured JRE if no custom package is assigned. Clicking the |
|||||||||
| macOS aarch64 JRE |
Enables selecting the Java Runtime Environment (JRE) version for applications running on 64-bit macOS (Apple Silicon) systems. The <default>, indicating that the system uses the globally configured JRE if no custom package is assigned. Clicking the |
||||||||
|
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. |
|||||||||
|
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 .
|
||||||||
|
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>. |
|||||||||
|
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. |
|||||||||
|
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. |
|||||||||
|
Specifies the look and feel the BBj session uses. Valid options are:
|
|||||||||
| Standalone JVM |
|
||||||||
|
|||||||||
|
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. |
|||||||||
|
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 |
|
||||||||
| Create Shortcut |
|
||||||||
| Display Load Image |
|
||||||||
| Display Load Text |
|
||||||||
| Run After Install |
|
||||||||
| Display Run Message |
|
||||||||
| Use Socket Compression |
|
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:
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 EM: Web > App Deployment > Applications.
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 |
WebUI Only
The WebUI Only section defines configuration properties exclusive to BBj WebUI applications, controlling runtime display, virtual display setup, and secure communication for headless or browser based execution. The section includes options such as Java arguments, terminal designation, connection parameters, and user credentials. This section references key BBjServices properties including webui.enabled, webui.display, and webui.virtualdisplay.prog, which determine whether BBjServices runs in graphical or headless mode. When the DISPLAY environment variable is not set, BBj automatically invokes xheadless/xvfb to create a virtual display, ensuring proper WebUI initialization on UNIX and AIX platforms. By default, xheadless is used on Linux systems and xvfb on AIX. Note that xheadless requires glibc 2.18 or later; on older Linux distributions using glibc 2.17, administrators must set the WebUI Virtual Display Program to xvfb using /usr/bin/xvfb-run. On UNIX systems, this section visually displays configuration fields such as WebUI Enabled, WebUI Context Mapping, WebUI Display, and WebUI Virtual Display Program, providing administrators with clear control over headless WebUI operation and system-level display handling. See: Global Settings.
WebUI Only Settings List
| Settings | Description | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Java Arguments |
Enables passing additional parameters to the Java Virtual Machine (JVM) when the application runs. The |
||||||||
| 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. |
||||||||
| 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. |
||||||||
| Goodbye URL |
Specifies the endpoint that BBjServices redirects to when a WebUI session ends. Used for session termination and user redirection after logout. This setting applies to all supported platforms and is not related to DISPLAY or xheadless/xvfb configuration. Accepts the following values:
|
||||||||
| 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.
|
||||||||
| 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. | ||||||||
|
Specifies the look and feel the BBj session uses. Valid options are:
|
|||||||||
| TCPS Preload |
|
||||||||
| 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 |
|
Other settings
Some less common Desktop App settings can be set via the following environment variables on the client machine:
Servers
Servers