On Monday 07 November 2016 10:43:18 Roy Teeuwen wrote: > Hey Oliver, Hi Roy,
> Forcing a user of a bundle to go and look up the git project to find the > README.md to see which permissions are needed doesn't sound like a good > solution for me, it should be present somehow in the built jar from the > maven central repo. So I would also go for the manifest file here like > Carsten proposed. you are usually using a distribution (Sling Launchpad or AEM) where users and ACLs are already configured. Using a single bundle without looking into it's documentation is a rather rare case. > I can follow that the provide capability could be something more of a nice > to have seeing as Carsten said in his first reply, it should be the user > who puts up the mapping between the users and the bundles that need the > service users. But he should of course know that he needs to do this, hence > the need for the require capability. If a bundle requires a capability the system has to provide that capability otherwise the bundle would not resolve. Does it make sense to express these requirements by OSGi Capabilities? When running Sling with Mongo you also have to look into documentation and set up host and port – do you expect that also to be expressed by capabilities (a running MongoDB, no better example at hand but I guess you get the point)? Regards, O. > Greetings, > Roy > > > On 7 Nov 2016, at 10:05, Oliver Lietz <apa...@oliverlietz.de> wrote: > > > > On Monday 07 November 2016 07:58:33 Carsten Ziegeler wrote: > >> Roy Teeuwen wrote > > > > Hi Roy, > > > >>> Hey Carsten, > >>> > >>> Thanks for the info, I will definitely follow up on the progress of what > >>> you are making then :). > >>> > >>> One remark though, you say it's not the task of the bundle developer to > >>> create the user and assigning the rights. I can follow in this, but this > >>> also means that the potential users of the bundle you create has to know > >>> exactly the name of the service user and the rights required for the > >>> bundle to work. > > > > which service user is mapped to the bundle is not important – but it has > > to be a service user with sufficient permissions. > > To ensure a user mapping is present for your component before getting > > activated use ServiceUserMapped[1]. > > > > Which permissions (JCR ACLs) are required by a bundle should be documented > > in the module's README but for now you have to look at provisioning model > > in launchpad/builder. > > > >>> Is there going to be some sort of mechanism (like the > >>> require-capability header) to tell the users of the bundle what the > >>> needed user and rights are? Maybe even a webconsole plugin showing which > >>> bundles aren't satisfied > >> > >> That's indeed a good point, so far we don't have any mechanism here. > >> Defining the requirement is easy and we could add an entry to the > >> manifest of a bundle if the bundle requires a service user including the > >> sub module names. > >> > >> The problematic part is providing the capability as these can't be > >> dynamically created and added to a module at runtime. For example, it > >> would not be possible that the Oak implementation bundle adds the > >> provide capabilities entries based on the available service users. > >> > >> I think the only option we have is using OSGi services as these are > >> dynamic and requirements can be easily expressed through services. I > >> don't have any good idea on how to do this with service users, but I > >> should definitely be possible and I agree that we should provide > >> something like this. > > > > We would have to observe the repository for all system users' ACLs and > > provide both as capabilities (or services) – is it worth the effort? > > > > Regards, > > O. > > > > [1] > > https://sling.apache.org/apidocs/sling8/org/apache/sling/serviceusermappin > > g/ServiceUserMapped.html > > <https://sling.apache.org/apidocs/sling8/org/apache/sling/serviceusermapp > > ing/ServiceUserMapped.html>> > >> Regards > >> > >> Carsten
