Server Core

The server core (Server ) is started by a bootstrap loader that sets a minimal class loader needed for running of the server. The server core then sets up further class loader with all supplied jars from a lib directory and creates an application context from configuration xml file (which is Spring Framework 's application context file). After that, it registers self with that application context as an singleton bean with the name "Server".

The server then starts deployment of a given URL. If not URL is supplied for server to run from a default location (directory named "server" is used instead). The deployment is done by obtaining "DeploymentManager" bean of DeploymentManager type and "DeploymentDirectoryModuleLoader" of DeploymentDirectoryModuleLoader type. The later is then used for the given URL to be deployed with.

Modules

The server is organised around Module s. Each module describes an unit that exists within a server's boundaries. The modules are organised in a hierarcy of dependancies.

Modules have well defined life cycle:

• UNDEFINED - each module starts with that state. Some modules stay forever in it.
• DEFINED - this state is assigned to the module as soon as it is "created" and important properties assigned to it.
• WAITING_ON_DEPENDENCY - this is internal state to denote that module is waiting for other modules this module depends on to be CREATED.
• CREATED - is assigned to the module when it is created and that can happen only if all modules this module depends on are created. This state is set after a module's create method is succesfully called.
• DEPLOYED - a state that is assigned when the module is started (deployed). It is set after module's start method is called.

Module Loaders

Modules are delivered to the system (loaded) by ModuleLoader s. When an URL is supplied to the server as a source of a module, all defined module loaders are checked in turn (in the order they are defined in the system) to load that URL. If the module returns true on call of canLoad method, delegation of loading of that module is passed to that module loader. A concrete class of loaded module is actually defined by the module loader.

Service Archives

There is one type of modules defined in the core part of the server: Service Archives. Those are modules that are defined in jar archives or directories with ".sar" extensions. For each service archive an application context is created and bean definitions loaded from a file named "service.xml". All jar files in the root of the archive as well as archive itself are used to form a classpath.

The application context has access to all application contexts of the modules this module depends on. Same stands to the class loaders.

The service archive extends definition of an XML files adding "<service>" tag bean definition. A presence of that tag denotes that bean is not ordinary bean but a service bean. The service beans can be created, started, stopped and destroyed along with the service module. For each bean these method names can be defined using sub-tags: "<create-method>", "<start-method>", "<stop-method>" and "<destroy-method>". By omitting any of these sub-tags the service archive will use default values "create", "start", "stop" and "destroy". Making tags with empty value (like "<destroy-method />") will signal to the service not to call the method. If no argument method doesn't exist then it just wont be called.

With this granularity of methods each service has four states in its lifecycle:

• instantiated - when bean is created. It is managed by the spring framework.
• initialised - when bean is fully initialised. It is, too, managed by the spring framework.
• created - when create method is called. It is managed by the spring application server.
• started - when start method is called. That is, too, managed by the spring application server.

Directory Structure

Here is directory structure spring application server operates from:

bin
  bootstrap.jar - bootstrap jar file
lib
  libraries needed for the server to work
server
  default
    config
      server.xml - the server's application context
    lib
      libraries needed for services - they are going to be visible from all modules
    deploy
      directory that contains deployable modules (.sar archives or directories, .war, etc...)

It is possible for different server directory to be used instead of the default. It is done by supplying argument -c <name of subdirectory> while starting bootstrap.jar. That directory is the directory the rest of the code is going to be executed from.

Also, path of the server directory can be specified as an argument -server followed by URL while starting bootstrap.jar.