[jira] [Updated] (OAK-3145) Allow plugging in additional jcr-descriptors
[
https://issues.apache.org/jira/browse/OAK-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-3145:
-
Attachment: OAK-3145.v2.patch
Good point [~chetanm], I've updated the patch: [^OAK-3145.v2.patch] - would
push this in a few days unless there's any -1 review coming ;)
> 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)
[jira] [Updated] (OAK-3145) Allow plugging in additional jcr-descriptors
[
https://issues.apache.org/jira/browse/OAK-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-3145:
-
Description:
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
was:
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
> 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
>
>
> 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)
[jira] [Updated] (OAK-3145) Allow plugging in additional jcr-descriptors
[
https://issues.apache.org/jira/browse/OAK-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli updated OAK-3145:
-
Attachment: OAK-3145.patch
Attached [^OAK-3145.patch] as a suggested implementation. Open for review.
> 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
>
>
> 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)
