Server class

Syntax

public class Server extends AgentryJavaBackEndManagedObject

Members

All members of Server, including inherited members.

Constructors Methods

Usage

The bulk of the methods within this class are factory methods for various other object types. If the designer overrides one of the classes constructed by these factory methods, a subclass of the Server class must also be created. This implementation must override the appropriate factory methods to construct objects of the appropriate type.

In addition to these factory methods, there are also methods related to login and logout, server startup and shutdown, and debugging. By default, these methods perform no application-related processing; they merely print a message to the debug log indicating that these events have or are about to occur. If additional processing is required for an application, these methods should be overridden in a subclass of the Server class.

When an Agentry Server with a Java System Connection is started, the server will construct a singleton instance of the Server class or a subclass of it, as specified by the serverClass setting in the Java system connection section of the Agentry.ini file. This Server object will persist until the Agentry Server is shutdown. If the designer has implemented an extension of the Server class, this new class must be named in the serverClass option in the Agentry.ini file in the section containing the configuration options for the Java Interface system connection.

Note, the constructor is public even though this class is a singleton. This is mainly for legacy reasons: the Agentry.ini file names a subclass of this class instead of naming a factory class, and we kept it that way rather than changing it to take a factory class name to maintain compatibility with AJAPI version 4 (since the server supports both versions of the AJAPI).

As such, in this version of the AJAPI, this class is not a strict singleton, although it should be treated as such. Applications should not try to create another instance of it, although it is acceptable (since it is hard to avoid) to do so in unit tests.

Eventually, this class will likely become a true singleton and the Agentry server will adopt the factory pattern to instantiate it, so you may wish to do so now in unit tests using a factory similar to:

public class ServerFactory
{
       private static class LazyHolder
       {
               private static final Server _instance = new Server();
       }

       public static Server getServerInstance()
       {
               return LazyHolder._instance;
       }
}

(Note, this example follows the "Initialization on Demand Holder" pattern; see this article on Wikipedia for information on how/why it works.)