Internal repository context
---------------------------
Key: JCR-2640
URL: https://issues.apache.org/jira/browse/JCR-2640
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-core
Reporter: Jukka Zitting
Assignee: Jukka Zitting
As discussed in JCR-890, the current approach of using protected or
package-private getters on key classes like RepositoryImpl to access other
internal components and resources is a bit troublesome. The attached patch
(repository-context-v1.patch) introduces a RepositoryContext object that can be
used to get rid of such getters. This first version replaces the
getNamespaceRegistry(), getNodeTypeRegistry(), getVersionManager() and
getRootNodeId() methods from RepositoryImpl.
The idea behind this component context idea is to separate the JCR API
implementation classes from the task of keeping track of the internal
implementation components. This way none of the instances returned by JCR API
methods would have methods through which Jackrabbit internals can be directly
accessed. See the attached UML diagram for how this layered access would work.
Assuming people think this is a good idea, I'd like to extend this mechanism to
cover also the rest of the internal Repository components like the data store
and the security managers, etc. I'm also thinking about using a similar context
objects for tracking internal components associated with workspaces
(WorkspaceInfo, SharedItemStateManager, etc.) and sessions
(LocalItemStateManager, etc.).
PS. Yes, we'd get much of the same functionality (and more) from OSGi or an IoC
container. For now I'm hoping to keep things simple without extra external
dependencies.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
