[
https://issues.apache.org/jira/browse/JCR-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872226#action_12872226
]
Thomas Mueller commented on JCR-2640:
-------------------------------------
> But modularization is about separation of concerns
Sure. I'm just against "we should modularize because modularizing is always
good". I'm also against "we should modularize because it *might* be good in the
future". We should only do that where it actually makes sense, and where it
makes sense *now*. Predicting the future is a bad idea. Known use cases are a
different topic of course (large number of child nodes, large transaction,..).
About public methods: having *every* method public is not a good idea of
course, and having a public method "loginAdministrative" is bad as well. But
adding an indirection class just to avoid public methods doesn't sound like
something I would want in Jackrabbit 3.
> 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.
