[ http://issues.apache.org/jira/browse/JCR-65?page=all ]
Jukka Zitting resolved JCR-65:
------------------------------
Resolution: Won't Fix
Resolving this issue as "Won't fix" to clean up the open issues list.
As Edgar already mentioned, there is little support for the idea of adding
complexity to the persistence manager layer. I think that we should try to find
other solutions to the mentioned needs. Until such a solution is found we can
direct people who have needs like this to this issue as an unsupported interim
solution.
Please reopen this issue if there is a design change that would favor this kind
of an approach.
For reference, see the original discussion thread at:
http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/911
> ChainedPersistenceManager
> -------------------------
>
> Key: JCR-65
> URL: http://issues.apache.org/jira/browse/JCR-65
> Project: Jackrabbit
> Type: New Feature
> Reporter: Edgar Poce
> Assignee: Jukka Zitting
> Priority: Minor
> Attachments: 05-03-15-chained-persistence.zip, uml-class.gif
>
> Overview
> The package contains the classes that provide chaining of Persistence
> Managers support through an implementation of the chain of responsibility
> pattern.
> The ChainedPersistenceManager class is the chain's external controller.
> The current implementation uses composition instead of inheritance. The
> concrete handlers (PersistenceManager) are private members instead of
> subclasses.
> For reading commands no evaluation is performed, the
> ChainedPersistenceManager returns the response of the first handler that
> finds the object.
> For writing commands, the PersistenceManagerHandler class delegates
> conditionally the persistence calls to the concrete implementation based on a
> custom evaluation.
> Custom PersistenceManagerEvaluator implementations can be set through
> configuration.
> Custom listeners can be added to the ChainedPersistenceManager class. It
> allows to perform custom operations on "after init" and "before close"
> events.
> Warning
> This package should be used only in a couple of cases and none of them is the
> best practice.
> * Sharing jcr data with others systems through a custom PersistenceManager
> * Integrating a legacy system
> Reliability, integrity and performance of the PersistenceManager are
> *crucial* to the overall stability & performance of the repository. if e.g.
> the data that a PersistenceManager is based upon is allowed to change through
> external means the integrity of the repository would be at risk (think of
> referential integrity/ node references e.g.).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
