[
https://issues.apache.org/jira/browse/JCR-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872216#action_12872216
]
Felix Meschberger commented on JCR-2640:
----------------------------------------
> The point is to avoid public getters of internal components in
> RepositoryImpl.
I think this is not enough of an argument.
If we go modularized and we have properly exported API and poperly shielded
implementation classes (as is possible e.g. with OSGi Export-Package specs) we
don't have to worry about public methods of implementation classes which are
used by the public by means of API.
The only way for the user to access such publich methods is by using
Reflection... But by using Reflection you can do anything you want, and
non-public methods are not protected from being used at all.
Thus I agree with Tobias, that defining an interface is sufficient.
I also agree with Thomas, that trying to prevent publich methods to help
modularize stuff is completely wrong and makes things way too complex and in
the end probably prevents proper modularization.
> Increased modularity comes with increased complexity. Unneeded complexity
> will make our lives harder, not
> easier. I'm afraid we bloat the code unnecessarily.
To a certain extent yes. But modularization is about separation of concerns, is
about hiding implementation from the users. If we don't go that route, we can
just as well keep the *Impl casts ;-)
> 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.
