On 08/03/2019 11:59, Jäkel, Guido wrote: > 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?
Tomcat is an open source project. git (and svn that we used until recently) provides a feature that lets you identify the most recent commit associated with any line of code. Every commit includes a log message. That is usually where you'd find an explanation for why a commit was made. Have you tried looking? Mark > > 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
