Stored persistent ID and migration to 3.2

[Cantor, Scott]

On 12/9/15, 3:51 PM, "users on behalf of Chris Phillips" <users-bounces at shibboleth.net on behalf of Chris.Phillips at canarie.ca> wrote:



>As Scott commented in this thread earlier, there WAS another datasource
>property in play in attribute-filter.xml which was/is for
>eduPersonTargetedId generation/storage in a mysql DB using the StoredId
>connector approach.

You mean resolver, not filter.

>First question: 
>That connector has no ability to handle the retry conditions and there's
>no way to configure it to in attribute-resolver.xml -- or is there?

Umm, doubt it. I probably didn't circle back to it other than making sure the updated classes got spun up at runtime in place of the old ones. The underlying code is the same, but the config isn't and would have to be specially handled. Not out of the realm of possibility.

>Given that, I looked at attempting to re-use the bean references in
>saml-nameid.xml in attribute-resolver.xml and they were not available. I
>assume it's a sequence of events thing where the beans in saml-nameid.xml
>are instantiated AFTER the resolver is in place.

They're not visible to each other at all, the two Spring contexts are siblings.

>Since I encountered that problem, I took the approach inspired by the
>StorageConfiguration[1] with the technique from
>PersistentNameIDGenerationConfiguration[2] persistentID Store, and created
>this in global.xml thinking I could create a global datasource connector
>just like the one in saml-nameid.xml to handle the extra retryableErrors
>conditions but available more globally:

No, there's no way to inject it into the resolver plugin.

>Which I then refer to in attribute-resolver.xml that I can then refer to
>via a BeanManaged Connection:

No, you can't. One is a plain JDBC DataSource and one is a special object of a different interface.

>However, what I get is the following stack trace saying that the the
>Beantype is not the right type and yet this technique works in
>saml-nameid.xml:

The target bean there knows how to accept both types of objects.

>A. How StorageConfiguration[1] escapes the problem of the retry scenario?

Doesn't.

>If I can't do this bean approach to capture retry conditions is the
>StorageConfiguration going to suffer the same risk as the saml-nameid.xml
>connection pool, and if so, how would one deal with that? Is this a bug
>yet to be encountered by the JPA/global.xml storage?

I wouldn't say never, but I believe the JPA code sees an exception type indicating an insert failed due to a duplicate. Whether that exception is raised reliably I couldn't say.

>B. What is the recommended way to handle database connections in
>attribute-resolver.xml in Shib 3.2.0 that need to trap the retry scenario
>and avoid the WARN statement?

There isn't one.

>C. If the attribute-resolver.xml can properly route the population of
>ePTId to the saml-nameid.xml configuration where it may (should?) reside
>what is the recommended way to do that?

It could never do that. They can share a DataSource, that's about it.

-- Scott