jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-2640) Internal repository context
Date Tue, 25 May 2010 14:02:25 GMT

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

Jukka Zitting commented on JCR-2640:
------------------------------------

The main goal here is to be able to break the tight package-private coupling between many
of the classes in o.a.j.core. This will simplify refactorings like the one proposed in JCR-890.

An alternative approach would be to split classes like RepositoryImpl and SessionImpl to separate
JCR API facades and underlying implementation classes. This would achieve similar disconnect
from client-visible objects, but would require much more extensive changes.

> + this.repositoryContext = repositoryContext;
> + this.rep = repositoryContext.getRepository();

That's a result of the patch being a first draft. Many of the internal repository components
are not included in RepositoryContext, so replacing rep.getSomething() with repositoryContext.getRepository().getSomething()
everywhere in SessionImpl would just have unnecessarily bloated the patch.


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


Mime
View raw message