idp 5.2.0 upgrade fails - org.opensaml.core.xml.config.XMLObjectProviderRegistry was unavailable

[Paul B. Henson]

I've run into an odd error while upgrading my dev idp instance from 5.1.6 to 5.2.0. After the upgrade it fails with the following logs:

2026-02-11 14:39:04,759 - / - DEBUG [net.shibboleth.idp.attribute.transcoding.impl.TranscodingRuleLoader:73] - Loading rules from directory (/opt/shibboleth-idp/conf/attributes/custom)
2026-02-11 14:39:04,838 - / - 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 'SAML2StringTranscoder' defined in class path resource [net/shibboleth/idp/conf/attribute-registry-system.xml]: Failed to instantiate [net.shibboleth.idp.saml.attribute.transcoding.impl.SAML2StringAttributeTranscoder]: Constructor threw exception
[...]
Caused by: java.lang.IllegalStateException: Configuration instance of type org.opensaml.core.xml.config.XMLObjectProviderRegistry was unavailable
at org.opensaml.core.config.ConfigurationService.ensure(ConfigurationService.java:113)

I package the idp in an rpm and deploy configuration from git, so I don't generally follow the recommended upgrade in place mechanism. I understand that is a "you broke it, you bought it" scenario ;), so I reverted my system to the working 5.1.6 configuration and did an upgrade in place:

Installation Directory: [/opt/shibboleth-idp] ?

INFO  - Update from version 5.1.6 to version 5.2.0
INFO  - Rebuilding /opt/shibboleth-idp/war/idp.war, Version 5.2.0 
INFO  - Initial populate from /opt/shibboleth-idp/dist/webapp to /opt/shibboleth-idp/webpapp.tmp 
INFO  - Overlay from /opt/shibboleth-idp/dist/plugin-webapp to /opt/shibboleth-idp/webpapp.tmp 
INFO  - Overlay from /opt/shibboleth-idp/edit-webapp to /opt/shibboleth-idp/webpapp.tmp                      
INFO  - Creating war file /opt/shibboleth-idp/war/idp.war 

Same issue. I set idp.loglevel.idp and idp.loglevel.opensaml to DEBUG and nothing of note showed up in the logs. The only interesting thing is that I don't see the call to initialize OpenSAML until after the failure which seems to say it's not initialized yet?

2026-02-11 14:39:06,966 - / - INFO [org.opensaml.core.config.InitializationService:47] - Initializing OpenSAML using the Java Services API

Hmm, looking at the logs from my working 5.1.6 installation, opensaml is initialized before the transcoding rules are loaded?

2026-02-11 15:04:22,792 - / - INFO [org.opensaml.core.config.InitializationService:47] - Initializing OpenSAML using the Java Services API 
2026-02-11 15:04:24,818 - / - DEBUG [net.shibboleth.idp.attribute.transcoding.impl.TranscodingRuleLoader:73] - Loading rules from directory (/opt/shibboleth-idp/conf/attributes/custom)

Is there perhaps something specific about my configuration that is causing this ordering issue? Or am I just the lucky guy running into a race condition for the first time? Or is this just a red herring?

Thanks...

--
Paul B. Henson | Operating Systems and Network Analyst
henson at cpp.edu | California State Polytechnic University Pomona