tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: Followup2: Changed behaviour of Tomcat Deployment/Context/Lifecycle Manager concerning symbolic links
Date Sat, 09 Mar 2019 21:26:27 GMT
Hi Guido,

Am 09.03.2019 um 10:09 schrieb Guido Jäkel:
> Dear Mark,
> thank you for comments and hints. I would say I have a wide knowledge about hard and
software. But as I'm not working as a software developer, I'm not familiar with a lot of things
in deep. I also don't have key-ready workbenches or buildchains. But I'll try to locate the
corresponding commit using web access to the git. May I also contact you afterwards for further
steps? Should I try to open an issue on the git or should I start a discussion in the Tomcat
developer mailing list?

To add small hints: the project is available on Github, which provides 
an easy web interface for basic code archeology. E.g. the class you 
metioned can be viewed at

and that page contains buttons for "Blame" - which shows when and in 
which commit each line was changes last, and also "History" which shows 
the list of changes applied to that file.

The above link if for master (TC 9), but analogous pages exist for each 
branch, e.g.



> On 08.03.19 21:58, Mark Thomas wrote:
>> 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
>> 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
>>>> (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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message