[
https://issues.apache.org/jira/browse/SLING-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13887637#comment-13887637
]
Bertrand Delacretaz commented on SLING-3352:
--------------------------------------------
Trying to think of the simplest way to implement this:
* One node per config factory, with a friendly name, resource type
config/factory and properties that describe the actual factory
* POST to config/factory creates a config node under it, with a friendly node
name, resource type config/config, POST also creates the ConfigurationAdmin
config
* POST to a config/config node updates the ConfigurationAdmin config, bypassing
normal node operations.
* config/config node does not store the config properties, maybe just the
config PID
* config/config is handled by a ResourceDecorator that gets config properties
from ConfigurationAdmin. Might include metatype info for convenience.
I think this fulfills all of the original requirements except the JCR nodes do
not contain the config properties, but you get them when the ResourceDecorator
kicks in.
There's no special configuration needed besides installing the config/*
servlets and ResourceDecorator service.
ACLs on the factory and config nodes are handled in the standard way.
WDYT?
> Expose OSGI configuration as JCR nodes
> --------------------------------------
>
> Key: SLING-3352
> URL: https://issues.apache.org/jira/browse/SLING-3352
> Project: Sling
> Issue Type: Improvement
> Reporter: Marius Petria
> Labels: replication
>
> We need a safe way to expose OSGI configuration via HTTP.
> Requirements:
> - all configs for a certain factory should be manageable
> - they should have associated JCR nodes that contain the config properties
> - only configs that are available through ConfigurationAdmin should be
> available
> - the HTTP urls should have friendly names
> - (Optional) the implementation should be general enough to be used for other
> configs other than replication if needed
> For example: a configuration with name publish for
> org.apache.sling.replication.agent.impl.ReplicationAgentServiceFactory
> should be mapped to /etc/replication/agent/publish
> Problems with current implementation of JCR nodes created by JCR installed:
> - Configuration files are read and created from /apps/.../config or
> /libs/.../config, and there is no easy way to determine which are active in
> the ConfigurationAdmin
> - There is no way to restrict a repository path to create only configuration
> from a specified factory (making it unusable with relaxed ACLs)
> - The url of a configuration is unfriendly (it contains the fully qualified
> name of the factory)
> - The node types are not homogenous making it hard to use in a client
> application (some are nt:file, some are sling:OsgiConfig)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
