Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
Description
currently configuration data is only read, and it's hard-coded how it's stored in the configuration resource (properties directly in the resource).
we need to enhance this to provide a management API to read+write configuration data (required for configuration editor GUIs).
additional the details of the persistence should be pluggable with a simple default implementation which can be similar to what is present today. but in more complex environments it may be desired to:
- use special node types to store the configuration in (e.g. to make sure they are stored in an index)
- use a jcr:content subnode to store configuration data in
- assign special resource types to support a configuration editor
- decide in which path the configurations are stored
Attachments
Issue Links
- links to