Extension Loading and Start-Up/Shut-Down Process

Extensions are sophisticated so it’s important to describe how they are loaded and the order in which various components will execute.

Each extension is loaded with its own classloader as part of the overall classloader hierarchy to ensure separation between extensions and the server.  On the surface, this may seem an unnecessary complexity, but it provides the most flexibility and convenience for extension developers.  For instance, by using a separate hierarchy we are able to ensure that extensions don’t interfere with each other.  This allows the server to run multiple instances of the same extension in parallel or even different versions of the same extension at the same time.  This also ensures that if one extension uses a different version of the same library there will be no conflict between them.

The server loads all extensions together at start up but in no specific order.  Any initialization process that throws an error will prevent the server from starting the external listeners.  This is to ensure that a secure system isn’t brought online in an insecure manner accidentally.  All start up errors will be in the log files as well as in the web-based administrator.

In practice, this is a very valuable attribute.  For instance, let’s assume a multiplayer game uses a database to authenticate players.  A login event handler uses a managed object factory to get access to the database connection.  The managed object factory uses its initialization method to create the connection pool initially. On start up, a connection string is incorrect and the factory can’t connect to the database.  Rather than starting the server and possibly letting users log in without being authenticated or logging errors every time the login event handler runs, the server simply flags the extension as an error and ensures the external listeners don't start.

The server loads each extension sequentially in an undetermined order.  Each extension runs through the following process:

Only when all extensions have started successfully does the server begin opening external listeners and allow users to connect.  As stated before, any exceptions while initializing will prevent listeners from coming online and will be displayed in the logs and as start up errors in the web-based administrator.

The extension shut down process works in exact reverse of the start-up process with the exception that while errors are logged, they do not stop the process from continuing.  The only two things that can cause an extension to shut down are the server getting shut down (registry or stand-alone) or the extension reloading which is described in the following section.