Making applications headless
When creating headless applications, you should include a System exit in your project’s main ENVY Application. You can use the System exit either in the Application itself or in the Application Entry Point startup code. The System exit lets the runtime environment know that the user application is finished processing.
For Linux (UNIX):
The traditional and standard lightweight sysadmin graceful process termination mechanism on UNIX platforms has long been the sending of a SIGTERM signal. When the Smalltalk virtual machine receives this signal, it causes the directed message residing in the class variable TerminateMessage of the class EmSystemConfiguration to be sent. By default, this will execute System exit. You can override this behavior to add shutdown code that is specific to your Smalltalk application by executing System terminateMessage: yourDirectedMessage. Typically, when you customize your own TerminateMessage, its last statement will be System exit.
Use the UNIX kill command line utility to send the SIGTERM signal to your Smalltalk process. The kill command needs only one argument when sending SIGTERM -- the process ID (pid) of the process to be signalled. The Smalltalk VM will print out its pid to the standard output stream when it comes up. For example, if the pid of your Smalltalk VM is 12345, you can gracefully bring this VM down from a UNIX shell prompt with the command:
kill 12345
Because only headless applications can run in the native server environments, you must make or modify your server applications so they contain no Smalltalk code or VA Smalltalk visual parts which provide a UI.
This means that your server applications cannot have UI Applications as prerequisites. Examples of UI Applications are AbtRunViewsApp and CommonWidgets.
When you create an ENVY Application in the Organizer, it will name AbtViewApplication as a prerequisite. If you intend to package this Application with the Server Workbench feature, you must change the prerequisite to AbtRunPartsApp. By doing so, you can only create nonvisual parts, Smalltalk classes, and Smalltalk extensions in your Application. Attempting to use visual parts will result in messages to the Transcript indicating undefined references to Applications outside the prerequisite chain.
Surprisingly, you can use AbtPromptersApp as a prerequisite because it can adapt itself to a headless environment.
This also means that your server applications cannot contain code that provides a UI.
Obtaining user input
Because your server applications must be headless, they must obtain any input from users through means such as the following:
• From client code
• From environment variables
• From command line parameters
• From a web page
• From an .ini file (see information on abt.ini in the Programmer Reference)
Generally, your server applications will obtain user input from client code. To obtain such input, your server applications must provide interfaces that let client applications supply any needed information to your server applications.
Externalizing strings for translation
If you intend to translate your server applications, you must also externalize strings in your Smalltalk code. To do this, follow the steps outlined in materials on National Language Support (NLS) in the Visual Programming User Guide and the Programmer Reference. The steps explain how to add methods such as abtExternalizedStringBuildingInfo to a Application subclass, build message and pool repository (.mpr) files, and bind image strings using menu choices available from the NLS menu choice of the Transcript's Tools menu.
When packaging server applications which use .mpr files, you may want to remove externalized strings from the .mpr files and include them in the packaged image.
Do this during packaging at the Modify Instructions step, by selecting the Dumper policy type from the Policies panel. For more information on packaging, see Packaging a Smalltalk image.
Last modified date: 07/24/2020