Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <9998359.1182773845905.JavaMail.jira@brutus>
Date: Mon, 25 Jun 2007 05:17:25 -0700 (PDT)
From: "Marcel Reutegger (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Resolved: (JCR-978) Remove circular dependency between
 VersionManagerImpl and VersionItemStateProvider
In-Reply-To: <19032923.1182536965861.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/JCR-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marcel Reutegger resolved JCR-978.
----------------------------------

       Resolution: Fixed
    Fix Version/s: 1.4

Assuming lazy consensus I committed the patch in revision: 550466

> Remove circular dependency between VersionManagerImpl and VersionItemStateProvider
> ----------------------------------------------------------------------------------
>
>                 Key: JCR-978
>                 URL: https://issues.apache.org/jira/browse/JCR-978
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: versioning
>            Reporter: Marcel Reutegger
>            Priority: Minor
>             Fix For: 1.4
>
>         Attachments: JCR-978.patch
>
>
> From a architectural perspective the VersionManagerImpl (VMgr) is at a higher level as the VersionItemStateProvider (VISP). While the VMgr deals with Items the VISP deals with ItemState object. Nonetheless the VISP has a reference to the VMgr and also calls the method setNodeReferences(), which violates the rule of a strictly layered system. E.g. one negative effect of this was a deadlock as described in JCR-672. It also makes it hard to solve JCR-962.
> The attached patch includes the following changes:
> - Move method VersionManagerImpl.setNodeReferences() VersionItemStateManager. The method can operate on ItemStates only and does not need to be in VersionManagerImpl. As can be seen in the current method it directly calls the PeristenceManager, which indicates it should be located in a lower layer.
> - Promote the class VersionItemStateManager to a top level class
> - Change method VersionManagerImpl.createSharedStateManager to return a VersionItemStateManager
> - Remove VersionManagerImpl instance variable from VersionItemStateProvider
> - In VersionItemStateProvider.setNodeReferences() call VersionItemStateManager.setNodeReferences()
> - Instead of using the PersistenceManager in VersionManagerImpl.getItemReferences() use the ItemStateManager. It also seems that locking is not necessary for this method.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.