I configure launch.json to launch Java debugger and working successfully. After a short while, I see error ERROR: transport error 202: recv error: Connection reset by peer. I did google it, and it was suggested to change the debug argument from:
-agentlib:jdwp=transport=dt_socket,server=n,suspend=y,address=localhost:52252
to:
-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=localhost:52252
The debug arguments above are auto generated by vscode. How I can change it? I didn't find a way to configure such argument. The only option is to configure a task to run the command, and configure a debug option to run the task to launch the debugger and attached to that debugger session.
I am checking if there is a way to change the part to server=y as it is much easier.
Stack Overflow seems to have these answers. I never tested them myself though.
How to set java vmargs in vscode at workspace level
vsCode java.test.config vmArgs not working
Thanks to your mention, there is an article with a lot of details to configure a launch request with a preLaunchTask task configuration at https://github.com/microsoft/vscode-java-debug/blob/388c842bcc854a9e2f7f1e8fc5aa9520cb7fecf6/Configuration.md#attach-to-a-debuggee
If it helps, one of the SO questions, and a comment here, has a link to the VSCode configuration reference, https://code.visualstudio.com/docs/java/java-debugging#_attach . There you can see the attach request options.
My understanding of the attach vs launch is that
launch runs your App, and then automatically attaches a debugger to it.
attach is used only in cases where you have an already running JVM, lets say on some remote server, and you want to debug it.
How are you running starting your JVM? My guess would be that if you are starting the JVM from terminal, then put the server=y option there. If you want the VSCode to run the JVM, which I assume is the case, then the launch request is what you want.
Sometimes I have to deal with an improperly configured Eclipse installation and when I try to run it only the dialog "Java was started but returned exit code shows up without giving me any useful information to trace the actual reason Java failed to start.
What is the best approach to debug this kind of problem?
There are several command-line options that can help with troubleshooting. I'd start with -debug -consoleLog and see if that produces useful output.
You can run eclipse with the verbose attribute from command line
eclipse -verbose
Read more about debugging eclipse and plugins here http://exploreeclipse.blogspot.nl/2014/01/enable-eclipse-verbose-for-trouble.html?m=1
By default, eclipse launches with javaw.exe process, since it's a window thread so you will not be able to see any verbose messages.
Step 1: Add below VM parameter in eclipse.ini file. By default, eclipse will have javaw.exe, modify it to java.exe
-vm
C:/KK/jdk1.6.0_32/bin/java.exe
Step 2: Pass verbose parameter during the eclipse launch.
eclipse -verbose
Edit: I've tried adding set "JAVA_OPTS=%JAVA_OPTS% -Dspring.profiles.active=test" inside standalone.conf.bat and this hasn't worked. It's as if it's being ignored.
Is it possible to set -Dspring.profiles.active=testlike one might if calling
java -Dspring.profiles.active=test -jar build/libs/weather-0.0.1-SNAPSHOT.jar
as a line in standalone.conf.bat? If not, what is the reason?
I've tried this (as well as in domain.conf.bat and appclient.conf.bat) and it seems to be completely ignored (I killed the java process and restarted the wildfly service to have the war redeployed). This is running on Windows 10.
Edit: it works perfectly fine when doing it from IntelliJ and running it in debug. I just want to be able to reproduce this on wildfly.
I discovered the problem and it relates to specific changes to other .bat files made by other people who worked on this project within the "standalone" directory. There was some strange interference with how %JAVA_OPTS% was being set (and overwritten). Even though server.log logged (multiple times that -Dspring.profiles.active=test was set, it wasn't "sticking".
I resolved this by doing a dive into all the places the VM args were messed with in the .bats in standalone, using recursive file search in Notepad++. The takeaway for anyone else is that, if running on windows, you should be able to set -Dspring.profiles.active=test (or whatever your arg is) in standalone.conf (and nowhere else), and that should be sufficient to carry-over into the wildfly java.exe process.
I have set up my glassfish project according to this guide: https://www.jetbrains.com/help/idea/creating-and-running-your-first-restful-web-service.html
The run configurations are created automatically and as far as I can see they use glassfish's startup-script.
However, upon startup I can see that these commands are executed:
C:\path\glassfish5\glassfish\bin\asadmin.bat start-domain domain1
"C:\path\Java\jdk1.8.0_171\bin\java.exe" -Dfile.encoding=windows-1252 -classpath "..."
Somewhere, somehow, a Dfile.encoding parameter got added. I tried setting this exact parameter to "UFT-8" instead in the launch configurations VM-Options, but the resulting commands still look exactly like above, no mention of my UTF-8.
I tried searching where this parameter is set or how to change it or anything regarding this, but I found absolutely nothing.
Does anyone know how I can make IntelliJ/glassfish startup with UTF-8 encoding instead? As mentioned above, setting VM options in the run-configuration had no effect.
Is it possible to launch a debugger such as jdb from Maven? I have a pom.xml file that compiles the project successfully. However, the program hangs somewhere and I would really like to launch jdb or an equivalent debugger to see what's happening.
I compile using mvn compile and launch using:
mvn exec:java -Dexec.mainClass="com.mycompany.app.App"
I was expecting something like:
mvn exec:jdb -Dexec.mainClass="com.mycompany.app.App"
to launch the debugger but, as usual, my expectations are incongruent with maven's philosophy.
Also, I couldn't find any documentation (on Maven's website or google) to describe how debugging works. I suspect that I have to use some plugin.
If you are using Maven 2.0.8+, run the mvnDebug command in place of mvn and attach a debugger on port 8000.
For Maven <2.0.8, uncomment the following line in your %M2_HOME%/bin/mvn.bat (and maybe save the modified version as mvnDebug.bat):
#REM set MAVEN_OPTS=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000
More details in MNG-2105 and Dealing with Eclipse-based IDE.
Just as Brian said, you can use remote debugging:
mvn exec:exec -Dexec.executable="java" -Dexec.args="-classpath %classpath -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=1044 com.mycompany.app.App"
Then in your eclipse, you can use remote debugging and attach the debugger to localhost:1044.
I thought I would expand on these answers for OSX and Linux folks (not that they need it):
I prefer to use mvnDebug too. But after OSX maverick destroyed my Java dev environment, I am starting from scratch and stubbled upon this post, and thought I would add to it.
$ mvnDebug vertx:runMod
-bash: mvnDebug: command not found
DOH! I have not set it up on this box after the new SSD drive and/or the reset of everything Java when I installed Maverick.
I use a package manager for OSX and Linux so I have no idea where mvn really lives.
(I know for brief periods of time.. thanks brew.. I like that I don't know this.)
Let's see:
$ which mvn
/usr/local/bin/mvn
There you are... you little b#stard.
Now where did you get installed to:
$ ls -l /usr/local/bin/mvn
lrwxr-xr-x 1 root wheel 39 Oct 31 13:00 /
/usr/local/bin/mvn -> /usr/local/Cellar/maven30/3.0.5/bin/mvn
Aha! So you got installed in /usr/local/Cellar/maven30/3.0.5/bin/mvn.
You cheeky little build tool. No doubt by homebrew...
Do you have your little buddy mvnDebug with you?
$ ls /usr/local/Cellar/maven30/3.0.5/bin/mvnDebug
/usr/local/Cellar/maven30/3.0.5/bin/mvnDebug
Good. Good. Very good. All going as planned.
Now move that little b#stard where I can remember him more easily.
$ ln -s /usr/local/Cellar/maven30/3.0.5/bin/mvnDebug /usr/local/bin/mvnDebug
ln: /usr/local/bin/mvnDebug: Permission denied
Darn you computer... You will submit to my will. Do you know who I am? I am SUDO! BOW!
$ sudo ln -s /usr/local/Cellar/maven30/3.0.5/bin/mvnDebug /usr/local/bin/mvnDebug
Now I can use it from Eclipse (but why would I do that when I have IntelliJ!!!!)
$ mvnDebug vertx:runMod
Preparing to Execute Maven in Debug Mode
Listening for transport dt_socket at address: 8000
Internally mvnDebug uses this:
MAVEN_DEBUG_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE \
-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000"
So you could modify it (I usually debug on port 9090).
This blog explains how to setup Eclipse remote debugging (shudder)
http://javarevisited.blogspot.com/2011/02/how-to-setup-remote-debugging-in.html
Ditto Netbeans
https://blogs.oracle.com/atishay/entry/use_netbeans_to_debug_a
Ditto IntelliJ
http://www.jetbrains.com/idea/webhelp/run-debug-configuration-remote.html
Here is some good docs on the -Xdebug command in general.
http://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/jrdocs/refman/optionX.html
"-Xdebug enables debugging capabilities in the JVM which are used by the Java Virtual Machine Tools Interface (JVMTI). JVMTI is a low-level debugging interface used by debuggers and profiling tools. With it, you can inspect the state and control the execution of applications running in the JVM."
"The subset of JVMTI that is most typically used by profilers is always available. However, the functionality used by debuggers to be able to step through the code and set breakpoints has some overhead associated with it and is not always available. To enable this functionality you must use the -Xdebug option."
-Xrunjdwp:transport=dt_socket,server=y,suspend=n myApp
Check out the docs on -Xrunjdwp too. You can enable it only when a certain exception is thrown for example. You can start it up suspended or running. Anyway.. I digress.
I found an easy way to do this -
Just enter a command like this -
>mvn -Dtest=TestClassName#methodname -Dmaven.surefire.debug test
It will start listening to 5005 port. Now just create a remote debugging in Eclipse through Debug Configurations for localhost(any host) and port 5005.
Source - https://doc.nuxeo.com/display/CORG/How+to+Debug+a+Test+Run+with+Maven
If you are using Netbeans, there is a nice shortcut to this.
Just define a goal exec:java and add the property jpda.listen=maven
Tested on Netbeans 7.3
If you don't want to be IDE dependent and want to work directly with the command line, you can use 'jdb' (Java Debugger)
As mentioned by Samuel with small modification (set suspend=y instead of suspend=n, y means yes which suspends the program and not run it so you that can set breakpoints to debug it, if suspend=n means it may run the program to completion before you can even debug it)
On the directory which contains your pom.xml, execute:
mvn exec:exec -Dexec.executable="java" -Dexec.args="-classpath %classpath -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=1044 com.mycompany.app.App"
Then, open up a new terminal and execute:
jdb -attach 1044
You can then use jdb to debug your program!=)
Sources:
Java jdb remote debugging command line tool
Why not use the JPDA and attach to the launched process from a separate debugger process ? You should be able to specify the appropriate options in Maven to launch your process with the debugging hooks enabled. This article has more information.
I use the MAVEN_OPTS option, and find it useful to set suspend to "suspend=y" as my exec:java programs tend to be small generators which are finished before I have manage to attach a debugger.... :) With suspend on it will wait for a debugger to attach before proceding.
I couldn't make any of the other solutions work and then I tried starting maven with the following.
mvn exec:exec -Dexec.executable="java" -Dexec.args="-classpath %classpath -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=8000 com.example.Main"
This worked for me and then I searched some more and found this other answer. IntelliJ can run Maven project in debug mode but ignores breakpoints
The fact is that my application is a spring-boot application. Now, the link referred to above may be right and the problem is that the spring-boot plugin creates a new fork that somehow invalidates the interaction between debugger and target app. I'm saying this because I got some info on how this may work from here
In any case, I don't know how the two solutions are related to each other. Is the first solution also preventing spring-boot from creating a fork??
Sadly I have no clue at the moment.
Here is how I do it.
For example:
mvn clean azure-functions:run -DenableDebug
Then, after it starts up, you'll see a link in the Terminal that says "Attach Debugger".
To me, that is the easiest way to do it.