IDP3 documentation regarding StoredId deprecated class

[Cantor, Scott]

On 3/21/16, 3:42 PM, "users on behalf of Charles R. Tompkins" <users-bounces at shibboleth.net on behalf of crt at ufl.edu> wrote:



>I just noticed that the documentation page
>https://wiki.shibboleth.net/confluence/display/IDP30/PersistentNameIDGenerat
>ionConfiguration appears to indicate there are two classes
>"JDBCPersistentIdStore" and "JDBCPersistentIdStoreEx".

Those by themselves aren't class names. Both are implementation classes, and before I redid everything when I fixed the race conditions, the only way to actually specify the storage was to define a bean using an implementation class. The new version provides a parent bean to inherit from that is defined to be of the appropriate type.

>My question is which one is being deprecated?

The class net.shibboleth.idp.saml.nameid.impl.JDBCPersistentIdStore is deprecated. The replacement for it is an implementation detail that you don't generally need to care about, but it happens to be net.shibboleth.idp.saml.nameid.impl.JDBCPersistentIdStoreEx.

>  The 3.2+ example "Example
>persistent ID store beans in saml-nameid.xml" shows "JDBCPersistentIdStore"
>in use,

No, it doesn't.

> but the proceeding text says "... you want to override some of the
>settings available, latter property can be used to point to a bean of type
>JDBCPersistentIdStoreEx, as shown below."

The bean called shibboleth.JDBCPersistentIdStore is defined to be of that type, and if it needed to be changed to use a different class at some point, we're free to do that as long as the properties that class supports are still supported.

Anywhere you have a user-editable file with a class name in it that's an implementation class, we essentially have, or had, a bug (or you have an issue in terms of creating a customization but are using internal classes and are at risk during upgrades).

The race conditions were bad, but it was arguably worse that the implementation class was exposed.

-- Scott