jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Egli (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-3145) Allow plugging in additional jcr-descriptors
Date Wed, 29 Jul 2015 10:08:04 GMT

    [ https://issues.apache.org/jira/browse/OAK-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14645829#comment-14645829
] 

Stefan Egli commented on OAK-3145:
----------------------------------

agreed, it should be closed esp with the current state where it doesn't continuously monitor
the registrations. I'll do that.

more generally speaking: the whiteboard/tracker pattern doesn't seem to support the push model
(of being notified when a new service is triggered) but rather relies on the pull model (where
you have to go {{Tracker.getServices()}} periodically in case you'd want to support late-joining
services to be taken into account). Or am I missing something?

> Allow plugging in additional jcr-descriptors
> --------------------------------------------
>
>                 Key: OAK-3145
>                 URL: https://issues.apache.org/jira/browse/OAK-3145
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 1.3.3
>            Reporter: Stefan Egli
>            Assignee: Stefan Egli
>            Priority: Minor
>             Fix For: 1.3.4
>
>         Attachments: OAK-3145.patch, OAK-3145.v2.patch
>
>
> The current way oak compiles the JCR descriptors is somewhat hard-coded and does not
allow an easy way to extend it. Currently oak-jcr's {{RepositoryImpl.determineDescriptors()}}
uses oak-core's {{ContentRepositoryImpl.createDescriptors()}} ones and overwrites a few (in
{{JCRDescriptorsImpl}}). The result of this is then put into the {{RepositoryImpl.descriptors}}
field - which is subsequently used.
> While these descriptors can explicitly be overwritten via {{put}}, that all has to happen
within overwriting code of the {{RepositoryImpl}} hierarchy. There's no plug-in mechanism.
> Using the whiteboard pattern there should be a mechanism that allows to provide services
that implement {{Descriptors.class}} which could then be woven into the {{GeneralDescriptors}}
in use by {{ContentRepositorImpl}} for example. The plugin mechanism would thus allow hook
in Descriptors as 'the base' which are still overwritten by oak-core/oak-jcr's own defaults
(to ensure the final say is with oak-core/oak-jcr) - as opening up such a *Descriptors-plugin
mechanism could potentially be used by 3rd party code too*.
> PS: this is a spin-off of OAK-2844



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message