directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: Getting a LdapSchemaViolationException when modifying a prescriptiveAci on an administrativeSubEntry
Date Tue, 21 Jun 2011 08:03:58 GMT
Hi Mike,

    This issue is no more present can you try with the latest trunk code

On Mon, Jun 20, 2011 at 2:09 PM, Mike Adamson <mikeatdot@gmail.com> wrote:
> I have raised:
>
> https://issues.apache.org/jira/browse/DIRSERVER-1625
>
> to cover this.
>
> MikeA
>
> On 17 June 2011 16:25, Mike Adamson <mikeatdot@gmail.com> wrote:
>>
>> Hi,
>>
>> I will raise one first thing on Monday, unfortunately I've been told I've
>> got to stop now and pack the car.
>>
>> I have managed to work around this problem for the time being by using the
>> adminSession to set the acis but this isn't ideal because it loses the audit
>> trail.
>>
>> MikeA
>>
>> On 17 June 2011 16:14, Kiran Ayyagari <kayyagari@apache.org> wrote:
>>>
>>> Hi Mike, this seems to be a side effect of the recent changes done to the
>>> lookup() method, can you file a bug report in JIRA, thanks
>>>
>>> On 17-Jun-2011 7:48 PM, "Mike Adamson" <mikeatdot@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> I am attempting to replace a prescriptiveAci on a sub entry using:
>>>
>>> Entry subEntry = session.lookup(subEntryDn, "+");
>>> ModifyRequest modifyRequest = new
>>> ModifyRequestImpl().setName(subEntryDn).replace("prescriptiveAci", aci);
>>> session.modify(modifyRequest);
>>>
>>> but this always throws a LdapSchemaViolationException.
>>>
>>> I have done some debugging in the code and found that this is coming from
>>> the TupleCache.hasPrecriptiveAci method. It is thrown because this methods
>>> identifies the dn as an administrative sub entry but can't find the
>>> precriptiveAci on it. The root cause of this is this code at the bottom of
>>> the AciAuthorizationInterceptor.modify method:
>>>
>>>         Entry modifiedEntry = modifyContext.lookup( dn,
>>> ByPassConstants.LOOKUP_BYPASS );
>>>         tupleCache.subentryModified( dn, mods, modifiedEntry );
>>>
>>> This lookup does not return the operationalAttributes so will always fail
>>> when modifying an operationalAttribute.
>>>
>>> Is this by design? E.g. is it not possible to modify
>>> operationalAttributes in this way.
>>>
>>> Thanks,
>>>
>>> Mike Adamson
>>>
>>>
>>
>
>



-- 
Kiran Ayyagari

Mime
View raw message