Attribute resolver dependency question/issue

[Tom Poage]

On 05/03/2012 11:15 AM, Chad La Joie wrote:
> On Thu, May 3, 2012 at 1:52 PM, Tom Poage <tfpoage at ucdavis.edu> wrote:
>> The definitions are defined in the above order. Is definition order
>> important in terms of triggering desired behavior?
> 
> No.  The order of plugin resolution is determined by the declaration
> of one plugin depending on another.

Good. Faith in my understanding of this is restored. :-)

>> Is this simply a case of ambiguity, where the LDAP attribute name is the
>> same as the attribute id?
> 
> I don't know, what you have right now will result in the following process:
> - LDAP data connector will run
> - The scripted attribute definition will run, create a new attribute
> called "eduPersonAffiliation" and give it a value of "member"

OK. I was under the impression that if the attribute existed (i.e. had a
value in LDAP), the script would operate on that list of values, the
'new' only being there if nothing was pulled from the directory (to
avoid an exception calling getValues() on a NULL).

> - The Scoped attribute definition will run and pull in the values for
> the "eduPersonAffiliation" (exact match on that name) LDAP attribute
> and the "eduPersonAffiliation" attribute from the scripted data
> connector and append the ucdavis.edu scope to all of them.

Ah, I didn't see them as separate containers that happened to have the
same identifier. Basically I wanted to add "member" if any value existed
in the LDAP attribute and remove the internal/legacy value "external",
leaving other values ("staff", "faculty", "student") intact. More or less:

>   if (eduPersonAffiliation.getValues().isEmpty() == false) {
>       eduPersonAffiliation.getValues().add("member");
>       if (eduPersonAffiliation.getValues().contains("external")) {
>           eduPersonAffiliation.getValues().remove("external");
>       }
>   }

(though the removal was actually being done in attribute-filter.xml).

>> Lastly, the wiki page above indicates id="..." instead of ref="..." for
>> resolver:Dependency. I don't see 'id' in the XSD (or perhaps I'm not
>> reading it correctly).
> 
> That was a typo and has now been fixed.

Thank you!
Tom.