Auto deployment failure on CentOS 7 tomcat with unpackWAR="false" in 3.4.0 update

[Takeshi NISHIMURA]

Hi Rod,

Wow, so strange...

In our case, I removed "conditional:" in general-admin-system.xml. Then a ClassNotFound exception occurred. I thought there may be class confusion between updated packages and old packages.

Takeshi

> 2018/10/19 16:55, Rod Widdowson <rdw at steadingsoftware.com> wrote:
> 
> Takeshi-san,
> 
>> org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Failed to import bean definitions
>> from URL location [conditional:/opt/shibboleth-idp/conf/admin/unlock-keys.xml]
>> Offending resource: file [/opt/shibboleth-idp/system/conf/general-admin-system.xml]; nested exception is
>> org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from ServletContext resource
>> [/conditional:/opt/shibboleth-idp/conf/admin/unlock-keys.xml]; nested exception is java.io.FileNotFoundException: Could not open
>> ServletContext resource [/conditional:/opt/shibboleth-idp/conf/admin/unlock-keys.xml]
> 
> We saw this during development of 3.4 [1]
> 
> Whilst this is obviously not your cause (unless you are on windows), The TLDR is that the conditional beans are a "canary" for badly
> formed URLs, which in turn come from strangely define ClassPaths.
> 
> I'd be investigating whether Tomcat is doing something strange with the ClassPaths in the failed situation, or whether
> idp.properties is somehow being wrongly or partially set
> 
> [1]
> https://issues.shibboleth.net/jira/browse/IDP-1326?focusedCommentId=28521&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acom
> ment-tabpanel#comment-28521