This page tries to explain the OpenCms 7 bootup process. You may find it useful if you are interested in the OpenCms internals.
The boot up phase happens in several stages called runlevels, a similar concept to the UNIX runlevels.
- When the OpenCms webapp is not initialized , it is said to be at runlevel 0. At this stage the OpenCmsCore singleton is not instantiated, nothing is really running yet. The system is also at runlevel 0 when shutdown is requested.
- At runlevel 1, the OpenCmsCore singleton is instantiated, and some of the core services are available from it. The configuration hasn't yet been read.
- At runlevel 2, configuration begins. The XML config files are read, and all remaining core services are instantiated and initialised. During this process, some of the services created at runlevel 1 are swapped with different implementations, as configured in the config files; one example is the CmsEventManager service.
- At runlevel 3, configuration finished and all the internal services are configured and running. HTTP serving is disabled. The CMS Shell operates at this runlevel.
- At runlevel 4, HTTP request serving is enabled, the system is operating normally.
Runlevels are defined in class org.opencms.main.OpenCms.
Parsing the configuration files
Parsing of the configuration files is a bit weird, XML files get fed through commons-digester, which constructs objects and calls methods based on some rules, all via Java reflection. In other words, don't expect to be able to trace the config parsing process in your IDE :-).
You can see the rules in classes named Cms*Configuration in package org.opencms.configuration. Each XML config file in WEB-INF/config has its own class. E.g. opencms-vfs.xml has class CmsVfsConfiguration.