sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marius Petria (JIRA)" <>
Subject [jira] [Commented] (SLING-3352) Expose OSGI configuration as JCR nodes
Date Mon, 03 Feb 2014 08:32:10 GMT


Marius Petria commented on SLING-3352:

[~tripod], I am just restating your proposal to make sure I understand it correctly
- have some kind of extension for jcr installer that can be configured with a factory and
a path
- enforce that objects of that factory can be installed only from that location (and also
that from that location you can only install instances for that factory)
- the advantage for that will be that we are reusing an already implemented syncing mechanism

I see two small shortcomings of that:
- the urls are not friendly, they have the fully qualified name of the factory and contain
a lot of dots. We can probably fix that by designating another property to represent the name
of the shadow node (for example property name). Implementing this might require some unexpected
- we are building this into the sling components directly, so we should first decide it is
a valid use case in general. The custom syncronizer was targeted first at replication with
the possibility of extending it.

> Expose OSGI configuration as JCR nodes
> --------------------------------------
>                 Key: SLING-3352
>                 URL:
>             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
> 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
> - 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

View raw message