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
