Re: Followup2: Changed behaviour of Tomcat Deployment/Context/Lifecycle Manager concerning symbolic links
On 11/03/2019 21:19, Michael Osipov wrote: > Am 2019-03-11 um 09:03 schrieb Rainer Jung: >> I think Mark refers to this one: >> >> https://marc.info/?l=tomcat-dev=153856675022101=2 > > Thanks Rainer. > > So this is a fix for another issue which clearly causes a regression. Sort of. A failure was reported when running some of the unit tests on Windows. That was fixed in this commit: https://github.com/apache/tomcat/commit/62c04ea42f115533437bccaa7873416abecc8c6e#diff-717001e0451788fe9f26d1176a4fff54 That fix had the potential to hide future case-sensitivity regressions so it was re-worked in: https://github.com/apache/tomcat/commit/db71c925106915581f1b60b0fda9c352fcdd9138#diff-717001e0451788fe9f26d1176a4fff54 While investigating the failures above it was noticed that ContextConfig was inconsistent. If the user supplied an absolute value for the docBase, the canonical version of that path was set as the docBase on the Context. If the user supplied a relative value for the docBase, the value was passed as is. There is no good reason that I can see for that inconsistency and potential (unproven) for things to break if the docBase contained sequences like "../..". Hence: https://github.com/apache/tomcat/commit/fd2abbb525660a9968694afd99a58f8c22cb54c6 There are actually 3 different options for making those calls consistent: - getPath() - getAbsolutePath() - getCanonicalPath() getAbsolutePath() wasn't considered as it wasn't one of the options already in use and the preference was to keep change to a minimum. The value (part of it anyway) ends up stored in the Context docBase and the general expectation in the code is that that value is absolute / canonical hence getCanonicalPath() was chosen. > Looking into RFC 8089 (proposed), E.2 talks about canonicalization of > driver letters. The behaviour described there is consistent with observed behaviour with current Microsoft operating systems. Based on experience, I'd rather ask the OS what that it considers to the canonical path than rely on an RFC. > This needs to be taken care of solving both issues. > > @Guido, please create a BZ issue with a minimal test case. It is, and it isn't, quite that simple. I've spent a chunk of time today experimenting with this code to see what the impacts are, if any, of reverting to using getPath() here. On the plus side, I haven't been able to find a combination of code and configuration that breaks with either getPath() or getCanonicalPath(). I haven't tested it but I'm confident that if both those methods are OK then getAbsolutePath() will be OK as well. What I have also noticed is what seems like a large number of calls to getAbsolutePath() and getCanonicalPath(). Those are relatively expensive calls and I am wondering if there is scope for some performance improvement here. That needs a little more research as I was doing a lot of restarts and not paying attention to whether those calls were during restart or during request processing. Reducing calls during request processing will have a bigger performance improvement. Where things get interesting is, if there is scope to reduce the number of calls to getAbsolutePath() and/or getCanonicalPath(), to what extent do those improvements depend on the current code remaining as is? Looking at the code in ContextConfig.fixDocBase() it looks like it should be possible to switch lines 585 and 587 to use getAbsolutePath() without having too much impact on any performance improvements we may want to consider. That should address the regression. @Guido can you confirm that please? I can run the unit tests and if they pass and the correction of the regression is confirmed it should be possible to get the fix into the next set of releases. The next release is almost certainly too soon for completing the performance review. That is probably going to need to wait until the following set of releases. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Followup2: Changed behaviour of Tomcat Deployment/Context/Lifecycle Manager concerning symbolic links
Am 2019-03-11 um 09:03 schrieb Rainer Jung: Am 11.03.2019 um 08:09 schrieb Michael Osipov: Am 2019-03-10 um 22:29 schrieb Mark Thomas: On 10/03/2019 20:54, Michael Osipov wrote: Am 2019-03-10 um 12:16 schrieb Mark Thomas: On 10/03/2019 09:08, Guido Jäkel wrote: Dear John, Hi Rainer, Thank you for your hints. I leaned to used this features on Github locate the commit - it's https://github.com/apache/tomcat/commit/fd2abbb525660a9968694afd99a58f8c22cb54c6 and it was committed by Mark Thomas. I don't know about the Tomcat project policies, but IMHO in the commit comment there was not any real hit for the motivation for the change or any reference to an issue ticket or a pull request. There's just one sentence for the changelog: Ensure that a canonical path is always used for the docBase of a Context to ensure consistent behaviour. (markt) But I can't get any idea from that what the author (Mark?) want to say with the terms "ensure" and "consistent". And it's classified as a "fix", but up to now I was not able to find the use case that is said to be fixed with this. From my point of view, the change lead to something what might be termed with "inconsistent", because now the link name is used as docBase, but the link destination is used to decide concrete aspects of Context loading. @Rainer: I familiarize me with the blame/history feature and have located the commit with this. But now, please tell me how to object against this change? Should I prepare a Git pull request against the master repository? Should I open an Issue somewhere? And how to locate the discussion that lead to this change? This should be tied to prevent flapping and respect and arrange with the motivation there. Changes aren't made on a whim. It is recommended that you investigate why a change was made before objecting to it. When a commit message in isolation appears to be missing context then that context can normally be found on the dev@ list. The 24 hours of dev@ traffic leading up to this commit should provide all the necessary background. There aren't any. I see the commit mail in Thunderbird, but no discussion on the change: Message-Id: <20181003111609.0b0143a0...@svn01-us-west.apache.org> So, what now? The context is there on the dev@ list in the 24 hours leading up to that commit. Sorry, I seem to be blind. Can you point me to the discussion? I can't find anything in my tomcat-dev folder. I think Mark refers to this one: https://marc.info/?l=tomcat-dev=153856675022101=2 Thanks Rainer. So this is a fix for another issue which clearly causes a regression. Looking into RFC 8089 (proposed), E.2 talks about canonicalization of driver letters. This needs to be taken care of solving both issues. @Guido, please create a BZ issue with a minimal test case. Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Followup2: Changed behaviour of Tomcat Deployment/Context/Lifecycle Manager concerning symbolic links
>-Original Message- >From: Rainer Jung [mailto:rainer.j...@kippdata.de] >Sent: Monday, March 11, 2019 9:03 AM >To: Tomcat Users List ; Michael Osipov > >Subject: Re: Followup2: Changed behaviour of Tomcat >Deployment/Context/Lifecycle Manager concerning symbolic links > >Am 11.03.2019 um 08:09 schrieb Michael Osipov: >> Am 2019-03-10 um 22:29 schrieb Mark Thomas: >>> On 10/03/2019 20:54, Michael Osipov wrote: Am 2019-03-10 um 12:16 schrieb Mark Thomas: > On 10/03/2019 09:08, Guido Jäkel wrote: >> Dear John, Hi Rainer, >> >> Thank you for your hints. I leaned to used this features on Github >> locate the commit - it's >> >> >> https://github.com/apache/tomcat/commit/fd2abbb525660a9968694afd99a58f8c22cb54c6 >> >> >> >> and it was committed by Mark Thomas. I don't know about the Tomcat >> project policies, but IMHO in the commit comment there was not any >> real hit for the motivation for the change or any reference to an >> issue ticket or a pull request. There's just one sentence for the >> changelog: >> >> Ensure that a canonical path is always used for the docBase >> of a Context >> to ensure consistent behaviour. (markt) >> >> But I can't get any idea from that what the author (Mark?) want to >> say with the terms "ensure" and "consistent". And it's classified as >> a "fix", but up to now I was not able to find the use case that is >> said to be fixed with this. >> >> From my point of view, the change lead to something what might be >> termed with "inconsistent", because now the link name is used as >> docBase, but the link destination is used to decide concrete aspects >> of Context loading. >> >> >> >> @Rainer: I familiarize me with the blame/history feature and have >> located the commit with this. But now, please tell me how to object >> against this change? Should I prepare a Git pull request against the >> master repository? Should I open an Issue somewhere? And how to >> locate the discussion that lead to this change? This should be tied >> to prevent flapping and respect and arrange with the motivation there. > > Changes aren't made on a whim. It is recommended that you investigate > why a change was made before objecting to it. > > When a commit message in isolation appears to be missing context then > that context can normally be found on the dev@ list. The 24 hours of > dev@ traffic leading up to this commit should provide all the necessary > background. There aren't any. I see the commit mail in Thunderbird, but no discussion on the change: Message-Id: <20181003111609.0b0143a0...@svn01-us-west.apache.org> So, what now? >>> >>> The context is there on the dev@ list in the 24 hours leading up to that >>> commit. >> >> Sorry, I seem to be blind. Can you point me to the discussion? I can't >> find anything in my tomcat-dev folder. > >I think Mark refers to this one: > >https://marc.info/?l=tomcat-dev=153856675022101=2 > >Regards, > >Rainer Dear Rainer, Thank you for scanning the mail archive! This states that getCanonicalPath() was used because -- instead of getPath() -- is case insensitive (on Windows!). And the change was made to fix typo problems in a testcase (http://svn.apache.org/viewvc?rev=1842657=rev ) Well - using getCanonicalPath() might solve a typo case issue, but unfortunately this introduce another semantic. Guido
[OT?] RE: Tomcat 8.5.13 - random issue with HTTPS (blank page) - working good with HTTP
Hi Youness Please see my comments below -Original Message- From: youness.dakk...@bnpparibasfortis.com Sent: Wednesday, March 6, 2019 7:55 AM To: Tomcat Users List Subject: RE: Tomcat 8.5.13 - random issue with HTTPS (blank page) - working good with HTTP > This is the content of the log4j.properties file: > > # Root logger > # console will log to console (local tomcat) or stdout.log im Tomcat/logs > log4j.rootLogger=ALL, console > > # Console appender. > log4j.appender.console=org.apache.log4j.ConsoleAppender > log4j.appender.console.layout=org.apache.log4j.PatternLayout > log4j.appender.console.layout.ConversionPattern=%d [%t] %-5p %c - %m%n > > # File appender. > log4j.appender.file=org.apache.log4j.RollingFileAppender > log4j.appender.file.File=PsClient.log > log4j.appender.file.layout=org.apache.log4j.PatternLayout > log4j.appender.file.layout.ConversionPattern=%d [%t] %-5p %c - %m%n > > # Leave an empty line at the end of the file for unix. We use Log4j2 in our project too. While your configuration is specified "log4j.properties", and ours in "log4j2.xml", I wonder if they are similar enough for comparison. I see that you define 2 appenders but no logger. The appenders define what Log4j2 resources are available, but did you tell it which appender to actually use - the logger? We also define both console and file appenders and enable/disable as required with the logger. As an analogy, you could compare defining Log4j2 resources with getting ready to paint. Each resource could be likened to a paint brush. The color and finish of the paint would be the layout and pattern. Maybe you defined a thick brush with blue matte paint as your console appender, and a thin brush with red gloss paint for the file appender. The logger keyword specifies which brush is in your hand. So without using the logger keyword, neither paint brush has been placed into the hand for actual use. The paint brushes (appenders) are just sitting there unused. Does that make sense? I wonder is some of the confusion with Log4j2 is the word "logger" - a generic term versus a keyword. Anyway, please note that I am not an expert in Log4j2, so all this could be complete BS. :-P HTH -- Cris Berneburg CACI Lead Software Engineer > -Original Message- > From: John Dale [mailto:jcdw...@gmail.com] > Sent: Wednesday, March 06, 2019 1:44 PM > To: Tomcat Users List > Subject: Re: Tomcat 8.5.13 - random issue with HTTPS (blank page) - working > good with HTTP > > Check your log4j configuration .. make sure it's got a console appender > configured (based on the log file names, it would seem like a console logger > will be required). If you can, try to post up your log4j configuration .. > there will be key classes for logging within tomcat that must be enabled. > > On 3/6/19, youness.dakk...@bnpparibasfortis.com > wrote: > > Those are the files on tomcat/logs/* > > > > - commons-daemon.-MM-DD.log > > - tomcat.gc.log > > - stdout.log > > - stderr.log > > > > This Tomcat is used inside SAP Business Objects. > > My questions are: > > - How we can get better logs on Tomcat ? > > - Do you already had that kind of behaviour --> From HTPPS you get a > > blank page and via HTTP it works, this is when I use the url of > > BIlaunchPad from SAP Business Objects > > - Is there a tool I can use to have better logging of Tomcat ? or how > > to set the tomcat config to get more usefull logs > > > > Thanks in advance, > > Youness [SNIP] - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Followup2: Changed behaviour of Tomcat Deployment/Context/Lifecycle Manager concerning symbolic links
Am 11.03.2019 um 08:09 schrieb Michael Osipov: Am 2019-03-10 um 22:29 schrieb Mark Thomas: On 10/03/2019 20:54, Michael Osipov wrote: Am 2019-03-10 um 12:16 schrieb Mark Thomas: On 10/03/2019 09:08, Guido Jäkel wrote: Dear John, Hi Rainer, Thank you for your hints. I leaned to used this features on Github locate the commit - it's https://github.com/apache/tomcat/commit/fd2abbb525660a9968694afd99a58f8c22cb54c6 and it was committed by Mark Thomas. I don't know about the Tomcat project policies, but IMHO in the commit comment there was not any real hit for the motivation for the change or any reference to an issue ticket or a pull request. There's just one sentence for the changelog: Ensure that a canonical path is always used for the docBase of a Context to ensure consistent behaviour. (markt) But I can't get any idea from that what the author (Mark?) want to say with the terms "ensure" and "consistent". And it's classified as a "fix", but up to now I was not able to find the use case that is said to be fixed with this. From my point of view, the change lead to something what might be termed with "inconsistent", because now the link name is used as docBase, but the link destination is used to decide concrete aspects of Context loading. @Rainer: I familiarize me with the blame/history feature and have located the commit with this. But now, please tell me how to object against this change? Should I prepare a Git pull request against the master repository? Should I open an Issue somewhere? And how to locate the discussion that lead to this change? This should be tied to prevent flapping and respect and arrange with the motivation there. Changes aren't made on a whim. It is recommended that you investigate why a change was made before objecting to it. When a commit message in isolation appears to be missing context then that context can normally be found on the dev@ list. The 24 hours of dev@ traffic leading up to this commit should provide all the necessary background. There aren't any. I see the commit mail in Thunderbird, but no discussion on the change: Message-Id: <20181003111609.0b0143a0...@svn01-us-west.apache.org> So, what now? The context is there on the dev@ list in the 24 hours leading up to that commit. Sorry, I seem to be blind. Can you point me to the discussion? I can't find anything in my tomcat-dev folder. I think Mark refers to this one: https://marc.info/?l=tomcat-dev=153856675022101=2 Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Followup2: Changed behaviour of Tomcat Deployment/Context/Lifecycle Manager concerning symbolic links
Am 2019-03-10 um 22:29 schrieb Mark Thomas: On 10/03/2019 20:54, Michael Osipov wrote: Am 2019-03-10 um 12:16 schrieb Mark Thomas: On 10/03/2019 09:08, Guido Jäkel wrote: Dear John, Hi Rainer, Thank you for your hints. I leaned to used this features on Github locate the commit - it's https://github.com/apache/tomcat/commit/fd2abbb525660a9968694afd99a58f8c22cb54c6 and it was committed by Mark Thomas. I don't know about the Tomcat project policies, but IMHO in the commit comment there was not any real hit for the motivation for the change or any reference to an issue ticket or a pull request. There's just one sentence for the changelog: Ensure that a canonical path is always used for the docBase of a Context to ensure consistent behaviour. (markt) But I can't get any idea from that what the author (Mark?) want to say with the terms "ensure" and "consistent". And it's classified as a "fix", but up to now I was not able to find the use case that is said to be fixed with this. From my point of view, the change lead to something what might be termed with "inconsistent", because now the link name is used as docBase, but the link destination is used to decide concrete aspects of Context loading. @Rainer: I familiarize me with the blame/history feature and have located the commit with this. But now, please tell me how to object against this change? Should I prepare a Git pull request against the master repository? Should I open an Issue somewhere? And how to locate the discussion that lead to this change? This should be tied to prevent flapping and respect and arrange with the motivation there. Changes aren't made on a whim. It is recommended that you investigate why a change was made before objecting to it. When a commit message in isolation appears to be missing context then that context can normally be found on the dev@ list. The 24 hours of dev@ traffic leading up to this commit should provide all the necessary background. There aren't any. I see the commit mail in Thunderbird, but no discussion on the change: Message-Id: <20181003111609.0b0143a0...@svn01-us-west.apache.org> So, what now? The context is there on the dev@ list in the 24 hours leading up to that commit. Sorry, I seem to be blind. Can you point me to the discussion? I can't find anything in my tomcat-dev folder. Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
