SUMMARY
How can I iteratively run my unit/integration tests in "dev mode" of the liberty-maven-plugin and easily turn on and off the launching of the debugger into the JVM running the tests themselves?
BACKGROUND
While the liberty-maven-plugin by default starts the Open Liberty server in debug mode, sometimes you need to debug into the source of the unit/integration tests themselves. The liberty-maven-plugin dev mode launches the server and will (by default) run my tests each time I hit <Enter>.
I can leverage standard documented approaches, which by default will launch a forked JVM waiting for a debugger on port 5005, e.g.:
mvn -Dmaven.failsafe.debug liberty:dev
But what if I already started dev mode without that property set on the command line?
Is there an easy way to enable the debugger after the fact? Or to toggle it on/off across executions?
An easy way to "toggle" the debug mode for the tests is to use Maven project properties and dynamically comment/uncomment out the standard test debug properties, e.g. maven.failsafe.debug.
E.g this will launch ITs in a forked JVM, suspended and waiting for the debugger on port 5005:
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<maven.failsafe.debug>true</maven.failsafe.debug>
<!--
<maven.surefire.debug>true</maven.surefire.debug>
-->
</properties>
You can also configure the maven-failsafe-plugin in your pom.xml with normal plugin configuration to configure non-default behavior.
This should work with recent (since v3.1) versions of the liberty-maven-plugin, e.g.:
<plugin>
<groupId>io.openliberty.tools</groupId>
<artifactId>liberty-maven-plugin</artifactId>
<version>3.3.3</version>
</plugin>
This could be applied to a simple sample app like the one here:
https://openliberty.io/guides/getting-started.html
WARNING
Don't make the mistake of toggling the value to "false" since you're really configuring this parameter. Just comment it out completely to avoid suspending for the debugger.
Related
I recently start deploying my quarkus project utilising a jar build by uber-jar
now each time I try to acces to /q/dev or anything like that, I have this error :
RESTEASY003210: Could not find resource for full path: http://participeo-monchoixdevie-api-dev.emotic.fr/q/dev/
Any idea?
I'm running in profil dev.
Running in dev-mode and running from an uber-jar are mutually exclusive. If you're running an uber-jar, you are not in dev mode, and so the dev mode facilities are unavailable. Perhaps you mean that you compiled the uber-jar with quarkus.profile=dev, but that is a bad idea to do (it will probably only affect the set of used configuration values, but won't activate dev mode). Dev mode is what you get by executing mvn quarkus:dev on the project (or an equivalent if you're using Gradle).
When running spring-boot 2.2.0 in debug mode in both Eclipse 2019-06 and IntelliJ 2019.2, attempts to terminate the process via the IDE look like they kill the process (per the IDE), however, the java process is still running (verified by ps -ef | grep java).
When running non debug mode in Eclipse, the process can be terminated but Eclipse displays a message stating "terminate failed".
I've tried all sorts of older post options including:
-Dspring-boot:run.fork=false
-Dfork=false
Running spring at cmd line using mvn spring-boot:run terminates normally with ctrl-c.
I'm not using any spring plugins in Eclipse. I'm using open jdk 11.0.3+7.
Everything worked normally in spring-boot 2.1.7, 2.1.8 and 2.1.9
Is this possibly a bug in spring-boot 2.2.0?
With Spring Boot v2.2.0.RELEASE, JVM process forking is enabled by default when starting from the maven plugin:
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.2-Release-Notes#fork-enabled-by-default-in-maven-plugin
At this time, Intellij's maven plugin in 2019.2 and earlier versions don't appear to associate the child process to the debugging session and the IDE is even unable to shutdown the process once started.
None of the solutions in the references below worked for me. The only way I found to disable forking was to set the flag directly in the spring-boot-maven-plugin in the pom.xml like so:
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<!-- disable process forking that is enabled by default in spring-boot 2.2.0.RELEASE and higher -->
<fork>false</fork>
</configuration>
</plugin>
Afterward, I can now right-click on spring-boot:run, select debug, and the debugger connects to the right child process.
Additional references:
https://github.com/spring-projects/spring-boot/issues/18638
https://github.com/spring-projects/spring-boot/issues/18706
I had the same problem when I moved to 2.2.0 (+ JDK 11).
As #guidadic said : since 2.2.0, the JVM is forked by default.
Unfortunately for me, if I disable forking, I lose some features, like colour in the console, which worked before with no fork. In addition, forking allows to use DevTools, with live reloading, which is pretty interesting.
After a long and hazardous search on Internet, I found out a solution on a non related Stackoverflow answer somewhere (I lost the link).
In your main method, get your application context from the run method, and then open a console scanner.
When you will press the red square to kill your app in Eclipse, the scanner throws an exception : the Eclipse managed (visible) thread is the one linked to the console, so the scanner doesn't like that you dare to stop it.
You just need to catch it to exit from the application :
log.info("Press 'Enter' to terminate");
try (Scanner scanner = new Scanner(System.in)) {
scanner.nextLine();
}
finally {
log.info("Exiting");
System.exit(SpringApplication.exit(context));
}
Additionally, if you press 'enter' in your Eclipse console, it will exit your application and terminate all the application JVMs.
I'm running unit tests from the gradle command line (because running them from IntelliJ was causing problems for some reason.)
So I'd like to turn on a debug port for remote debugging from the unit test. How can I do that? Is there a way to send the -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y into the unit test itself? I'm using Gradle daemon mode so I'm not sure how that all works and can't find any documentation about it.
Actually it turned out that there's no need to set the jvmArgs manually. Instead you just need to invoke (docs):
gradle someTestTask --debug-jvm
and it will stop execution and wait for debugger connection. Now when this process hangs, go to IntelliJ, Eclipse (or other IDE) and set up an remote debugging configuration (remember to set source module - red arrow):
After it's set, run the debugger and you're done. Breakpoints may be set in IntelliJ directly.
Previous answer below:
test {
jvmArgs '-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y'
}
I'd like to debug with the Cloud-SDK Based Maven plugin (com.google.cloud.tools::appengine-maven-plugin v. 1.3.0).
I run the goal appengine:run in Eclipse in Debug, but this does not put me into Debug mode, e.g. stopping on breakpoints.
I can use remote-debugger, but it is a hassle to run two processes every time I need to start my application. Is there a way of running a Debug session with one command?
I believe the only way to do this with Maven is by setting up a remote debug configuration in Eclipse as described in the App Engine documentation.
<configuration>
<jvmFlags>
<jvmFlag>-Xdebug</jvmFlag>
<jvmFlag>-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005</jvmFlag>
</jvmFlag>
</configuration>
Your eclipse remote debug configuration needs to use the port specified in the jvmFlag arguments.
Another more practical way to run the debugger is to use Google Cloud Tools for Eclipse.
I need to setup performance tests which are run automatically triggered by a CI system. For that I want to use JMeter due to some scripts and experience already exist and I want to combine it with Maven.
During my research for a reasonable plugin I found that two plugins are existing:
jmeter-maven-plugin:
http://wiki.apache.org/jmeter/JMeterMavenPlugin
chronos-jmeter-maven-plugin:
http://mojo.codehaus.org/chronos/chronos-jmeter-maven-plugin/usage.html
Which one is better to be used? Both seem to be currently maintained and under development. Is there any experience on this? Even the configuration is similar.
I would be happy to get some hints to help me descide without playing around with both plugins for some days.
I haven't yet used the .jmx files with maven and specifically those plugins you mention.
But I can think of a way how to do it if I needed that.
So consider this, you can execute jmeter test in no gui mode.
Create a shell script wrapper that will execute the jmeter test in no gui mode, example (jmeter_exe.sh):
$JMETER_HOME/bin/jmeter.sh -n -t MY_LOAD_TEST.jmx -l resultFile.jtl
So this will execute the given script and store results in the .jtl file, you can use that to display your test results maybe this post will be useful to you, it's off topic for now.
With step one done.
2.You could then create directory scripts in your project root. Than you can put this in your pom.xml :
<plugin>
<artifactId>exec-maven-plugin</artifactId>
<groupId>org.codehaus.mojo</groupId>
<executions>
<execution>
<id>Run load Test</id>
<phase>generate-sources</phase>
<goals>
<goal>exec</goal>
</goals>
<configuration>
<executable>${basedir}/scripts/jmeter_exe.sh</executable>
</configuration>
</execution>
</executions>
</plugin>
And voila your test is executed during generate-sources phase. This might have been easier with the plugins you mentioned but I have no knowledge of those, this is what just came to my mind.
Use jmeter-maven-plugin: http://wiki.apache.org/jmeter/JMeterMavenPlugin.
It's the de-facto one and (as #Ardesco mentioned above) it doesn't require anything to be installed, which gives you abstraction on where JMeter executable is installed and all those kind of problems...
Word(s) of warning on the apache plugin (lazerycode):
It suppresses JMeter output by default, add the following configuration settings to prevent that:
<configuration>
<suppressJMeterOutput>false</suppressJMeterOutput>
<!-- to override debug logging from the plugin (although also in jmeter.properties) -->
<overrideRootLogLevel>debug</overrideRootLogLevel>
<jmeterLogLevel>DEBUG</jmeterLogLevel>
</configuration>
Looking at the source (of version 1.8.1), it seems the -Xms and Xmx are limited to 512
The plugin swallows exceptions so your tests may fail but you don't know why. It looks like they've just completed but not provided results.
The jmeter mojo kicks off jmeter as a new java process but does not provide the capacity to provide any arguments to this execution. So if exceptions are swallowed (See above), and logging isn't sufficient (which it may not be) it's not easy to debug the process to fing out what's wrong. We (my colleague) added the debug args to the process execution and debugged the jmeter call to find out.
you get informative output running jmeter directly for dev purposes. I'd say it's even more informative in the jmeter UI output.
I've not used chronos mind.
JMeter Maven Plugin by #Ardesco is updated every time JMeter version is released.
It is very well documented and works perfectly.
It is easily setup and allow easy addition of plugins like JMeter-Plugins or commercial plugins as long as required libraries.
You can read a full blog showing the setup for old version 1.1.10:
http://www.ubik-ingenierie.com/blog/integrate-load-testing-in-build-process-with-jmeter-ubikloadpack-maven/
For more recent version 2.5.1 (as of November 2017) ensure you read documentation:
https://github.com/jmeter-maven-plugin/jmeter-maven-plugin/wiki