IDP3 documentation regarding StoredId deprecated class

[Charles R. Tompkins]

> -----Original Message-----
> From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor,
> Scott
> Sent: Monday, March 21, 2016 6:43 PM
> To: Shib Users <users at shibboleth.net>
> Subject: Re: IDP3 documentation regarding StoredId deprecated class
> 
> 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/PersistentNameIDGe
> nerat
> >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
> 

Ok, that jives with what I'm seeing in system/conf/saml-nameid-system.xml.
Thanks for the explanation.

Can the "dataSource-ref" property for the idp.persistentId.store bean be
sourced by a bean managed connection in global.xml (shared by the
attribute-resolver data connectors) or does idp.persistentId.dataStore need
to be specified independently in saml-nameid.xml for idp.persistentId.store
to invoke from? 

-Charles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4793 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/users/attachments/20160321/ad12eb29/attachment.p7s>