Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <23872263.34451274795905568.JavaMail.jira@thor>
Date: Tue, 25 May 2010 09:58:25 -0400 (EDT)
From: "Felix Meschberger (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-2640) Internal repository context
In-Reply-To: <24963476.32931274792491060.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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