Extending the SP Dynamic Metadata Provider

Cantor, Scott cantor.2 at osu.edu
Fri Oct 27 11:18:40 EDT 2017


On 10/27/17, 8:55 AM, "dev on behalf of Rod Widdowson" <dev-bounces at shibboleth.net on behalf of rdw at steadingsoftware.com> wrote:

> It probably makes the documentation easier.  I'd need to work out how to do it in the code.  I suppose you just register another
> factory and have that call the same constructor - the Folder MetadataProvider will be the paradigm to follow?

Yeah, I have other aliases in the code, it's all just symbolic to start with. You can easily polymorphize the code itself if you really care to make the behavior different in the two "types" by just having them examine the type attribute at runtime, but at that point it probably just becomes separate subclasses sharing a base class of course.
 
> I don’t see that in the documentation.  I'll poke at the code, or maybe Brent can chime in.  On the other hand, isn't reloading
> from the local cache not going to do much of what you want except when you are bootstrapping a new system.

Mostly, I imagine so. Maybe Brent did end up dumping the idea and just figured we'd handle it by querying the metadata using an API or something.

> As I researched this I realized that I had misinterpreted the local cache in the IdP.  It preloads the in memory cache with the
> contents of the disk cache.  This is can also be done in a worker thread, potentially deferred (hence more configuration).  The IdP
> uses "initializeFromPersistentCacheInBackground" and "backgroundInitializationFromCacheDelay".   Do these attribute names
> work ?  If so we'd probably want to us "persistentCacheDirectory" (dropping the IdP's "Manager" from the name since there is
> no pluggable manager for the SP.

I'd rather consistent names then start trying to "make them better" if it's really the same setting.

-- Scott




More information about the dev mailing list