Circular dependency in attribute resolver

Rod Widdowson rdw at
Thu May 12 07:51:20 EDT 2016

So, as I understand it the problem comes that you really have two attributes called "umnCareerOffice" one which exits the LDAP and one from a ScriptedDefinition which ends up being encoded for the SP.

Because they have the same name you get tripped up  by a circular dependency.  But you may also get all sorts of strange side effects if the LDAP attribute escapes into the wild.

I suspect that if I (re)read the code carefully I could come up with a way of doing this which would work for the code as it currently is, but I am always leery of pushing the edges here, since you often don't get what you expect.   If it were I, I would preserve my sanity by renaming the LDAP attribute _at the DataConnector_ to umnCareerOfficeLDAP ((<Column column=" umnCareerOffic" attributeID=" umnCareerOfficeLDAP "/>) and then leave the rest of your chain intact (but with umnCareerOfficeSplit depending on umnCareerOfficeLDAP).

Alternatively you could make the output umnCareerOfficeOut, and change all the filters and encoders...

>  My understanding of what Dependency actually means is sort of fuzzy.

Keep it that way and you will be successful.  If you think you understand it and start pushing the edges you will encounter things which don't work the way you'd expect.


More information about the users mailing list