tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: Followup2: Changed behaviour of Tomcat Deployment/Context/Lifecycle Manager concerning symbolic links
Date Sat, 09 Mar 2019 09:44:04 GMT
On March 9, 2019 9:09:42 AM UTC, "Guido Jäkel" <G.Jaekel@DNB.DE> wrote:
>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?
>
>Guido
>
>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 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
>>>
>>>> (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: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org

This mailing list is the correct location should you have any follow-up questions.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message