You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Carsten Ziegeler (JIRA)" <ji...@apache.org> on 2014/02/06 19:50:20 UTC

[jira] [Commented] (SLING-3352) Expose OSGI configuration via HTTP

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

Carsten Ziegeler commented on SLING-3352:
-----------------------------------------

I've just updated the title of this issue to reflect the problem at hand:

Expose OSGi configurations via HTTP

I guess we all agree that using Sling's mechanisms to "create" this http api is the preferred way  - by this I mean being able to use the ootb json rendering, the post servlet etc.
This leads to the conclusion, to represent the configurations as resources in Sling's resource tree.

Since the beginning of this project we have a concept for this - named Resource Provider - it's a very easy way to represent any data as resources
Now, there is the concern of handling access to these resources, since 1.5 years Sling has an answer to this: the resource access security service - it allows to use nodes and JCR acls in the repository.

So, implementing this requirement following the Sling principles is exactly as pointed out above - if there is something wrong with the approach than this means there is something wrong with the fundamentals of Sling.

Please forget the installer once and for all - just looking at the purpose of this tool "installer" (or provisioning) it will be an abuse to implement this issue with that. Not to mention all the problems you will definitely run into. I've mentioned some of them during various discussions and I don't want to waste my time reiteration this any further.

And to be honest, this issue is absurd - the correct solution from a Sling perspective is so obvious but people still don't want to have this the reality and come up with the most obscure solutions.

So either do it the Sling way - or do it the JCR way which is a full sync; everything else is a faulty compromise which is not worth further discussion.



> Expose OSGI configuration via HTTP
> ----------------------------------
>
>                 Key: SLING-3352
>                 URL: https://issues.apache.org/jira/browse/SLING-3352
>             Project: Sling
>          Issue Type: Improvement
>            Reporter: Marius Petria
>            Assignee: Carsten Ziegeler
>              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)