[EXT] idp 5.2.0 upgrade fails - org.opensaml.core.xml.config.XMLObjectProviderRegistry was unavailable
Paul B. Henson
henson at cpp.edu
Thu Feb 12 02:32:47 UTC 2026
On Thu, Feb 12, 2026 at 02:05:06AM +0000, Paul B. Henson via users wrote:
> Is this a bug? Is there somewhere else other than global.xml I'm
> supposed to define this bean now? I don't recall why I defined it there,
> other than that's where all my random local custom beans are defined.
I tried moving the bean from global.xml to oidc-clientinfo-resolvers.xml;
it doesn't fail to start but it seems the bean isn't found in that
location:
2026-02-11 18:08:52,903 - / - WARN
[net.shibboleth.oidc.metadata.keyinfo.ext.impl.provider.ClientSecretReferenceProvider:98] - No values could be resolved for the client secret reference openidconnect.net
I tried putting it in services.xml but then it failed to process
relying-party.xml 8-/.
2026-02-11 18:17:59,567 - / - WARN [net.shibboleth.shared.spring.context.FilesystemGenericApplicationContext:628] - Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'shibboleth.UnverifiedRelyingParty' defined in file [/opt/shibboleth-idp/conf/relying-party.xml]: Cannot resolve reference to bean 'shibboleth.DefaultSecurityConfiguration' while setting bean property 'securityConfiguration'
I think I'll stop trying to stick it in random places for now <sigh>.
> That just isn't really a "configuration" sort of error, it's deep
> inside the system during startup. I'm not sure it's even possible to
> trigger it with a configuration change.
Seems you can :). Is there a prize for finding the most obscure bugs you
didn't think were possible ;)?
--
Paul B. Henson | Operating Systems and Network Analyst
henson at cpp.edu | California State Polytechnic University Pomona
More information about the users
mailing list