The Registry Service is one of the key parts of the infrastructure built around eXo JCR. Each JCR that is based on service, applications, and more may have its own configuration, settings data and other data that have to be stored persistently and used by the appropriate service or application (called "Consumer").
The service acts as a centralized collector (Registry) for such
data. Naturally, a registry storage is JCR based i.e. stored in some JCR
workspaces (one per Repository) as an Item tree under
Despite the fact that the structure of the tree is well defined (see the scheme below), it is not recommended for other services to manipulate data using JCR API directly for better flexibility. So the Registry Service acts as a mediator between a Consumer and its settings.
The proposed structure of the Registry Service storage is divided into 3 logical groups: services, applications and users:
exo:registry/ <-- registry "root" (exo:registry) exo:services/ <-- service data storage (exo:registryGroup) service1/ Consumer data (exo:registryEntry) ... exo:applications/ <-- application data storage (exo:registryGroup) app1/ Consumer data (exo:registryEntry) ... exo:users/ <-- user personal data storage (exo:registryGroup) user1/ Consumer data (exo:registryEntry) ...
At each upper level, eXo Service may store its configuration in eXo
Registry. At first, start from xml-config (in jar etc) and then from
Registry. In configuration file, you can add the
parameter to the component to ignore reading parameters initialization from
RegistryService and to use the file instead: