[
https://issues.apache.org/jira/browse/SLING-8309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16791894#comment-16791894
]
Sergiu Dumitriu commented on SLING-8309:
----------------------------------------
Thanks for presenting your concerns. My goals are centered around creating
custom and more complex node types, and currently involve:
* being able to validate more than what is possible with {{ValueConstraints}},
and I found that adding new {{Validator}}s makes it easy to do that
* being able to add new {{Autocreated/Protected}} properties, and I found that
adding them via a commit {{Editor}} makes it easy to do that during
persistence, although I would rather find a way to do that earlier, at node
creation (no idea yet if that's possible)
* being able to autocreate / autoremove child nodes and properties depending
on related changes on the parent node, which is also easy with an {{Editor}}
1. As I understand the Observer mechanism, it fires asynchronously, after a
change already happened, and the {{NodeState}} passed only contains the new
state, with no reference to the old one. This makes it harder to figure out
what exactly changed, and it leaves a possibly large window of inconsistency
w.r.t. the above goals. Thus, I'm looking for other extension mechanisms. Can
you point me in a better direction?
2. If commit editors is the best way forward, what would be the preferred way
to have a customize repository manager? Build a custom module with my own
implementation of {{AbstractSlingRepositoryManager}}, then build a custom
sling-starter with a custom configuration referencing it? For early prototyping
(and still being a beginner when it comes to Sling and its hundreds of modules)
I found it easier to just use the default sling-starter and plug in my
components.
3. If I change the default for
{{OakSlingRepositoryManagerConfiguration#dynamic()}} to be {{false}}, would you
be OK with merging the pull request?
4. As long as any custom code can find its way into the repo, security and data
integrity is at risk, be it a commit editor or a custom esp/jsp for displaying
a resourceType. Correct? So my plan is to make sure nobody unauthorized can
introduce code, with production instances only receiving content, no OSGi
updates.
> Allow adding CommitHooks and EditorProviders dynamically from bundles
> ---------------------------------------------------------------------
>
> Key: SLING-8309
> URL: https://issues.apache.org/jira/browse/SLING-8309
> Project: Sling
> Issue Type: Improvement
> Components: Oak
> Reporter: Sergiu Dumitriu
> Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, {{OakSlingRepositoryManager}} uses a hard-coded list of
> {{CommitHook}} and {{EditorProvider}} to be used by the Oak repository. This
> means that other than building a patched version of
> {{OakSlingRepositoryManager}} there's no way to include a new commit
> observer. Ideally, a single pseudo-\{{CommitHook}} and
> pseudo-\{{EditorProvider}} should be handled to Oak, and these should just
> dynamically aggregate all the {{CommitHook}} and {{EditorProvider}} instances
> registered in the {{Whiteboard}}.
> All the currently hardcoded components are already available in the
> whiteboard, so no functionality will be lost, but this change will
> automatically enable support for {{mix:atomicCounter}} via the
> {{AtomicCounterEditorProvider}} that's not used at the moment.
> The old behavior should still be available via a new configuration,
> {{OakSlingRepositoryManagerConfiguration#dynamic_components}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
