tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Arch (sarch)" <>
Subject RE: Different handling of -Dfoo="bar" between versions
Date Thu, 03 Oct 2013 15:45:18 GMT
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.


-----Original Message-----
From: Christopher Schultz [] 
Sent: Thursday, October 03, 2013 4:25 PM
To: Tomcat Users List
Subject: Re: Different handling of -Dfoo="bar" between versions


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.util.logging.config.file=/usr/share/tomcat7/conf/logging.proper
> ties
> 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.

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

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

View raw message