Am 04.11.15 um 19:17 schrieb Robert Munteanu: > On Wed, 2015-11-04 at 18:51 +0100, Carsten Ziegeler wrote: >> Am 04.11.15 um 17:26 schrieb Bertrand Delacretaz: >>> On Wed, Nov 4, 2015 at 5:22 PM, Bertrand Delacretaz >>> <bdelacre...@apache.org> wrote: >>>> ...Antonio recently created a bunch of "Remove >>>> loginAdministrative() >>>> usage" tickets for several of our components (SLING-5227 for >>>> example).... >>> >>> This also means backward compatibility issues, as the modified >>> modules >>> will require the corresponding service users to exist. >>> >>> We probably need a super simple mechanism for creating those users >>> - >>> maybe embed their definitions in the corresponding bundles, and let >>> an >>> (optional) bundle process them. >>> >> >> No, the user and also the ACL must not be part of the bundle - it is >> not >> the concern of the implementation to create the user and setup the >> ACLs. >> We must not mix these things. >> And this is also fragile, bringing in yet another mechanism to do >> something does not make our system more stable. We already have most >> pieces in place for provisioning: the OSGi installer and friends. >> For installing content, and users and ACLs are content, we have the >> JCR >> contentloader. >> >> I suggest we create for each feature a separate bundle with the user >> definition and the ACLs. The stuff gets then installed - like any >> other >> content - through the contentloader. > > A brief look at the jcr.contentloader bundle leads me to believe that > we do not have support for installing users and ACLs, and must add it > instead. > Ok, but that shouldn't be too hard and is imho the better approach compared to add yet another bundle listening for bundles and doing something. We also must be very clear and what happens when such bundle gets uninstalled, no matter which approach we take.
But my main point is: let's not mix concerns just because its easy for the developer. Now another option is to do some additional handling in the provisioning model, so instead of creating an artificial bundle, we could support having a "free" text section in the provisioning model which then gets processed in some way. I think, this would be the easiest way: you define the service user, security configuration (which is already part of the provisioning model) and ACLs as part of the provisioning model. That's super easy, user friendly and we just need to find a way to get this interpreted. Easiest way, the tooling creates a bundle :) which then gets picked up by the jcr contentloader. I personally would prefer having everything in the provisioning model instead of "hiding" it in bundles - no matter how it really ends up in the runtime. Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
