CDO Server Application and Startup

Author: Eike Stepper

The packaged OSGi server application is CDOServerApplication. It is an internal application implementation, not an application API to subclass. It owns orchestration: it starts the OSGi application lifecycle, uses the shared plugin container, discovers application-extension contributions, configures the repositories, and coordinates auxiliary server components. Application code enters through the IAppExtension extension point and through repository/store configuration. Standalone programs assemble those components themselves; embedded applications can use the higher-level embedded-repository API. These are different ownership models, not three ways to subclass the packaged application.

1  Startup and Shutdown

The OSGi application lifecycle starts first; CDOServerApplication obtains the shared plugin container through its container accessor. If the configured server XML file exists, the application discovers appExtension contributions from the OSGi registry, removes contributions superseded by a predecessor, instantiates them, and injects the container into extensions that implement ContainerAware. It sorts early and normal extensions separately by priority; lower numeric priorities start first, with the default priority used by extensions that do not implement IAppExtension4. An IAppExtension5 selects the early phase with IAppExtension5.startBeforeRepositories().

Early extensions run before repository configuration, so they can install container-level factories or services but cannot assume repositories exist. The configured RepositoryConfigurator then reads the XML: it creates each store and repository, applies properties and initial packages, registers the repository in the container, and activates it. A configuration with no repository entries is allowed but logged. An invalid XML document, missing store factory, or repository activation error propagates from startup. The OSGi application framework does not then call this application's normal stop sequence as rollback, so components created before the error can require operator cleanup or restart; validate configuration before deployment.

After repository setup, the application creates the optional browser component if configured, then starts normal extensions. An IAppExtension3 receives the configured repository array instead of the base file-only callback. Base and early extensions receive the configuration file; an early extension must not assume that repositories are ready. The optional browser is a container-owned component started before normal extensions. Acceptor configuration is normally represented in server XML and creates its acceptors as container elements; the application coordinates the configured repository setup rather than exposing acceptor startup as an extension callback.

Shutdown stops normal extensions in reverse priority/start order, deactivates the repositories returned by initial configuration, stops early extensions in reverse order, deactivates the shared application container, and then stops the OSGi application. Each extension stop is attempted even when another throws; exceptions are logged and shutdown continues. An extension whose start partially installed listeners before throwing is still responsible for undoing that partial work: a failed start is logged and the application does not call stop as rollback.

If the configured XML file is absent, the application logs a warning, skips extension discovery, repositories, browser, and normal extension start, then enters the running application wait. It does not silently create a default repository.

Dynamically created repositories are managed by the repository-configuration manager and their dynamic extension lifecycle, not appended to the initial repository array. Use IAppExtension2 for per-dynamic-repository XML callbacks; use repository-specific extension behavior only when its callback provides the needed repository context. See Application Extensions.

2  Early Extensions

IAppExtension5.startBeforeRepositories() separates extensions that must prepare container-level services before repository configuration from extensions that need running repositories. IAppExtension5.getName() supplies the lifecycle log name. priorities order each group; lower values start first and reverse stopping follows the final order.

3  Standalone, Embedded, and OSGi Use

The packaged OSGi application uses the shared plugin container; its bundle registry supplies factories and appExtension contributions, and the application owns shutdown of that shared container. A standalone program owns an independent initialized container, creates/configures named Net4j elements and repositories, and deactivates the container when done. An embedded repository API packages a local repository and client connection lifecycle for an application that does not need to assemble the full server. See The Managed Container and Creating and Configuring Repositories for those workflows. Deployment details, configuration-file names, ports, TLS, and production topology belong to Operating a CDO Server and Configuring Acceptors.

See Also:

• The Managed Container
• Creating and Configuring Repositories