Hi Marius
Thanks for the patch. However, I think you misunderstood my
suggestion. The idea was that there is a well-defined property (e.g.
sling:osgiConfigPid), which can be set on a JCR node, this points to
the configuration that should be "mounted" on this node.
I'll try to illustrate it with an example:
/etc/replication/agents/author (JCR node):
{
"jcr:primaryType": "nt:unstructured", // could optionally use
some marker node-type
"sling:osgiConfigPid":
"org.apache.sling.replication.agent.impl.ReplicationAgentServiceFactory-author",
"sling:resourceType": "replication/agent" // entirely optional,
but may be useful to provide different renderings for different
configs
}
Then your ResourceProvider could have its root set e.g. to "/etc" and
thus be given a chance to handle any requests for resources in that
tree. It would look at the underlying JCR node's sling:osgiConfigPid
property, and if present enrich it with service/config specific
additional properties (may be useful for rendering), or maybe even
child-resources (I haven't thought the details of the mapping
through).
Using such an approach would enforce that config resources are indeed
backed by a JCR node (and can thus be restricted with ACLs), it also
allows greater flexibility in placing the configuration UIs at
arbitrary paths.
Does that make sense?
Regards
Julian
On Mon, Feb 24, 2014 at 2:42 PM, Marius Petria <mpet...@adobe.com> wrote:
> Hi,
>
> I have provided an initial implementation in a patch for [1]. It allows to
> customize the resource provider so that downstream users can choose which
> property should be used as the friendly name (as Julian suggested). We can
> add also a customization option to specify a resource type.
>
> Basically a resource provider for OSGI configs can be configured as follows:
> {
> "name" : "replicationAgents",
> "provider.roots" : [ "/etc/replication/config/agents" ],
> "friendlyNameProperty" : "name",
> "configFactoryPid" :
> "org.apache.sling.replication.agent.impl.ReplicationAgentServiceFactory"
> }
>
> Marius
>
> [1] https://issues.apache.org/jira/browse/SLING-3352
>
>
>
>
>> -----Original Message-----
>> From: Julian Sedding [mailto:jsedd...@gmail.com]
>> Sent: Friday, February 21, 2014 12:51 PM
>> To: dev@sling.apache.org
>> Subject: Re: Replication REST-ful/HTTP API
>>
>> Hi Marius
>>
>> I like the general direction of your proposal. The only concern I have is
>> that you
>> require properties on the services (sling:friendlyName and maybe
>> sling:resourceType). Since this requires modification of the service
>> implementation this cannot flexibly be used by downstream users of this
>> feature.
>>
>> However, if you require some JCR node structure as a skeleton for the
>> hierarchy
>> in any case, why don't you just reference the service/service-factory from a
>> property on the respective nodes? This would allow:
>>
>> * fine or coarse grained access control as required,
>> * flexible placement/naming of the hierarchy (e.g. it would be possible to
>> map
>> replication services into /etc/replication and other sevrices to /system/...)
>>
>> Regards
>> Julian
>>
>>
>>
>>
>>
>> On Thu, Feb 20, 2014 at 1:12 PM, Tommaso Teofili
>> <tommaso.teof...@gmail.com> wrote:
>> > Hi Marius,
>> >
>> > 2014-02-20 9:58 GMT+01:00 Marius Petria <mpet...@adobe.com>:
>> >
>> >> Another idea was proposed to generally solve access to OSGI objects
>> >> (configs and services).
>> >>
>> >> 1. OSGI configs need to be managed (CRUD) over HTTP and access should
>> >> be controlled at factory and config level.
>> >>
>> >> URL hierarchy:
>> >> - /system/osgiconfigs/factoryPid/{configFriendlyName}
>> >> - configFriendlyName will be provided in a OSGI config property
>> >> sling:friendlyName ACLs are controlled via representative JCR nodes:
>> >> - root node /system/osgiconfigs - controls access to the whole
>> >> hierarchy
>> >> - intermediate nodes are optional, a node like
>> >> /system/osgiconfigs/factoryPid controls access to managing configs of
>> >> a certain factory
>> >> - implementation will be done using a ModifyingResourceProvider and
>> >> access will be secured with a ResourceAccessGate
>> >>
>> >>
>> > looks good to me, especially because this is a generic solution that
>> > can be leveraged for other use cases.
>> >
>> >
>> >> Questions:
>> >> - should we expose all configs or only selected ones (for example
>> >> those that have the property sling:friendlyName)?
>> >>
>> >
>> > being this a generic proposal affecting all the existing configs,
>> > maybe it'd be better to not expose anything by default.
>> >
>> >
>> >> - should we use a ResourceProvider per factory in order to customize
>> >> the provider better.
>> >
>> >
>> > maybe it'd be good to have a generic one that works on a config
>> > factory resourcetype and then that could be overridden by a custom one
>> > in case it's needed.
>> >
>> >
>> >> The following customization options are useful:
>> >> ---- define a custom root for config factory (for example
>> >> /etc/replication/config)
>> >> ---- define exactly what properties are exposed from configs
>> >> belonging to a factory by using a whitelist.
>> >
>> >
>> >> 2. OSGI services need to be exposed over HTTP in order to make it
>> >> easy to link them to servlets that execute actions on them.
>> >> URL hierarchy:
>> >> - /system/osgiservices/servicePid
>> >> - services should have a property to (sling:resourceType or
>> >> different) that will be used as the resource type of the associated
>> >> resources
>> >> - servlets can use the designated resource type to bind and execute
>> >> methods on the associated services.
>> >> ACLs are controlled via respresentative JCR nodes
>> >> - root node /system/osgiservices is mandatory and controls access to
>> >> whole hierarchy
>> >> - sub nodes are optional and allow fine grained control at service
>> >> level
>> >> - implementation will be done using a ResourceProvider and access
>> >> will be secured with a ResourceAccessGate
>> >>
>> >>
>> > looks good to me, I'm not sure about the property to be used for the
>> > resourcetype, however that's just a detail.
>> >
>> >
>> >> Questions:
>> >> - should we expose all services or just the ones having the
>> >> designated property?
>> >> - should we use a ResourceProvider per service interface so that we
>> >> can customize it better?
>> >> ---- define a custom root node for a service interface (for example
>> >> /system/replication/agent for ReplicationAgents)
>> >>
>> >>
>> > probably same as above, no service exposed by default.
>> >
>> >
>> >>
>> >> This is just the initial proposal. Feedback will be greatly valued on
>> >> the general approach, but also on the particular questions of whether
>> >> a single hierarchy for all objects is desirable or a more granular
>> >> strategy should be taken. Related to that, should we expose all
>> >> objects by default or just those that have certain properties?
>> >>
>> >
>> > I'd expose only resources (either for configs or services) that are
>> > configured on purpose to be exposed (having certain properties), using
>> > a granular approach.
>> >
>> > Regards,
>> > Tommaso
>> >
>> >
>> >>
>> >> Marius
>> >>
>> >> > -----Original Message-----
>> >> > From: Carsten Ziegeler [mailto:cziege...@apache.org]
>> >> > Sent: Tuesday, February 18, 2014 11:15 AM
>> >> > To: dev@sling.apache.org
>> >> > Subject: Re: Replication REST-ful/HTTP API
>> >> >
>> >> > I prefer the granular design as well - and just to reiterate, the
>> >> > Sling
>> >> concepts for
>> >> > this are resource providers (and resource access security)
>> >> >
>> >> > Regards
>> >> > Carsten
>> >> >
>> >> >
>> >> > 2014-02-18 9:47 GMT+01:00 Tommaso Teofili
>> <tommaso.teof...@gmail.com>:
>> >> >
>> >> > > Does anyone else have any opinion and / or concerns? It'd be nice
>> >> > > if we can move forward.
>> >> > >
>> >> > > Regards,
>> >> > > Tommaso
>> >> > >
>> >> > >
>> >> > > 2014-02-14 2:29 GMT+01:00 Alexander Klimetschek
>> <aklim...@adobe.com>:
>> >> > >
>> >> > > > On 13.02.2014, at 13:44, Tommaso Teofili
>> >> > > > <tommaso.teof...@gmail.com>
>> >> > > > wrote:
>> >> > > >
>> >> > > > > I personally prefer the granular one as it's more resource
>> >> > > > > oriented,
>> >> > > > which
>> >> > > > > makes more sense in my opinion for an HTTP API (be it REST or
>> >> > > > > not)
>> >> > > >
>> >> > > > Regarding REST: It is closer to REST only once you send out
>> >> > > > links to the various options/commands.
>> >> > > >
>> >> > > > If the client needs to build the request itself and has to know
>> >> > > > URL patterns or other headers or payload paths, it misses the
>> >> > > > hypermedia constraint.
>> >> > > >
>> >> > > > So in itself, there is no real difference between granular and
>> >> > > > flatten in the proposal:
>> >> > > >
>> >> > > > POST /system/replication/agent/{agentName}/replicate
>> >> > > >
>> >> > > > and
>> >> > > >
>> >> > > > POST /system/replication/all/replicate { "agents" : [
>> >> > > > "publish1", "publish2" ] // ....
>> >> > > > }
>> >> > > >
>> >> > > > However, the granular one has the advantage that you can more
>> >> > > > easily do the linking, for example using standard <form> and hrefs.
>> >> > > >
>> >> > > > Basically, if you can browse it with some simple HTML pages and
>> >> > > > do everything (find all agents, look at agent state, clear
>> >> > > > queue, import package etc.), then this is good.
>> >> > > >
>> >> > > > Just my 2 cents
>> >> > > > Alex
>> >> > >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Carsten Ziegeler
>> >> > cziege...@apache.org
>> >>
