directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRSERVER-1080) LDAP modify operation does not create or update necessary operational attributes within an entry
Date Wed, 03 Oct 2007 00:27:50 GMT

    [ https://issues.apache.org/jira/browse/DIRSERVER-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531970
] 

Emmanuel Lecharny commented on DIRSERVER-1080:
----------------------------------------------

I have a fix for this issue, but it generate incredibly bad collateral dammages ...

The problem is that OperationnlAttribute interceptor is called before the schemaService interceptor.
Not sure that it's a good idea, because the OperationalAttribute interceptor add some new
attributes to the entry, and this has side effect : the schema interceptor for instance does
not like that an attribute is present in the modification list, as it's an operational attribute,
and thus is not supposed to be modified by a user !

If I add a flag in the ModificationItem class, to signal the fact that the attribute has been
added by the server, everything goes fine but... some tests are failing in another place.
For instance, replacing an inexistent attribute is supposed to do nothing. Before the fix,
as the ops attribute where not added, we where in a situation where we tested the presence
of such an inexistent attribute by checking ... the number of modification !!! If this number
was 1, then we were fine: 
        // -------------------------------------------------------------------
        // DIRSERVER-646 Fix: Replacing an unknown attribute with no values 
        // (deletion) causes an error
        // -------------------------------------------------------------------
        
        if ( ( mods.length == 1 ) && 
             ( mods[0].getAttribute().size() == 0 ) && 
             ( mods[0].getModificationOp() == DirContext.REPLACE_ATTRIBUTE ) &&
             ! atRegistry.hasAttributeType( mods[0].getAttribute().getID() ) )
        {
            return;
        }

Obviously a bad hack, and certainly not a fix.

So I will reopen this other issue, and we will think about moving the operationalAttribute
interceptor down in the list of interceptors to fix the current problem without modifying
the server...

Damn !

> LDAP modify operation does not create or update necessary operational attributes within
an entry
> ------------------------------------------------------------------------------------------------
>
>                 Key: DIRSERVER-1080
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1080
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: ldap
>    Affects Versions: 1.5.1
>         Environment: * ApacheDS 1.5.1 
> * Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
> * Windows XP Professional SP2
>            Reporter: Stefan Zoerner
>
> If an existing entry is modified (e.g. additional attribute addition), and the operational
attributes "modifiersName" and "modifyTimestamp" are not present, they are not present afterwards
as well. 
> I have extended the existing test case org.apache.directory.server.core.operational.OperationalAttributeServiceITest
in order to demonstrate this and to depict the desired behavior (svn commit follows).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message