My app is deployed on Tomcat and I've configured the JAVA_OPTS environment variable in /etc/default/tomcat7.
There seem to be a million different places where these variables can be provided to Tomcat, so I want to check that the values I'm providing are what's actually being used. Is there something I can inspect at runtime to determine the value of this variable. I checked System.getProperties(), but it doesn't seem to be there.
If you're looking for just the property overrides and JVM arguments, you can use RuntimeMXBean:
RuntimeMXBean mxBean = ManagementFactory.getRuntimeMXBean();
System.out.println(mxBean.getInputArguments());
For example, running with the following command-line:
java -Xms512m -Xmx1024m -Dtest.prop=foo com.example.sandbox.RuntimeMXBeanExample
I get the following output:
[-Xms512m, -Xmx1024m, -Dtest.prop=foo]
Note that this does not include arguments passed to the main() method.
You can use System.getenv("JAVA_OPTS") as suggested.
If you don't want to modify code than you can use some of those methods
Java Tools
jps -v displays Java processes with arguments
jvisualvm connects to Java process and let's you inspect number of properties including MXBeans
GNU/Linux tools
ps e displays environment variables passed to processes
One important thing, although post is old. Whatever variable you are passing it should be before the class name you are executing else it will be ignored.
Below will work:
Example: java -classpath . -Dformat=xls -DTabname=\"Base data new\" com.cg.bench.GenerateReport
Below will NOT work:
WRONG Example: java -classpath . com.cg.bench.GenerateReport -Dformat=xls -DTabname=\"Base data new\"
Related
Why do we need to prefix JVM arguments with -D e.g. when running a jar from the command line? E.g.
java -jar -DmyProp="Hello World" myProgram.jar
is used to run myProgram.jar with the system parameter myProp. So why the leading -D? Why couldn't the architects of Java let us simply do:
java -jar -myProp="Hello World" myProgram.jar
I'm hoping for an answer beyond just "Because that's the way it is".
Bonus Question: Why the letter -D as opposed to any other letter, does it stand for anything?
Note: This question asks why there was a need to use "D", or any other letter for that matter, in the first place. It is less concerned with the choice of specific letter "D" over any other letter, though that is asked as a bonus question.
The bonus question has an answer here: In java -D what does the D stand for?.
Why couldn't the architects of Java let us simply do:
java -jar -myProp="Hello World" myProgram.jar
It could work today but suppose that in next Java versions a -myProp argument is introduced as a JVM option.
How to distinguish your -myProp from the -myProp JVM option ? No way.
So it exists an obvious reason to use -D to define system properties.
As other example, instead of -myProp suppose you program relies on a -client system property.
It will not run :
java -jar -client="davidxxx" myProgram.jar
You would have a JVM error such as :
Unrecognized option: -client=davidxxx
as -client is a JVM standard option that expects no value.
But if you use -D-client, it is now fine as here -Dclient is defined as a system property that is distinct from the -client standard JVM option :
java -jar -D-client="davidxxx" myProgram.jar
Or by using both :
java -jar -client -D-client="davidxxx" myProgram.jar
To go further, not all JVM arguments start with -D. but most of them have a prefix (-D, -X, -XX) that allows in a someway to define namespaces.
You have distinct categories of JVM arguments :
1. Standard Options (-D but not only).
These are the most commonly used options that are supported by all implementations of the JVM.
You use -D to specify System properties but most of them don't have any prefix :-verbose, -showversion, and so for...
2. Non-Standard Options (prefixed with -X)
These options are general purpose options that are specific to the Java HotSpot Virtual Machine.
For example : -Xmssize, -Xmxsize
3. Advanced Runtime Options (prefixed with -XX)
These options control the runtime behavior of the Java HotSpot VM.
4. Advanced JIT Compiler Options (prefixed with -XX)
These options control the dynamic just-in-time (JIT) compilation performed by the Java HotSpot VM.
5. Advanced Serviceability Options (prefixed with -XX)
These options provide the ability to gather system information and perform extensive debugging.
6. Advanced Garbage Collection Options (prefixed with -XX)
These options control how garbage collection (GC) is performed by the Java HotSpot VM.
"Define". The meaning is similar to a preprocessor definition in C. The -D signifies that the definition is in the context of the application, and not in the Java interpreter context like any other option before the executable name.
The usage of the letter "D" isn't specifically explained in the documentation, but the only use is to "define" a key in the system properties map - except for this reference:
The System class maintains a Properties object that defines the configuration of the current working environment. For more about these properties, see System Properties. The remainder of this section explains how to use properties to manage application configuration.
If you do not specify anything like -myProp="XYZ" it means it is passed as an argument to main method of the program.
-D means you can use this value using System.getProperty
-X is used for extension arguments like -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000
Yes, they could have interchanged.. the characters; but these characters are used to specify what type of parameter is passed and who is the consumer.
Without the -D the properties would conflict with normal JVM options. For example how would you set the property jar?
The -D was probably chosen (I can only speculate about that) because it is also used in the C preprocessor to define symbols and was therefore familiar to most people.
From Java, is it possible to get the complete commandline with all arguments that started the application?
System.getEnv() and System.getProperties() do not appear to contain the values.
Some of it is available from the RuntimeMXBean, obtained by calling ManagementFactory.getRuntimeMXBean()
You can then, for example call getInputArguments()
The javadocs for which say:
Returns the input arguments passed to the Java virtual machine which does not include the arguments to the main method. This method returns an empty list if there is no input argument to the Java virtual machine.
Some Java virtual machine implementations may take input arguments from multiple different sources: for examples, arguments passed from the application that launches the Java virtual machine such as the 'java' command, environment variables, configuration files, etc.
Typically, not all command-line options to the 'java' command are passed to the Java virtual machine. Thus, the returned input arguments may not include all command-line options.
In Linux that should be possible when you get the output of that command (run in a shell)
cat /proc/$PPID/cmdline
But that is not portable at all and should therefore not be used in Java...
The following links may help you get there:
How to get command line arguments for a running process
get command-line of running processes
How to get a list of current open windows/process with Java?
Just as a note:
In Windows you have Process Explorer by Sysinternals that shows you the command line used to open the process. Right click the process and select Properties... You'll see Command Line in the window that is opened.
You might want to look into how jps does this. It's a Java program that is able to get the full command line for all Java processes, including full class name of main class and JVM options.
There is a environment variable %~dp0 which returns the complete path
Have a look at YAJSW (Yet Another Java Service Wrapper) - it has JNA-based implementations for various OSes (including win32 and linux) that do exactly this so it can grab the commandline for a running process and create a config that wraps it in a service. A bit more info here.
Since Java 9 you may use ProcessHandle to get the command line of the process:
ProcessHandle.current().info().commandLine()
One option I've used in the past to maintain the cross-platform-shine is to set the command line as an environment variable prior to issuing the command.
If you are using solaris as the OS, take a look at "pargs" utility. Prints all the info required.
I'm running in an environment where I can pass parameters but not set environment variables using a normal commandline.
I would like to set environment variables nevertheless. Is there an alternative way to "fool" java that an environment variable is set, e.g. using -D parameters?
(I'm running spark in oozie through hue; all in the Cloudera stack).
The java command itself doesn't seem to allow that. It has a -D parameter, but that sets Java 'system properties':
$ java -help 2>&1 | grep -A1 '\-D'
-D<name>=<value>
set a system property
Java system properties are a sort of Java properties. Like environment variables, java properties are key-value pairs, but aren't the same thing as environment variables: If your Java application reacts to a specific environment variable, setting a system property of the same name won't have any effect unless the application explicitly reacts to that property, too.
If your environment allows you to run arbitrary Java applications and if it allows your Java applications to execute other processes, you can write a little wrapper that sets the environment variables on a ProcessBuilder (see the question Arnon linked in his comment: How do I set environment variables from Java?) to then invoke java with your actual JAR from it. You could either hard-code the environment variables to set, or set them according to system properties the wrapper receives. (Or you could even implement your own shell in Java and pass a script to it.)
Though, if you can modify the source of that actual JAR, a much more idiomatic solution would be to make it itself react to properties instead of (or additionally to) environment variables. (Unless you have to control environment variables that the java command / the JVM reacts to rather than the JAR you'd like to run. Then this approach would not be applicable, of course.)
If you can run arbitrary Java code, you can create and run a Process using ProcessBuilder, including an environment of your choice.
Hence, write a java program that parses a command-line like
java -cp .... your.Prog FOO=BAR BAZ=BOOM command arguments ...
and starts command with the environment extended by FOO and BAZ
(Note that command could be java ...)
From Java, is it possible to get the complete commandline with all arguments that started the application?
System.getEnv() and System.getProperties() do not appear to contain the values.
Some of it is available from the RuntimeMXBean, obtained by calling ManagementFactory.getRuntimeMXBean()
You can then, for example call getInputArguments()
The javadocs for which say:
Returns the input arguments passed to the Java virtual machine which does not include the arguments to the main method. This method returns an empty list if there is no input argument to the Java virtual machine.
Some Java virtual machine implementations may take input arguments from multiple different sources: for examples, arguments passed from the application that launches the Java virtual machine such as the 'java' command, environment variables, configuration files, etc.
Typically, not all command-line options to the 'java' command are passed to the Java virtual machine. Thus, the returned input arguments may not include all command-line options.
In Linux that should be possible when you get the output of that command (run in a shell)
cat /proc/$PPID/cmdline
But that is not portable at all and should therefore not be used in Java...
The following links may help you get there:
How to get command line arguments for a running process
get command-line of running processes
How to get a list of current open windows/process with Java?
Just as a note:
In Windows you have Process Explorer by Sysinternals that shows you the command line used to open the process. Right click the process and select Properties... You'll see Command Line in the window that is opened.
You might want to look into how jps does this. It's a Java program that is able to get the full command line for all Java processes, including full class name of main class and JVM options.
There is a environment variable %~dp0 which returns the complete path
Have a look at YAJSW (Yet Another Java Service Wrapper) - it has JNA-based implementations for various OSes (including win32 and linux) that do exactly this so it can grab the commandline for a running process and create a config that wraps it in a service. A bit more info here.
Since Java 9 you may use ProcessHandle to get the command line of the process:
ProcessHandle.current().info().commandLine()
One option I've used in the past to maintain the cross-platform-shine is to set the command line as an environment variable prior to issuing the command.
If you are using solaris as the OS, take a look at "pargs" utility. Prints all the info required.
In a shell script, I have set the JAVA_OPTS environment variable (to enable remote debugging and increase memory), and then I execute the jar file as follows:
export JAVA_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,address=8001,server=y,suspend=n -Xms512m -Xmx512m"
java -jar analyse.jar $*
But it seems there is no effect of the JAVA_OPTS env variable as I cannot connect to remote-debugging and I see no change in memory for the JVM.
What could be the problem?
PS: I cannot use those settings in the java -jar analyse.jar $* command because I process command line arguments in the application.
You can setup _JAVA_OPTIONS instead of JAVA_OPTS. This should work without $_JAVA_OPTIONS.
I don't know of any JVM that actually checks the JAVA_OPTS environment variable. Usually this is used in scripts which launch the JVM and they usually just add it to the java command-line.
The key thing to understand here is that arguments to java that come before the -jar analyse.jar bit will only affect the JVM and won't be passed along to your program. So, modifying the java line in your script to:
java $JAVA_OPTS -jar analyse.jar $*
Should "just work".
In the past 12 years some changes were made.
Environment variable JAVA_OPTS was and is NOT a standardized option. It is evaluated by some shell script wrappers for Java based tools, an example of how this works is in the answer from ZoogieZork.
The environment variable _JAVA_OPTIONS mentioned by HEX is nowadays deprecated/undocumented.
Starting with Java 9, the recommended way to do what you wanted is the variable JDK_JAVA_OPTIONS, see Using the JDK_JAVA_OPTIONS Launcher Environment Variable in the Oracle Java 9 documentation, and this comprehensive answer What is the difference between JDK_JAVA_OPTIONS and JAVA_TOOL_OPTIONS when using Java 11?.