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

[Takeshi NISHIMURA]

Hi Rod,

I did further investigation and found an essential cause.

If you change the "idp.war" file (inode) since Tomcat restart, you will see the error in 3.4.0 update.

For example, you will have trouble when you copy /opt/shibboleth-idp using these commands:
# rsync -aX /opt/shibboleth-idp/ /opt/shibboleth-idp-3.4.0
# mv -i /opt/shibboleth-idp /opt/shibboleth-idp-3.3.3
# ln -s shibbolhet-idp-3.4.0 /opt/shibboleth-idp
while Tomcat running. Needless to say, two WAR files:
/opt/shibboleth-idp-3.3.3/war/idp.war
/opt/shibboleth-idp-3.4.0/war/idp.war
exist and have different inodes and the original WAR file is the former. Then as install.sh will overwrite only the latter, the running Tomcat will act wrongly.

The key point is that both files (/opt/shibboleth-idp-3.3.3/war/idp.war and /opt/shibboleth-idp/war/idp.war aka /opt/shibboleth-idp-3.4.0/war/idp.war) seem to be watched for auto deployment but the former (the original file that was pointed by idp.xml when Tomcat started) seems to be used for real deployment.

I have confirmed this weirdness on all currently supported Tomcat packages from apache.org (7.0.91, 8.5.34, 9.0.12).

Anyway, this whole description assumes unpackWAR="false" configured. Otherwise you will not see such an error.

Best regards,
Takeshi

On 2018/10/25 1:22, Rod Widdowson wrote:
>> 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.
> 
> Did you get any further chasing this up?  Or does it end up as another "Tomcat is weird" situation?
> 
> /Rod