[ 
https://issues.apache.org/jira/browse/SLING-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13886852#comment-13886852
 ] 

Tobias Bocanegra commented on SLING-3352:
-----------------------------------------

bq. You might also want to provide the HTTP endpoint as a node in the 
repository that you protect.

let's look at the special case of replication agents: IMO what is needed is to 
have 1 JCR node for each replication agent (or agent group) that has a special 
resource type and will be protected by JCR ACLs. If those nodes also contain 
the properties of the respective OSGi configuration is not relevant. the 
servlet behind the resource type should create a response derived from the OSGi 
config. but it might also include other, more dynamic information, like # of 
pending items.

the "service" should also listen for config admin changes and 
create/remove(/update) the nodes. I agree with felix, that adding a 2-way sync 
might result it a mess - but would simplify the management of course.

note: if the config properties are also mapped to the node, you can use the 
norma json-get to read the data.

> 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)

Reply via email to