[
https://issues.apache.org/jira/browse/JCR-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12871212#action_12871212
]
Jukka Zitting commented on JCR-2640:
------------------------------------
FTR, I agree with Angela and Stefan on JCR-890, exposing implementation details
through public methods of publicly accessible objects is just asking for
trouble.
Felix:
> What functionality can be solved by OSGi and IoC in this "context" ?
The proposed RepositoryContext class is essentially a very lightweight
component manager that decouples the code that instantiates a component from
the code that uses it. An extra benefit of using a solution like this is that
it'll make our lives easier down the road if we want to go for increased
modularity.
> 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.
