[ https://issues.apache.org/jira/browse/JCR-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871584#action_12871584 ]
Stefan Guggisberg commented on JCR-2640: ---------------------------------------- i like the idea of the patch in general. a quick glance revealed a minor issue: instead of accessing 'rep.context' directly i'd prefer to use a (non-public ;) getter method instead. +1 for the patch (assuming my above concern is being addressed) > 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 > Attachments: repository-context-v1.patch, repository-context.png > > > 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.