I'm writing a web app that uses JAX-RS (Apache CXF) and JPA (Apache OpenJPA) and is deployed using TomEE+. I've started using Arquillian via the arquillian-tomee-embedded maven dependency to unit test my REST services.
When I use IntelliJ to launch the test phase of Maven's build lifecycle everything works great. It runs OpenJPA's enhancer on my JPA Entities, kicks off the unit tests, and I'm able to successfully call my web services and they're able to successfully access the database.
Unfortunately, if I launch the test phase in debug mode everything still works but none of my breakpoints hit. What must I do to correct this problem?
I've found a tedious workaround. I can right click each unit test and run in debug mode and the debugger will hit breakpoints...but I have to manually run the OpenJPA enhancer beforehand in order for the JPA code to work.
When you "launch the test phase in debug mode ", it means that Maven runs in debug mode, not that it debugs your app. You cannot debug your app through maven. Maven runs the tests using surefire-plugin, and you cannot use breakpoints and debug.
There can be two possibilities:
1) The code / break-point(s) are not reachable / not getting called with current context.
2) You are NOT running application in Debug mode.
Make sure that you are Debugging the application and not run it like "Run As..."
Considering that you are using Eclipse, Run -> Debug As -> <-Your Target Application->
Also make sure that where ever you have added breakpoints, those lines are reachable.
I've hit problems with IntelliJ debugging not hitting breakpoints before. You may have luck disabling the JUnit plugin and restarting IDEA.
Related
I was able to Debug and Run my spring boot application on intellij, until I made some changes in my application-profile.yml. which caused some failures.
I played with some debug options in intellij to figure out the issue.
I corrected the YML and then I was able to run the application fine.
But now when I start my application in Debug, Intellij is not taking new values, Its still failing with old reasons. I can run my application as Run Main class, but not Debug main class.
Seems some caching in intellij,
I restarted intellij,
restarted my Machine
I did maven clean
Deleted Configuration (Alt_shift+F9 --> EditConfiguration -- deleted the one present)
But still when Debugging, even if Junit or Main Application class, its failing for same reason.
Reading old YML value which
I'm using community addition.
Wasted more than an hour, still dont know the solution, I just deleted .idea folder and .iml file. and reimported the project in intellij.. all worked fine..
When I develop spring boot gradle projects in intellij idea, if I want to change some code and restart the project, I have to click the Make Project menu item and this will trigger a gradle build.If the gradle deamon is dead, it will start first which is an upset process.
While in Spring Tool Suite, everything is so easy, just Ctrl S and STS will restart immediately witout the long gradle build. So is there any way to make intellij idea restart faster?
I know if the gradle deamon is alive, gradle build in intellij idea is not very slow and is acceptable. But on my computer, the deamon can usually live for only several minites. When I change some codes and want to see the effects, the deamon died. I have to start the deamon every time! Is there any other ways to make the deamon live longer?
Thanks a lot if there is any useful tips!
Well, thanks to #Gregg and #CrazyCoder 's comment, I found some useful links:
Developing/Debugging a Gradle-built Spring Boot app in IntelliJ IDEA
I accidently enable the delegate to gradle option in idea, which will trigger gradle build instead of idea's build, which is faster than gradle's. So disable the delegate to gradle option is a choice.
From another post, I get some idea to use the continuous build in gradle: open a terminal and run gradle assemble --continuous, when files are changed(for example save files or defocus window), gradle will compiles files automatically. Then run the spring boot app use gradle bootRun or from the tasks in idea, everything is ok. But this way will start two gradle so ram usages are larger.
Update:
I found another way to automatically compile. Fisrt, enable build project automatically option, then use ctrl shift a and input registry to open a dialog, and then enable compiler.automake.allow.when.app.running opiton. Finally, project will compile automatically and spring boot will also restart automatically.
I have a JVM application that I need to debug using breakpoints with a Gradle task (run and test as dependencies) within IntelliJ 2016.3.5.
There are various sources on how to accomplish debugging with Gradle and IntelliJ:
Debug Gradle plugins with IntelliJ
Using Intellij to set breakpoints in gradle project (most helpful one)
https://youtrack.jetbrains.com/issue/IDEA-119551
https://youtrack.jetbrains.com/issue/IDEA-86465
https://youtrack.jetbrains.com/issue/IDEA-119494
However, these sources are either outdated or meant for another scenario. I do not want to debug the Gradle script but the JVM that runs the actual Java/Scala application. Moreover, the recent versions of IntelliJ use the Gradle Tooling API, which does not offer the option to turn off the daemon. A native support from JetBrains is only provided using the debugging button on the run and test tasks directly, but not if they are defined as dependencies from another task (e.g., check).
According to the sources, this is the way to go then:
run { // or test, doesn't matter
jvmArgs "-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005"
// xor, or both, doesn't seem to make any difference
debug true
}
In any way, Gradle (or the JVM) will then start to listen on port 5005:
Then, I have created a remote configuration with the following parameters:
But when I start the IntelliJ remote debugging task, it fails:
I have also tried using port 5006 and suspend=n without success. Before that, I tried using Gradle arguments in the IntelliJ-Gradle run task. Then, it indeed connected, but seemingly to the Gradle script and not the application JVM because it did not interrupt at the breakpoints. How to fix this?
Debugging of gradle tasks like 'test', 'run', actually all gradle tasks that implements JavaForkOptions interface, should work in IntelliJ since 2014 year
Meanwhile, I found the solution myself. If you have a similar issue, follow the approach mentioned above using the debug option.
test {
debug true
}
But make sure that external connections are accepted in the settings after IntelliJ restarted:
Then, it connects to the correct JVM and interrupts at the breakpoints using the remote task:
If you restart IntelliJ, however, with the very same option (external connections) enabled, then the debugging task might fail due to a blocked port:
So, for some reason, IntelliJ blocks that port after a restart but it is necessary to enable the setting for the debugging task to work. That's odd and I don't think it is intended to behave like that.
Anyways, if you disable the setting and restart, the port will be open again. Then, re-enable the setting, do not restart, just run the Gradle task, and the debugging task. It will work.
I hope this helps anyone else looking for an intermediate solution to debug JVM applications with Gradle and IntelliJ among the confusing and partially outdated answers out there. If anyone has a better or simpler suggestion, feel free to append your answer.
I have been asked to debug a Java application installed in Apache Karaf (OSGi) running in a VM hosted on my dev machine. My colleague has been able to do remote debugging successfully using Eclipse. My tool of choice is IntelliJ and in my attempts to debug remotely, IntelliJ connects successfully (via socket). If I pause the debugging session, the Karaf console freezes as expected and resumes when I click continue. But when I am paused I can see the following message in IntelliJ and my breakpoints are ignored.
Target VM is not paused by breakpoint request. Evaluation of methods is not possible in this mode.
What does this mean? I have searched and also gone through the documentation for IntelliJ. Why can Eclipse allow working breakpoints and IntelliJ doesn't?
Firstly, one presumes that you have started up your OSGI container (for example, Fuse Fabric) in debug mode. Often this is done by adding the argument debug to the start script.
For example:
c:\> startfabric.bat debug
As Tim noted, you just now need to make sure that your source code is exactly synced with whatever is deployed to the OSGI container.
To be sure, check out the exact same source code version as what is deployed to the server, and choose Build -> Rebuild Project. If necessary, do a mvn clean install on your machine, and deploy a bundle / feature that you have built yourself - then you know that the code you have locally should exactly match what is deployed.
Lastly, check your debug panels in IntelliJ, and remove any Watch expressions that might be interfering whilst in debug mode.
So I've been running into this for a while and I've seen other questions / answers pertaining close to the subject but I don't feel I understand what's going on yet.
I'm using Spring Roo 1.1.15, Eclipse 3.6.0 & Maven 2.2.1.
I have found that if I have had a successful run of tests (running from within Eclipse) and then make any modification to a RooEntity class object that any/all Roo-centric tests will fail on the next run with the following:
Entity manager has not been injected (is the Spring Aspects JAR configured as an AJC/AJDT aspects library?)
This will continue until I do the following:
Enable "Build Automatically" in Eclipse's Project menu
Flip over to a terminal window and at the project root issue:
mvn -o clean package
Once mvn is finished, then flip back over to Eclipse and refresh the project
Let Eclipse refresh and then rebuild
At this point I can run the test suite and it will report accurate information. (Tests pass or fail based on actual results and not complaining of the Entity manager.)
I have not had the time to upgrade this project to the latest version of Roo and I admit that may be the proper "fix" but I was wondering if anyone else has seen this behavior and can explain what's happening in the rebuild process that would cause the manager to "disappear"? If so or you have found a way to allow Eclipse to act successfully independent of the terminal workaround, feedback would be great.
Thanks as always.