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:[email protected]]
> Sent: Friday, February 21, 2014 12:51 PM
> To: [email protected]
> 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
> <[email protected]> wrote:
> > Hi Marius,
> >
> > 2014-02-20 9:58 GMT+01:00 Marius Petria <[email protected]>:
> >
> >> 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:[email protected]]
> >> > Sent: Tuesday, February 18, 2014 11:15 AM
> >> > To: [email protected]
> >> > 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
> <[email protected]>:
> >> >
> >> > > 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
> <[email protected]>:
> >> > >
> >> > > > On 13.02.2014, at 13:44, Tommaso Teofili
> >> > > > <[email protected]>
> >> > > > 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
> >> > [email protected]
> >>
