[
https://issues.apache.org/jira/browse/SLING-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13886461#comment-13886461
]
Marius Petria commented on SLING-3352:
--------------------------------------
The HTTP endpoints for replication were implemented in SLING-3315. However that
implementation relies on a custom ResourceProvider and ResourceAccessSecurity
to security. That triggered objections (in a private discussion with some
people including [~tripod] and [~cziegeler]) that was followed by the
recommendation to base security on shadow nodes rather than on access security
gates.
In general if osgi configs are to be used by admins through configuration
console and also through HTTP by restricted users we should work out a way to
provide such a functionality in a way that is secure (links a resource path
with a configuration factory) and easy to use (should allow modification of
content via standard servlets).
The synchronization does not look that bad.
- When the sync agent is activated copies all configs from ConfigurationAdmin
to the desired location.
- Any change to the content or to the configuration triggers an update to the
related entity. Updates are made only if content is really changed to prevent
circular updates.
- When the sync agent is deactivate all copies are deleted.
> 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)
