Update attribute problem

[hasdy]

I've seen some related threads but I don't think they're exactly the same.
I'm on the latest v1.2..... using Active directory

so here's the jist of my code:

DistinguishedName dn = new DistinguishedName(dnString);

DirContextAdapter ctx = (DirContextAdapter) ldapTemplate.lookup(dn);
ctx = setAttributes(ctx, user);
ldapTemplate.modifyAttributes(dn, ctx.getModificationItems());

Where setAttributes does a whole bunch of:

adapter.setAttributeValue("blah", user.getBlah());

I'm able to update some of the values.... and I can't with some. For example, I try to update the "manager" value (which is a DN). I put in some debug code before the call to modifyAttributes(....):

		ModificationItem mi[] = ctx.getModificationItems();
		System.out.println("Mod Items count " + mi.length);
		int j=0;
		while(j < mi.length){
			System.out.println("modItem " + mi[j].toString());
			j++;
		}

And the output looks good...... all the items that I want changed are there and so are their values.

No exceptions thrown or anything.....

So where am I going wrong?

Or is this a known problem?

Thanks!

[hasdy]

I've also tried using

DirContextOperations ctx = (DirContextOperations) ldapTemplate.lookupContext(dn);
ctx = setAttributes(ctx, user);
ldapTemplate.modifyAttributes(ctx);

Still no go.

[hasdy]

Further findings:

So I threw a packet sniffer on the server.....
And it seems as though it does a modifyRequest with the new value of an attribute....
then it throws another modifyRequest with the old value of the attribute.

Whats going on here? Seems its doing a rollback.... but why?

The only difference i notice between the 2 modifyRequests that occur is that one object is of type:

cn=somesuser, ou=ABC,dc=xyz,dc=com
and the second one is
CN=someuser,OU=ABC,DC=xyz,DC=com

Could the case and/or whitespace affect the modify request?

Any help is appreciated.

Thanks!

[rasky]

It's still a little bit unclear what your problem is (can't really figure out whether an attribute that's supposed to be updated isn't or if it's the other way around).

Anyway, whitespace differences will cause DirContextAdapter to think that an attribute value changed, case differences won't.

Does that help you at all? If not, please try to clarify the problem.

[hasdy]

thanks for your reply...to clarify....

I am doing an update on a user....with the code mentioned previously.
And this user has a number of attributes..... phone, fax, title, manager.....etc.

From a high level when I run the code, I can see that the appropriate ModificationItems are created and then it goes into the ldapTemplate.modifyAttributes(ctx). I've verified that the data has not been updated but no exceptions are thrown.

Note: It updates some attributes but not others (ie will update 'floor' attribute but not 'telephoneNumber' attribute)

Using a packet sniffer, I noticed that it actually sends 2 modify requests to ldap. The first request is with the new data (as expected) then it sends another one with the old data (which seems like a rollback) but I don't know why.

The kicker: the exact same code works on my local environment.... and this problem is occurring in our dev environment. Both my local and dev are pointing to the exact same Active Directory server and using the exact same system user. Locally, when I run the code, using the packet sniffer, I notice only 1 modify request with the new data (as expected) but unlike the dev environment, it does not send the 2nd request.

Hope that clears things up a bit...... and I hope you can point me in the right direction

[rasky]

The ModificationItems are just delivered to the underlying JNDI layer; the actual low-level update is completely out of our hands. That is all handled by the Java LDAP provider. If the ModificationItems you get from DirContextAdapter are OK everything's pretty much out of our hands.

The problem seems pretty strange - I must admit I'm pretty much at a loss here. It looks like some kind of environment mismatch.

Different JVMs/libraries?
Access permissions (based on ip/certificates)?

[hasdy]

Strange problem indeed....
Same JVM and the only access permission is based on the application user... which is the same for both my local and dev environment.

So I have another question ... coming at a different angle.

Since the modificationItems are correct and they are being sent to the underlying LDAP provider.... in what cases would the LDAP provider send the original request off then send another request with the old values (rollback?)?

Another finding... which may be a clue..... as I mentioned only some of the attributes are updating properly....
If my ModificationItems array is 5 items..... the subsequent request has 3 items with the old values. So 2 of them update while the others are rolled back.
It also seems consistent as to which attributes are being updated and which aren't. And again, the same code works on my local environment by not the dev... using the same LDAP server (Active Directory) and the same application user.

Also, there are no errors or rejections from the Active Directory based on the logs.

weird...... any help is appreciated.

Thanks

[hasdy]

I notice there is a ModifyAttributesOperationExecutor that calls a rollback.... does this play into the equation at some point?

[rasky]

Ah, is it a rollback? That would explain some of this. That means something went wrong somewhere (i.e. an exception was thrown or the transaction war rolled back explicitly). It still doesn't explain why some things are left and some are rolled back however. I would expect it to be all or nothing.

First of all you should try to find out what's causing the rollback. Once that's figured out we should try to explain why not everything is rolled back. I'm very interested in that part.

[rasky]

BTW, try to turn off transactions for starters and see what happens in dev environment.