FIXED: Porting advanced v2 resolver config to v3

[Cantor, Scott]

On 2/11/15, 3:43 PM, "Marvin Addison" <marvin.addison at gmail.com> wrote:



>I'm fairly certain that the root cause is that I was missing a dependency 
>reference.
>I defined the ResultCache here since the config was more succinct, though 
>it still seems like the cache is not shared between data connectors with 
>that config; if that's
> correct then cache sharing isn't needed. I don't care about caching 
>mechanics as long as attribute resolution works, which it does.

Caching is always per connector in V2. Each connector has its own cache 
and just uses that to auto-return results when it's asked to resolve. It's 
done inside the connectors, not at a more general level across the 
resolver.

With V3, it's possible to share a cache bean, but to be honest that's 
probably not advisable. I don't know if Rod changed that code, but it 
doesn't seem like it would be very safe unless the result sets are somehow 
labeled with the connector ID.

It's contrived, but it seems like you could have overlapping statements 
intended for different connectors/sources, but they'd look like the same 
cache entry.

I think the use case for having a separate bean were to configure more 
advanced cache settings or implementations using the Guava stuff rather 
than sharing a cache.

>Also, I want to clarify that expressions like the following still work in 
>v3:
>
>(entitled=uid=$uid.get(0),ou=people,dc=vt,dc=edu)
>
>Where $uid is an attribute resolved by a dependency data connector.

They're certainly supposed to (and it should work for either data 
connector-produced attributes or for attribute definitions).

In both versions, $uid really doesn't refer to the IdPAttribute object 
called "uid", but to a list of its values. It's pretty much identical code 
between V2 and V3 in the specific case of what gets put into Velocity for 
that key.

-- Scott