Warning
You are looking at documentation for an older release. Not what you want? See the current release documentation.
eXo Repository Service is a JSR 170-based standard service and is a registered IoC (Inversion Of Control) component that can be deployed in some eXo Containers (see Repository service configuration for more details). The relationships between components are shown in the picture below:
eXo Container: Some subclasses of ExoContainer (usually StandaloneContainer or
PortalContainer) that holds a reference to Repository Service. See Containers for more details.
Repository Service: Contain information about repositories. eXo JCR is able to manage many Repositories.
Repository: Implementation of
javax.jcr.Repository. It holds references to one or more Workspace(s).Workspace: Container of a single rooted tree of Items. (Note that here it is not exactly the same as
javax.jcr.Workspaceas it is not a Session object). See Workspace for the workspace configurations.
The JCR application usecase typically includes two initial steps:
Obtaining Repository object by getting Repository Service from the current eXo Container (eXo "native" way) or via JNDI lookup if eXo repository is bound to the naming context using (see Repository configuration for more details).
Creating
javax.jcr.Sessionobject that callsRepository.login(..).
The following diagram explains which components of eXo JCR implementation are used in a data flow to perform operations specified in JCR API.
The Workspace Data Model can be split into 4 levels by the data isolation and value from the JCR model point of view.
eXo JCR core: Implements the JCR API interfaces, such as Item, Node, Property. It contains JCR "logical" view on stored data.
Session Level: Isolates the transient data viewable inside one JCR Session and interacts with API level using eXo JCR internal API.
Session Data Manager: Maintains the transient session data. With data access/ modification/ validation logic, it contains Modified Items Storage to hold the data changed between subsequent save() calling and Session Items Cache.
Transaction Data Manager: Maintains the session data between save() and transaction commit/ rollback if the current session is part of a transaction.
Workspace Level: Operates for the particular workspace shared data. It contains objects of each Workspace.
Workspace Storage Data Manager: Maintains the workspace data, including final validation, events firing, and caching.
Workspace Data Container: Implements the physical data storage. It allows different types of backend (such as RDB, FS files) to be used as a storage for JCR data. With the main Data Container, other storages for the persisted Property Values can be configured and used.
Indexer: Maintains the workspace data indexing for further queries.
Storage Level: Persistent storages for:
JCR Data.
Indexes (Apache Lucene).
Values (for example, for BLOBs) if being different from the main Data Container.