Re: Different handling of -Dfoo=bar between versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 10/3/13 4:03 PM, André Warnier wrote: I think that the basic misunderstanding here is simply this : The executable program that is being launched by the above command-line is not Tomcat. It is /usr/lib/jvm/jre/bin/java. All the rest of the command-line options and parameters are options and parameters for /usr/lib/jvm/jre/bin/java, and are parsed by /usr/lib/jvm/jre/bin/java. Including the -Dfoo=bar. Yes and no. That foolishness with quoting, etc. only happens with old DOS programs. On UNIX (since forever, I think), the shell parses the command-line and tokenizes everything. The argv vector contains exactly what the parent process provided... nothing more, nothing less. Those quotes appear in the argument vector therefore they are part of the parameter. The parameter -Dfoo=bar (or -Dfoo=bar) itself is in fact parsed by the JVM process, but trivially: if it looks like -Dsomething, then set the system property something to whatever the value is after the = sign. You don't even need an equals sign, and it will work (I'm actually not sure what value you get ... maybe empty string?). If the quotes are there in the argv vector, they will be there in the system property's value. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSTsrGAAoJEBzwKT+lPKRYAsAP/ihT1sBnaMG0gSGk4Ln1D3oG J2WEc4qI6tCsxfmzq5VdAe99aK3lyLwa0bXLDHjoOnp4h5/GDPjn6Lt7nygtEqfG 4wvmG7ZJhinrniK3HkbacIfHayRBF92k0ChkUAAkm49yKt1263hsSeEZKfApO3Ds KavZE0zGqGWdnnq0BVXi21lAhbbKfldp+17XO4CHYEQcRhrSdnlgsNIUid7xGWPq u0ubi4UAYsv48ufYHO4p/r0uLSm5/KR7BgfIBJBWOiB7mW1q98Y8zDLkpXeh5oA7 d70N2LXplOm9egMe76bwww9aJgjb4/4A308Lnjn/oFKPT0HqfDXTpkmDAZs/4Dhy OsthAtry3nKPdr/OH9qzk6AF8hwYinmROZLN3GlGPBTsNUqBtTwej1HuTsBgHkls EsJtX9EQ2DVDGQErShH93yjJkb/Scc1VbzV/Zm+gZs+8bMFJrcorJecoE6ueV0ba CtM2TZn0wM/OmdXreqkw+LJZTJxrrOxgIqucw3kwbLSdccCj9u45wj/T/TvdhTyt 5Y8H5O1Bv4mDP2WmqkPRRQJwBTSpCSVnNLxL2o6vDpuSZy0Q4IbLcqeTNPhLiL/r 6Synn8tRC3RpgFkVpLX0SNlQ7mbaA63opIMX8TMLzqNXjJch/F/N+NNAttBAXjuP E63xKpBSnc8YWr1mZT0q =cysF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Different handling of -Dfoo=bar between versions
I've noticed the following disparity between using two different versions of Tomcat when setting system properties using -D. If I pass in -Dfoo=bar into Tomcat, and then look up the value of the 'foo' system property, I get different results depending on which version of Tomcat I use. Tomcat 7.0.37: System.getProperty(foo) returns bar (with quotes) Tomcat 7.0.27: System.getProperty(foo) returns bar (without quotes) What is the 'correct' behaviour of this and should a bug be raised? For reference, I'm doing this on AWS Elasticbeanstalk, so it's using 64-bit architecture and AWS's default distribution (which uses yum repositories though I don't know exactly which distro it is based on). AWS sets the parameters automatically form me via a nice web UI so I can't just pass in -Dfoo=bar as that is hidden from me.
Re: Different handling of -Dfoo=bar between versions
On 03.10.2013 16:21, Steve Arch (sarch) wrote: If I pass in -Dfoo=bar into Tomcat, and then look up the value of I believe, that one has to use quotes in command line parameters to surround whole parameter, not only its part. Thus following are correct: -Dfoo=bar -Dfoo=bar bar while these are not: -Dfoo=bar bar Its shell's job to parse quotes, wildcards, etc. You have to verify quotes/parameters handling on bare tomcat instance. Otherwise, you should raise a bug to maintainers of third party tool you use to manage tomcat with. -- Mikolaj Rydzewski m...@ceti.pl - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Different handling of -Dfoo=bar between versions
OK, thanks. Bug has been raised with AWS: https://forums.aws.amazon.com/message.jspa?messageID=492286#492286 -Original Message- From: Mikolaj Rydzewski [mailto:m...@ceti.pl] Sent: Thursday, October 03, 2013 3:29 PM To: Tomcat Users List Subject: Re: Different handling of -Dfoo=bar between versions On 03.10.2013 16:21, Steve Arch (sarch) wrote: If I pass in -Dfoo=bar into Tomcat, and then look up the value of I believe, that one has to use quotes in command line parameters to surround whole parameter, not only its part. Thus following are correct: -Dfoo=bar -Dfoo=bar bar while these are not: -Dfoo=bar bar Its shell's job to parse quotes, wildcards, etc. You have to verify quotes/parameters handling on bare tomcat instance. Otherwise, you should raise a bug to maintainers of third party tool you use to manage tomcat with. -- Mikolaj Rydzewski m...@ceti.pl - 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
RE: Different handling of -Dfoo=bar between versions
From: Steve Arch (sarch) [mailto:sa...@cisco.com] Subject: Different handling of -Dfoo=bar between versions I've noticed the following disparity between using two different versions of Tomcat when setting system properties using -D. On the face of it, this is not related to Tomcat. If I pass in -Dfoo=bar into Tomcat Exactly how are you passing this to Tomcat? System.getProperty(foo) The System class is part of the JRE, not Tomcat - Tomcat itself has absolutely nothing to do with retrieval of system properties. Whatever mechanism you're using to create the system property may have changed (e.g., different versions of the JRE or the JSVC/procrun wrapper). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Different handling of -Dfoo=bar between versions
AWS's tools pass the values to tomcat. I supply a set of key:value pairs and AWS (ElasticBeanstalk) passes them to tomcat via the command line. I can find out how they are set with ps and it shows that they are getting passed as: -Dfoo=bar The System.getProperty call was just to demonstrate how I can retrieve them. Something has changed between version 24 and 37 in Tomcat when it parses the JVM options (-D). Mikolaj's response says that the input was illegal anyway (quotes have to surround the whole string: -Dfoo=bar or -Dfoo=bar bar rather than -Dfoo=bar bar). As long as I know that -Dfoo=bar is illegal syntax for passing options into the JVM/tomcat then I can contact AWS and raise a bug with them. I just assumed it was something to do with tomcat as that was the only thing that had changed. -Original Message- From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com] Sent: Thursday, October 03, 2013 3:44 PM To: Tomcat Users List Subject: RE: Different handling of -Dfoo=bar between versions From: Steve Arch (sarch) [mailto:sa...@cisco.com] Subject: Different handling of -Dfoo=bar between versions I've noticed the following disparity between using two different versions of Tomcat when setting system properties using -D. On the face of it, this is not related to Tomcat. If I pass in -Dfoo=bar into Tomcat Exactly how are you passing this to Tomcat? System.getProperty(foo) The System class is part of the JRE, not Tomcat - Tomcat itself has absolutely nothing to do with retrieval of system properties. Whatever mechanism you're using to create the system property may have changed (e.g., different versions of the JRE or the JSVC/procrun wrapper). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - 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
RE: Different handling of -Dfoo=bar between versions
From: Steve Arch (sarch) [mailto:sa...@cisco.com] Subject: RE: Different handling of -Dfoo=bar between versions AWS's tools pass the values to tomcat. This is not an adequate description. Tomcat must be launched by some mechanism, such as the java executable, JSVC service wrapper, class loading from some already running Java application, etc. What's being used here? I supply a set of key:value pairs and AWS (ElasticBeanstalk) passes them to tomcat via the command line. Exactly what command line? Tomcat itself is just a set of class files, not an executable. Something has changed between version 24 and 37 in Tomcat when it parses the JVM options (-D). Again, Tomcat does not parse command line options and has absolutely nothing to do with the JRE-supplied System class. The launcher used to start Tomcat does parse the command line; Tomcat has no built-in launcher. Mikolaj's response says that the input was illegal anyway (quotes have to surround the whole string: -Dfoo=bar or -Dfoo=bar bar rather than -Dfoo=bar bar). As long as I know that -Dfoo=bar is illegal syntax It's not illegal (and Mikolaj never said it was), but it may not be what you want. When quotes come after the equals sign, they are part of the value; quotes surrounding the entire expression are stripped off by the shell when creating the argument list for the executable. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Different handling of -Dfoo=bar between versions
AWS's tools pass the values to tomcat. This is not an adequate description. Tomcat must be launched by some mechanism, such as the java executable, JSVC service wrapper, class loading from some already running Java application, etc. What's being used here? OK, in this case 'magic' is being used. The running process is: /usr/lib/jvm/jre/bin/java -Dfoo=bar -XX:MaxPermSize=64m -Xmx256m -Xms256m -classpath /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat7 -Dcatalina.home=/usr/share/tomcat7 -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat7/temp -Djava.util.logging.config.file=/usr/share/tomcat7/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start I supply a set of key:value pairs and AWS (ElasticBeanstalk) passes them to tomcat via the command line. Exactly what command line? Tomcat itself is just a set of class files, not an executable. Tomcat is launched by some magic which may as well boil down to launching from the command line: /usr/lib/jvm/jre/bin/java -Dfoo=bar -XX:MaxPermSize=64m -Xmx256m -Xms256m -classpath /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat7 -Dcatalina.home=/usr/share/tomcat7 -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat7/temp -Djava.util.logging.config.file=/usr/share/tomcat7/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start Something has changed between version 24 and 37 in Tomcat when it parses the JVM options (-D). Again, Tomcat does not parse command line options and has absolutely nothing to do with the JRE-supplied System class. The launcher used to start Tomcat does parse the command line; Tomcat has no built-in launcher. Whatever parses the command line has not changed between versions of tomcat. At some stage, part or all of -Dfoo=bar makes its way through to Tomcat. On tomcat 7.0.24, this results in the environment parameter 'foo' being set to 'bar'. On Tomcat 7.0.37, this results in the environment parameter 'foo' being set to 'bar'. Mikolaj's response says that the input was illegal anyway (quotes have to surround the whole string: -Dfoo=bar or -Dfoo=bar bar rather than -Dfoo=bar bar). As long as I know that -Dfoo=bar is illegal syntax It's not illegal (and Mikolaj never said it was), but it may not be what you want. When quotes come after the equals sign, they are part of the value; quotes surrounding the entire expression are stripped off by the shell when creating the argument list for the executable. Maybe should have said 'wrong' rather than 'illegal' but if the correct behaviour of -Dfoo=bar is for the system parameter 'foo' to be set to 'bar' (with the quotes) then I can raise a bug with AWS. If the correct behaviour of is for 'foo' to be set to 'bar' (without the quotes) then I'll raise a bug with Tomcat. TBH I don't care which is 'correct' as long as I know which one is and can chase up the bug with someone. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Different handling of -Dfoo=bar between versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Steve, On 10/3/13 11:12 AM, Steve Arch (sarch) wrote: AWS's tools pass the values to tomcat. This is not an adequate description. Tomcat must be launched by some mechanism, such as the java executable, JSVC service wrapper, class loading from some already running Java application, etc. What's being used here? OK, in this case 'magic' is being used. The running process is: /usr/lib/jvm/jre/bin/java -Dfoo=bar -XX:MaxPermSize=64m -Xmx256m -Xms256m -classpath /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar - -Dcatalina.base=/usr/share/tomcat7 -Dcatalina.home=/usr/share/tomcat7 -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat7/temp -Djava.util.logging.config.file=/usr/share/tomcat7/conf/logging.properties - -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start It's clear that Tomcat's bundled startup scripts are not in use, here. Id so, there would be a -Dnop on the command line that is a hack to prevent a broken command-line when no logging configuration has been specified (which is the case above). I don't have enough experience with jsvc to know what the command-line looks like when its in use... you can easily check for the parent process for the JVM and see if it's something like jsvc -- though it could have been re-renamed by Amazon. Something has changed between version 24 and 37 in Tomcat when it parses the JVM options (-D). Again, Tomcat does not parse command line options and has absolutely nothing to do with the JRE-supplied System class. The launcher used to start Tomcat does parse the command line; Tomcat has no built-in launcher. Whatever parses the command line has not changed between versions of tomcat. At some stage, part or all of -Dfoo=bar makes its way through to Tomcat. On tomcat 7.0.24, this results in the environment parameter 'foo' being set to 'bar'. On Tomcat 7.0.37, this results in the environment parameter 'foo' being set to 'bar'. Given that it's not Tomcat scripts, it's unlikely to have been affected directly by the upgrade in Tomcat version. Instead, you are probably seeing some environmental change that you may otherwise be unaware of: Amazon changed something, and it happened at the same time the Tomcat upgrade occurred. I think logging a bug with Amazon was appropriate. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSTYw1AAoJEBzwKT+lPKRYPjwQAMZqZDwsAaPDfhjOwfmtMkVY 6ZJh1ouw/5Jv/w9Ir8SXkw2+n2a+ML25+yDW/K9SQ4lq6N0Q17WAIX0tXH/tmYPn GCYRdnH9pUeLTtfhNPwPzCqcCvSaiofjQtI+Eqiz7/Q2hYSFm5j08D2XR+2sHJJJ DGNzD070VQk4skWu8iL1rnfoWdazuKu/UviqUz3iWkPnMDQDUgtt92sK9P+sVaCf bB1sRD9QAPYeW9+fnd48puA7Dtyo9UKrpln4iRGol0pfPUHHYRbo/ESULlu7D5hA Uvc05fr2Hm9evgkwgHPrA4ALqxdjbwNvrtBkHhPoUhPQieQhUtr5LJJRHtjS06ZJ YnwKDgZ2e/CYzzHeHuGfT3/j2S2Ml2C9ZC4Ho68JwzvomVfwPSRF+qXILtExpN+J e9t+ds7MGKTNXWLjfvB9FKZfYhN/SHeH1/tvmMj/H6CY34aVrN0OwPeHRmzH6D+o SkenwBEWvAv6ceH+eX3B25b99KcG0xel2t3Ch1g7OqYE4SnhFpweivNQwJfOwjjm 6LGIM2EjvU720aiNFe4QjL36m1Wosxijecq9qZQwQTIMX9rJOyjjhRITzEYwlfbQ C4yrYjpwMXA+IRUBA+r0or+g3azMzApbFjANpoHzsPk9Z657cLsiNOXGwCS4aFCt iAFfkmEbfrZ5iPRu0RzS =qolt -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Different handling of -Dfoo=bar between versions
I've found a bit more explanation. You are indeed correct - AWS has their own custom tomcat startup scripts that override the default tomcat startup scripts to handle the quotes. The yum update reverts to the default tomcat scripts and introduces the ambiguity. Thanks for the help. Steve -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, October 03, 2013 4:25 PM To: Tomcat Users List Subject: Re: Different handling of -Dfoo=bar between versions Steve, On 10/3/13 11:12 AM, Steve Arch (sarch) wrote: AWS's tools pass the values to tomcat. This is not an adequate description. Tomcat must be launched by some mechanism, such as the java executable, JSVC service wrapper, class loading from some already running Java application, etc. What's being used here? OK, in this case 'magic' is being used. The running process is: /usr/lib/jvm/jre/bin/java -Dfoo=bar -XX:MaxPermSize=64m -Xmx256m -Xms256m -classpath /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-jul i.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat7 -Dcatalina.home=/usr/share/tomcat7 -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat7/temp -Djava.util.logging.config.file=/usr/share/tomcat7/conf/logging.proper ties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start It's clear that Tomcat's bundled startup scripts are not in use, here. Id so, there would be a -Dnop on the command line that is a hack to prevent a broken command-line when no logging configuration has been specified (which is the case above). I don't have enough experience with jsvc to know what the command-line looks like when its in use... you can easily check for the parent process for the JVM and see if it's something like jsvc -- though it could have been re-renamed by Amazon. Something has changed between version 24 and 37 in Tomcat when it parses the JVM options (-D). Again, Tomcat does not parse command line options and has absolutely nothing to do with the JRE-supplied System class. The launcher used to start Tomcat does parse the command line; Tomcat has no built-in launcher. Whatever parses the command line has not changed between versions of tomcat. At some stage, part or all of -Dfoo=bar makes its way through to Tomcat. On tomcat 7.0.24, this results in the environment parameter 'foo' being set to 'bar'. On Tomcat 7.0.37, this results in the environment parameter 'foo' being set to 'bar'. Given that it's not Tomcat scripts, it's unlikely to have been affected directly by the upgrade in Tomcat version. Instead, you are probably seeing some environmental change that you may otherwise be unaware of: Amazon changed something, and it happened at the same time the Tomcat upgrade occurred. I think logging a bug with Amazon was appropriate. -chris - 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
Re: Different handling of -Dfoo=bar between versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Steve, (Bringing your reply back on-list.) On 10/3/13 11:40 AM, Steve Arch (sarch) wrote: I trimmed the running process line to strip out our private stuff (like our AWS keys!) and must have snipped out the logging parameters too. As I said, tomcat behaves as designed so the bug with AWS is appropriate, but this happens on all our machines. We can run on version 24 and restart tomcat as many times as we like and the value of the 'foo' parameter in the java code (and returned by our webapp) is 'bar' (no quotes). We upgrade tomcat to 7.0.37 via yum and restart tomcat and it immediately returns 'foo'. Tomcat is the only thing that's changed here - nothing else has. It could be a problem with the package-managed version of Tomcat. Requesting the apache-tomcat-7.0.37 package from AWS's repository doesn't mean that you are getting only ASF code, scripts, etc. It is certainly a possibility that their package is broken in some way. You said that you use Elastic Beanstalk... I've never used it but my understanding was that you deploy your WAR file and you have no access to the machines actually running the webapp. Am I misinformed? I'm wondering why -- if you are using Beanstalk -- you are even managing your own Tomcat package? IT's not a problem with Tomcat, but saying that it's a change in something else is incorrect as Tomcat is the only thing that's changed (but as I said, that change is correct (what I wanted to verify on the mailing list) so the bug is with AWS, not Tomcat). Yep, things work fine for me specifying arbitrary things on the command-line. This problem it likely with whatever components stores your settings and then converts them into command-line parameters... it's probable a part of the tomcat package from Amazon, even though it doesn't really make sense to me that it would be. Good luck, and please reply to the list if/when the problem is resolved... it would be good to have an answer in the list archives. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSTZ3AAAoJEBzwKT+lPKRY46IQALVRC593JdhO/d3wnx8pzcbN KTiEOAgMrhxBPHWqeDdH/Uud8EM1Yac3L/FiAN9Zo8qkASAgh4qi4wWvBfNi9hAW iMfvV0TnncomjZTTilavR2ISUcpUIOtpbz51+QElzKsb6Ia5eYXEmejUP7GDYPR2 Cf4zis19tAHLWpcfgigNN5k2pmh7no5uYCp41s3O3uNc6vx74TjOhoc3e+0bG5p2 50v5bYhbVdBywNSHr4eFrfPoEVfQYNOx+plhMfMu04bo79s6jV7BGSUctzugKDGa WTAxp+BmAG/NqYLCqycfO93kEkq6NKy2EqMwYk3zx373xpPhpqid/wNGe1QqRsnl K8Ezbbl15P1RabSW7ApweCV0ly81Y/fvGse5Vu6XcvDB6Mkkp03eCICGIvWD5fYq ffZAPY9hVpt/E/nPEjvG3qMgZFKZZ4jLr84CXyoVTLb9ecWgIMEDiFjeYP4Rc25A 9e9hwSR179/M9RQ4OmXJy8YN0YNKV2jKkFS5kh5A3tEaxNWJumxmCS9/E6Z7KakV MVgui1vTRMlnSi7m1h7I9o9v6DTQg2ETZ2EGgffUWtTvhtyg41hXyRa+k8oaKjBp uDcZq9crtgXbaslxKh9IHHDqY/cE2m6+9Vic4UYqQTtL1Dfp6YNypgB8xLvcXPoz Z99yzjSsVWtRH9l8qajW =8ghn -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Different handling of -Dfoo=bar between versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Steve, Please post-back to the list instead of individual members of the community. The Tomcat users' list isn't a place to get hooked-up with people who can help you... it's to get help from the community. By replying to me privately you are 1) robbing yourself of the wisdom of other members and b) robbing those other members of your own comments. On 10/3/13 12:42 PM, Steve Arch (sarch) wrote: Your guess was correct. AWS uses a custom launch script that gets configured after tomcat is installed. When an update is installed, it trashes the customisation (renaming the start script in /etc/init.d/tomcat7) and reverts to tomcat's default behaviour. That’s why I (incorrectly) believed that it was a change in the tomcat versions. Full explanation (and fix for EB users at the bottom) here: https://forums.aws.amazon.com/message.jspa?messageID=460080 It looks like the real solution can be found here: https://forums.aws.amazon.com/message.jspa?messageID=418307#460080 - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSTaJ6AAoJEBzwKT+lPKRYnLUP/0l5veT3S/Sx6lMsEw8RqZp8 Oy4KCDjXId5cTl+wVOVjir44rWcTWwCAveNyFiJHI7V+F7dCsR70OCnFYSsiR1GA XGTztiX1ELHEYooqQnzGP4svI+2bVUmRlbOXyDrI+xZWix1PVlGyMYjiXISVSVhZ zZZPgfFnlPso9pyNwyTZqwvoHwwbW+Bu2wdxz1JkeHGE9qF3WXT+uu5q9H6OWqqP tQ10frJFazl2CcaByxCDVppgxxoUhznyusUcTTW2ZIH2WwuX3gO2JyJV7zzjD/N5 MlYGI06NcoYGCg/EMJNjsqRyIGc+7VnnWqOJp2mRQMdwa1MsUnPStia22lwAd9Xu lQpzvAD/rMTrxmh53LkEPMLDvbAi80lNLyiMHmkwyVDqJo9H3l2ixkXdyVYf4Pnq EvemxUTzVHlSUsna+dOaECNLEbjlzapctd0OCbIGfZil8G5F7h3/w41cyMOR7xtR 7fXjRntEBye1eBK8WFEE38qCJ0BLTWPAUWQRqfkbGT4p2leuDgMX6fnDNbah52dO xZ9qtLON22MUyOf32b4nat705F+m7EDeA2Q3lBwzUrjNDi3JSS9ZWcD47WjurO8g XbjtrpfVMTKbcl7syzbeYrjTkSmZZS/XjTp+1rjCjMQyXKHInK0iQ/GXnn/1Dxpm z+I/Rak2vzCOT9DSwmKb =QWbr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Different handling of -Dfoo=bar between versions
I meant to. For some reason when I hit 'reply' it replied to only you rather than the whole mailing list as it had previously done. Apologies. -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, October 03, 2013 6:00 PM To: Steve Arch (sarch); Tomcat Users List Subject: Re: Different handling of -Dfoo=bar between versions Steve, Please post-back to the list instead of individual members of the community. The Tomcat users' list isn't a place to get hooked-up with people who can help you... it's to get help from the community. By replying to me privately you are 1) robbing yourself of the wisdom of other members and b) robbing those other members of your own comments. On 10/3/13 12:42 PM, Steve Arch (sarch) wrote: Your guess was correct. AWS uses a custom launch script that gets configured after tomcat is installed. When an update is installed, it trashes the customisation (renaming the start script in /etc/init.d/tomcat7) and reverts to tomcat's default behaviour. That’s why I (incorrectly) believed that it was a change in the tomcat versions. Full explanation (and fix for EB users at the bottom) here: https://forums.aws.amazon.com/message.jspa?messageID=460080 It looks like the real solution can be found here: https://forums.aws.amazon.com/message.jspa?messageID=418307#460080 -chris
Re: Different handling of -Dfoo=bar between versions
Steve Arch (sarch) wrote: I've found a bit more explanation. You are indeed correct - AWS has their own custom tomcat startup scripts that override the default tomcat startup scripts to handle the quotes. The yum update reverts to the default tomcat scripts and introduces the ambiguity. Thanks for the help. Steve -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, October 03, 2013 4:25 PM To: Tomcat Users List Subject: Re: Different handling of -Dfoo=bar between versions Steve, On 10/3/13 11:12 AM, Steve Arch (sarch) wrote: AWS's tools pass the values to tomcat. This is not an adequate description. Tomcat must be launched by some mechanism, such as the java executable, JSVC service wrapper, class loading from some already running Java application, etc. What's being used here? OK, in this case 'magic' is being used. The running process is: /usr/lib/jvm/jre/bin/java -Dfoo=bar -XX:MaxPermSize=64m -Xmx256m -Xms256m -classpath /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-jul i.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat7 -Dcatalina.home=/usr/share/tomcat7 -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat7/temp -Djava.util.logging.config.file=/usr/share/tomcat7/conf/logging.proper ties ... I think that the basic misunderstanding here is simply this : The executable program that is being launched by the above command-line is not Tomcat. It is /usr/lib/jvm/jre/bin/java. All the rest of the command-line options and parameters are options and parameters for /usr/lib/jvm/jre/bin/java, and are parsed by /usr/lib/jvm/jre/bin/java. Including the -Dfoo=bar. Correction : what you see with the ps display is the command that was used to launch that process, *after* the original command-line was parsed by whatever shell was in use. So if that shell was a Unix shell, the original command-line may have included (as one of the possibilities) '-Dfoo=bar' (or : -Dfoo=\bar\ - and there are a few more esoteric possibilities too). In any case, java reads the -Dfoo=bar, and sets the corresponding internal java system property. And then, later, java runs tomcat. And then, later, some java code in Tomcat asks for the value of the property foo, and gets this value from the JVM that is running it (/usr/lib/jvm/jre/bin/java). And it gets whatever the JVM thinks it is. If the JVM thinks it is bar, then Tomcat gets bar. If the JVM thinks it is bar, then Tomcat will get bar. So it has nothing to do with Tomcat per se or any of its versions. It happens before. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
