Ok, I just noticed I replied to a super old thread because my Email app decided
to surface it as if it were new :D
Cheers,
Alex
> On 01.10.2018, at 16:19, Alexander Klimetschek
> wrote:
>
> Hi Marius,
>
> AFAICS, what you describe below is exactly my @ServiceUser annotation, just
>
Hi Marius,
AFAICS, what you describe below is exactly my @ServiceUser annotation, just
different names and a different syntax for the ACLs :)
Cheers,
Alex
On 08.12.2015, at 08:09, Marius Petria wrote:
> I do not have a precise use case right now other than obtaining a “content
> access
Hi all,
I think the current proposal makes sense and deals with the deployment concerns
of service users. Would it make sense to express also the development
requirements for services? I know that has been discussed over and over again
but I wonder if instead of choosing one variant over
Hi,
On Tue, Dec 8, 2015 at 9:28 AM, Marius Petria wrote:
> ...2. Development definition of services and their requirements (defined by a
> developer)
> - this a a bundle concern and is a definition of services (not of
> users) and their needs
> - it does not
On 12/8/15, 4:16 PM, "Bertrand Delacretaz" wrote:
>The require method throws an Exception if the requested permissions
>are not granted.
>
>Using this in a bundle Activator or in a component's activate() method
>causes those activations to fail if permissions are
Hi,
On Mon, Nov 16, 2015 at 11:50 PM, Carsten Ziegeler wrote:
> ...do we have a solution now on how to
> define the service user and ACLs in the provisioning model?...
I'm hoping to find time to work on this soon, for now I had a look at
the ideas in JCRVLT-61 and chatted
This thread started two weeks ago, do we have a solution now on how to
define the service user and ACLs in the provisioning model? Without this
we shouldn't change our code and switch.
Regards
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
On Thu, Nov 5, 2015 at 9:48 AM, Carsten Ziegeler wrote:
> ...Keeping it separate from the beginning is the clearest way and works in
> all cases...
I agree as long as that separation does not complicate things more
than strictly needed - provisioning model sounds good,
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
>>> wrote:
...Antonio recently created a bunch of
Am 05.11.15 um 09:41 schrieb Bertrand Delacretaz:
> On Thu, Nov 5, 2015 at 9:35 AM, Carsten Ziegeler wrote:
>> ...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...
On Thu, Nov 5, 2015 at 9:35 AM, Carsten Ziegeler wrote:
> ...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...
That would work but for testing I think we also need
Am 05.11.15 um 09:39 schrieb Bertrand Delacretaz:
> Hi,
>
> On Wed, Nov 4, 2015 at 6:51 PM, Carsten Ziegeler wrote:
>> ...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
>>
Hi,
On Wed, Nov 4, 2015 at 6:51 PM, Carsten Ziegeler wrote:
> ...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
So taking SLING-5227 as
On Wed, Nov 4, 2015 at 5:22 PM, Bertrand Delacretaz
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
Hi,
Antonio recently created a bunch of "Remove loginAdministrative()
usage" tickets for several of our components (SLING-5227 for example).
While replacing the login calls is easy, I'm wondering how to test
these changes.
Do we have a simple mechanism for creating service users in
integration
hi Betrand,
thanks a lot for starting the email thread for this topic.
I am really keen on try to be as much constant as possible in the various areas
where the loginAdministrative should be replaced whit regards to:
- user creation
- ace handling
- testability
As this is a green field for
Am 04.11.15 um 17:26 schrieb Bertrand Delacretaz:
> On Wed, Nov 4, 2015 at 5:22 PM, Bertrand Delacretaz
> wrote:
>> ...Antonio recently created a bunch of "Remove loginAdministrative()
>> usage" tickets for several of our components (SLING-5227 for example)
>
> This
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
> > wrote:
> > > ...Antonio recently created a bunch of "Remove
> > > loginAdministrative()
> > > usage"
18 matches
Mail list logo