You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Mike Adamson <mi...@gmail.com> on 2011/06/17 16:16:55 UTC
Getting a LdapSchemaViolationException when modifying a
prescriptiveAci on an administrativeSubEntry
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
Re: Getting a LdapSchemaViolationException when modifying a
prescriptiveAci on an administrativeSubEntry
Posted by Kiran Ayyagari <ka...@apache.org>.
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 <mi...@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 <mi...@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 <ka...@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" <mi...@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
Re: Getting a LdapSchemaViolationException when modifying a
prescriptiveAci on an administrativeSubEntry
Posted by Mike Adamson <mi...@gmail.com>.
I have raised:
https://issues.apache.org/jira/browse/DIRSERVER-1625
to cover this.
MikeA
On 17 June 2011 16:25, Mike Adamson <mi...@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 <ka...@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" <mi...@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
>>
>>
>>
>
Re: Getting a LdapSchemaViolationException when modifying a
prescriptiveAci on an administrativeSubEntry
Posted by Mike Adamson <mi...@gmail.com>.
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 <ka...@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" <mi...@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
>
>
>
Re: Getting a LdapSchemaViolationException when modifying a
prescriptiveAci on an administrativeSubEntry
Posted by Kiran Ayyagari <ka...@apache.org>.
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" <mi...@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