Good news! I reverted the change and this solve my issue at once, i.e. all former installed applications will start up as expected.
So, please what was the reason or intention here to shift from getPath() to getCanonicalPath() in case of a link (detected by !file.isAbsolute() )? What's the motivation to "fully expand" the path here at Java level instead of delegating this to the underlying OS? greetings Guido >-----Original Message----- >From: Jäkel, Guido [mailto:g.jae...@dnb.de] >Sent: Friday, March 08, 2019 11:39 AM >To: 'Tomcat Users List' <users@tomcat.apache.org> >Subject: Followup: Changed behaviour of Tomcat Deployment/Context/Lifecycle >Manager concerning symbolic links > > [...] > >And just from the names of the used methods, I wonder that the root cause is >the following change > > > diff -r -u > /var/tmp/portage/www-servers/tomcat-8.5.23/work/apache-tomcat-8.5.23- >src/java/org/apache/catalina/startup/ContextConfig.java >/var/tmp/portage/www-servers/tomcat-8.5.37/work/apache-tomcat-8.5.37- >src/java/org/apache/catalina/startup/ContextConfig.java > > [...] > @@ -589,7 +583,7 @@ > > File file = new File(docBase); > if (!file.isAbsolute()) { >- docBase = (new File(appBase, docBase)).getPath(); >+ docBase = (new File(appBase, docBase)).getCanonicalPath(); > } else { > docBase = file.getCanonicalPath(); > } > [...] > >(I'm going to check this out right now) > >May somebody point me to a ticket for the commit of this change and/or an >issue ticket leading to this change? I want to know >the motivation for this change and I want to please to find a solution to keep >the old behavior. Because in my eyes, the current >is inconsistent: For the context naming and so on, the well-known behavior is >kept -- the context is named by the naming of the >link itself and not of it's destination. And therefore, this should also hold >for all other aspects > > >greetings > >Guido
