I have raised: https://issues.apache.org/jira/browse/DIRSERVER-1625
to cover this. MikeA On 17 June 2011 16:25, Mike Adamson <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 >> >> >> >
