[
https://issues.apache.org/jira/browse/JCR-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871151#action_12871151
]
Felix Meschberger commented on JCR-2640:
----------------------------------------
I do not understand the problem either ?
To me the problem is rather mixture of internal API with implementation in the
same package, which should be solved. I have no issue with an implementation
object calling and using another implementation object.
What functionality can be solved by OSGi and IoC in this "context" ?
> 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.
