[ 
https://issues.apache.org/jira/browse/JCR-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871158#action_12871158
 ] 

Thomas Mueller commented on JCR-2640:
-------------------------------------

> break the tight package-private coupling

And what is the advantage of this?


> 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.

Reply via email to