Explanation of multi-value attribute updates

[myearick]

This is my first time using Spring LDAP and I am having some problems updating multi-value attributes. I am trying to add a user to a set of groups and also to a set of roles. Both of which are multi-value attributes. I am reading the user prior to the update and then attempting to perform the modiftyAttributes call. I receive a "LDAP error code 20 - Attribute Or Value Exists". After reading the user and applying the changes to the context, I dump out the ModificationItem array and the multi-value attribute seems to always have an Add as the operation. This works fine when I add the user to the first group or role, but once the user is in one role or group, then any subsequent "updates" fail with the error message above (obviously because it is trying to add a role/group value which already exists). I noticed that the ModificationItem only has a single operation value, so I am not sure how this would work for multi-value attributes where one or more values could be an add and others could be deletes. Does Spring LDAP handle this scenario or am I missing something?

I am using Sun Directory Server Enterprise Edition version 6.3 and spring ldap 1.3.0

After some extensive searching, I believe that I have discovered what is causing this problem, but I am unsure of the best way to fix it. I am performing a ldapTemplate.lookupContext call prior to mapping my changes to the context. The problem lies in the fact that the multi-valued attributes I am changing are actually subentries which means that they are not normally retreived during lookups. When I perform the updates to the context, it assumes because they are not there that everything is an add. I have resolved this in other parts of my code by providing an explicit list of attribute names to retrieve. Unluckily, I don't see an option for this on the lookupContext method. I will continue to look at this further, but if anyone has any suggestions, they would be appreciated.

[rasky]

Quite right, there seems to be a missing method here. It is possible to do: you might just use the lookup method that takes an attribute list and a ContextMapper, providing a dummy context mapper that just returns the DirContextAdapter instance.

Now, there really should be a lookup method that takes an attribute list as well. Feel free to add a JIRA issue on this if you find it important enough.
Cheers,

[myearick]

I was prepared to tell you what a brilliant idea this was, but it didn't work. I received an error indicating that "The DirContextOperations instance needs to be properly initialized". I believe the problem is that by doing the lookup in this way, the context is not set to "update" mode which I believe I have seen a number of posts regarding. Is there a way around this?

[myearick]

The answer to this question was to cast the DirContextOperations object returned back to a DirContextAdapter and use the setUpdateMode method to turn on update mode prior to applying changes to the context.

So, to wrap up this post, due to the fact that the attributes I was trying to modify are subentries, then you have to explicitly request them using the lookup methods which allow an array of attribute names to be passed in. This will return all the attributes that you request (including subentries, i.e. operational attributes). I then had to create an AbstractContextMapper which just returned the DirContextOperations object (normally it would return an application object). Finally, I had to cast this back to a DirContextAdapter and set the update mode to true. This allowed me to make the changes to the context and call the modifyAttributes method on ldapTemplate.

Thanks for all the help.

[ulsa]

This will return all the attributes that you request (including subentries, i.e. operational attributes).

I believe there is a significant difference between subentries and operational attributes. Subentries are entries that must be explicitly asked for, while operational attributes are attributes that must be explicitly asked for.