intellij run vs debug configuration has different args input paramter
已回答
Same as stackoverflow question: http://stackoverflow.com/questions/35662978/intellij-run-vs-debug-configuration-has-different-args-input-paramter
Intellij 15.0.3
Main class: xxx.project.Boot
VM args: -cp xxx.jar -Dxxx.work.dir=yyy xxx.project.Boot
Program arguments: dump_args
Project Code
public static void main (String[] args) Throwable {
// first line in the Main entry point of the program
for (int i = 0; i < args.length; i++){
System.out.println("args["+i+"] = "+args[i]);
}
...
}Run output:
args[0] = -Didea.launcher.port=7536
args[1] = -Didea.launcher.bin.path=/home/dev/Software/idea-IU-143.1821.5/bin
args[2] = -Dfile.encoding=UTF-8
args[3] = com.intellij.rt.execution.application.AppMain
args[4] = xxx.project.Boot
args[5] = dump_argsDebug output:
args[0] = -Dfile.encoding=UTF-8
args[1] = xxx.project.Boot
args[2] = dump_argsI have tried to invalid cache and restart Intellj. The behavior in this case does not change. When I tried to create another entry point using the same code, the behavior is as expected. How can I debug this type of configuration problem?
请先登录再写评论。
What's in xxx.jar? Can you share a sample project to reproduce? Overriding the default app classpath may be not a good idea.
Hi Serge,
Our project is has some simple based upon Java chord project. http://www.cc.gatech.edu/~naik/chord.html
The source code is available here. http://jchord.googlecode.com/files/chord-src-2.1.tar.gz
Instructions on how to run the application is here: http://pag-www.gtisc.gatech.edu/chord/user_guide/start.html#id4
Inside the instruction, we are given
This is definitely one of the most unconventional programs I have configured with Intellij. I have tried the following:
1) Main class: xxx.project.Boot
VM args: -cp xxx.jar -Dxxx.work.dir=yyy xxx.project.Boot
Program arguments: dump_args
2) Main class: xxx.project.Boot
VM args: -cp xxx.jar -Dxxx.work.dir=yyy
Program arguments: dump_args xxx.project.Boot
Both gives very strange behavior. I agree that overriding the default application classpath is unconventional.
Side note/question:
What makes this project even worse for debugging is that the "chord.project.Boot" entry point and "chord.project.Main" entry point uses different classpath. Chord.project.Boot uses ProcessExecutor.execute to launch chord.project.Main with different VMArgs and paramters. For all run and debugging sessions, the current process is to break the program into two parts and run them separately by dumping out the VMargs and parameters generated by chord.project.Boot and feed them into chord.project.Main through intellij. The generated VMArgs for chord.project.Main consists of about 500-4000 words! It's very easy to make copy and paste mistakes!
Is there anyway to automatically use the return value of one run/debug session for chord.project.Boot and feed it into the VMArgs for chord.project.Main? Is there a better way to work with this kind of project configurations? If not is there a good way to change the program such that it's IDE/debugger friendly?
You can create your own startup class that will run Boot to get the parameters and then run Main class with these parameters, run without overriding classpath so that all the classes are in the single classpath.
1
Hi Serge,
I forgot to mention this important thing earlier that the classpath for Main is also generated by chord.program.Boot. The classpath is generated by Boot by reading one of the variable inside a configuration file provided by the user (may change frequently). Therefore there is no way to know the entire classpath of main beforehand without doing some processing (essentially what java.chord.Boot is doing). The problem right now is that after a new JVM is spawned from Boot using new classpath and VMargs, I am not sure if there is a way to debug the "spawned" program without resorting to manually connecting a remote debugging session.
I guess Remote debug is the only way to debug it properly without implementing some custom launcher.