configuring an attribute resolver

[Cantor, Scott]

On 7/1/15, 12:38 PM, "dev on behalf of Jim Fox" <dev-bounces at shibboleth.net on behalf of fox at washington.edu> wrote:



>
>I am migrating a custom attribute resolver from V2 to V3.

A custom resolver or a custom plugin to the resolver? I assume the latter...

>There are many ways to configure it in V3: ApplicationManagedConnection, BeanManagedConnection, and springResourcesRef (and others).

For JDBC data sources, yes. That's not really an extension point per se, it's just more ways to get a DataSource bean injected into a connector.

>It appears that I could use the springResources option and avoid implementing a parser alltogether.  Is that feasible?  Is that the direction the project is taking?

You can avoid custom parsing anywhere you can get a bean reference injected, but that has limits. I don't think you can easily plug in a DataConnector without one, because I don't think you can specify a dependency on it through a native bean reference. The resolver itself is still wired together like before.

We're definitely in favor of *not* using ApplicationManagedConnection to configure the data sources because that's less efficient and more limiting than just defining a shared bean with any settings needed and just sharing it, but that's a specific case.

The resolver in general is still mostly expected to be configured like before. There are edge cases we're not going to build parsers for, like referencing condition beans to control things because we can't wire up every possible condition somebody might want to build, so that's native Spring for advanced users. But the basic tree of definitions and connectors is not going to be native, I don't think. That didn't appear to be a fruitful direction for this file or the filter file.

-- Scott