All future development in the client servlet should be accomplished using the Client Module system (3.1+). This is a flexible system that allows for basic dependency management (client module B can require that client module A has been set up and is available before B can be started), injection of other OSGi services, and dynamic creation/destruction of modules as appropriate.

Background Information

Base Interface

The primary interface for the client module system is

I'll add javadocs to the interface shortly, but here's a rundown on the methods. The constants can be largely ignored.

• public String getFactoryName(): This should return a unique identifier in the format com.xmlnamespace.panel.client.factory.client_module.<subname>. The identifier is used by other client modules to denote that they require this module to be active before they can be activated themselves. It is recommended that you declare a public constant (similar to the BASE_FACTORY_NAME constant above) that contains the factory name, for other modules to reference.
• public Class<?> getClassReference(): Client modules are available from the ClientRootUI based on a particular class. The class that a particular module should be available under is what's returned by this method. It is recommended that this method return an interface class, rather than a concrete class, for the purposes of extensibility.
• public void startup(final ComponentContext context): This method, although not required in the OSGi scheme, is the recommended activate method for your OSGi service. Therefore, it is included in the interface for the purpose of easy over-riding. 
• public void shutdown(final ComponentContext context): Same as the startup method, but for deactivating the OSGi service.

Abstract base class

An abstract base class is provided (com.xmlnamespace.panel.client.BaseClientModule) that simplifies extracting the ClientRootUI object from the ComponentContext in the startup method, and provides access to it as a class member. It is recommended, although not required, that you extend this class when implementing a new client module implementation.

Types of Client Modules

There are two primary types of client modules, based on how early in the client login process they are required:

Init Client Modules

Init client modules are loaded when the ClientRootUI is first loaded, before login. This means that they will not have access to the current user object, the current core server object, or any related login information. They will have access to these services:

• The ClientRootUI, and services it directly provides:
  • The Request object for information about the browser and request
• The communication service (assuming it has been defined as a dependency and injected by OSGi)
• Other init client modules that have already been loaded (based on the dependency tree created by the factory names), which generally includes:
  
  • Language Module
  • Login Module (including the login screen)

Login Client Modules

Login client modules will be initialized after a successful login has taken place, either through the saved login feature or via the login screen. They will have access to the full range of services and other modules (assuming they have been initialized up the tree). See the subpages for descriptions of the particular modules.