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 > > >
