Splitting the relying-party.xml

[Wessel, Keith]

Ah, got it. I was making false assumptions about the <import> element.

Thanks much, I think I'm off and running.

Keith


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Wednesday, August 26, 2020 10:00 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: Splitting the relying-party.xml

On 8/26/20, 10:46 AM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:

>    One more question on this. Scott, you said that metadata filters can be defined in separate files now. So, circling back
> to a variant of the question from my first note in this thread, is it better to add a second metadata providers config file
> as a second resource in services.xml or via a <import> element in the default metadata-providers.xml? I'm assuming a
> second resource in services.xml, but I wanted to make sure I wasn't missing something.

There are no <import> statements when any of the old custom XML formats are involved (metadata, resolver, filter).

There's no way for any of those syntaxes to directly include other files, you just have to add them as resources to the service.

If you're adding files with custom beans, then those files can import other files. But adding files to services that are reloadable is also necessary if you want it to detect them as having changed, it can't do that for imported files

But that's getting less and less interesting. I actually only rely on the filter service reloading on a timer now and I rarely change It anyway. The move to metadata has mostly obviated service reloads for me that aren't rare, and I usually do metadata reloads by hand that are more targeted.

I'm still not using Docker but the need to adapt to that general approach by the project has changed how I do things anyway.

-- Scott


-- 
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net