 |
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Dmitry Jemerov - 01 Nov 07 14:31
Please ensure that the problematic module is compiled with debug info.
Thanks for getting back to me so quick!
We double checked that we are compiling in debug at our top level pom.xml using the -g arg. This cascades to the other modules. <plugin> I guess to start I'm curious why I don't see a check- or x-mark in the break point dot? > I guess to start I'm curious why I don't see a check- or x-mark in the break point dot?
This means that the class where the breakpoint was set, was not even loaded or that debugger is not active (not connected to the debuggee). I'm not sure yet what the best way would be to get you a project example, but I have made a little more progress based on your help so far.
The steps I take are: 1. Set up a Remote debugging configuration for Jetty on port 8080 2. Open a cmd to the web module of our project. 3. run: set MAVEN_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,address=8080,server=y,suspend=y 4. Start up the app from the cmd which gives: "Listening for transport dt_socket at address: 8080" 5. Start the IntelliJ debugger. This allows the app to finish starting up and it connects the debugging session. IntelliJ shows I have a valid breakpoint and the app will even stop at my break and allow me to step or whatever. So far so good, but... 6. When I F9 or green arrow click to resume the program, I get the message Application is Running. This should be ok, but the debugger, although it appears to still be connected it no longer stops at the breakpoints and none of the breakpoints are checked or X'd. Its like its been disconnected (or unloaded), but does not give any indication that it has stopped. I don't recall this being the behavior from my previous experience. By the way I've been using intelliJ for a few years now and we plan to buy it soon at this place, so I greatly appreciate your help. Andrew, please try using another port for debugger connection as 8080 is usually used by application servers for client connections. I thinks this is the reason (unless your Jetty is explicitly configured to use some port other than 8080). For example, ports 5005 or 5050 usually is free and can be safely used for debug connections.
Wow, thanks for the prompt reply. I've been saying y'all have good support!
I did try it on 5005 and I get the same result. It debugs fine up until I hit Resume and then the debugging "discontinues". Look at the logs...of course...step one...thanks for reminding me. No errors. What I see is a connection timeout.
--------------------------------------- I did read something about time outs and I thought that the additional plugin config was to address this. Note the: <maxIdleTime>3600000</maxIdleTime> I don't know if this is still in the rhealm of IntelliJ at this point, and again I'll take any help I can on this. <plugin> Just thought I would add that I get the same result with JBoss 4.0.5. Hope to talk to you again next week.
Hi Eugene,
I found one other curiosity to add to this ticket. I recall with the previous version of IntelliJ that I could randomly add in or remove break points while the debugger is running. This no longer works. Once I launch the debugger it does not recognize breaks I add afterwards unless I shut it all down and start over. Am I doing something wrong or am I really up against some kind of a problem? I confirmed that I get the same behavior when running jetty 6 or jboss 4.0.5 ga. Thanks again, So, If I understand the sutuation right:
1. Just after the debugger is connected, breakpoints get validated (a checkmark appears on breakpoint's icon). When execution flow comes to the class where the breakpoint is set, the breakpoint is hit by a thread and IDEA shows thread's variables. 2. After you resume execution, the breakpoints does not work anymore, while the debugger remains connected and you can pause/resume the whole application. (can you?) When breakpoins don't work anymore - what happens to breakpoint icon? Does it have a checkmark or a cross or neither of those? When you set a new breakpoint - what happens to its icon (is there a heckmark or a cross on it)? If there are no checkmarks on breakpoints, that means that the class was not even loaded during this debug session. If there is a checkmark on a breakpoint but it does not seem to work, can you confirm that the code is really called (using System.out.println())? ok, now the sutuation has cleared up.
The problem is that you debug Maven and not tests which are run by Maven's "surefire" plugin in a separate VM. Workaround: configure your surefire plugin not to use fork mode for tests; that way the tests will be loaded in the same VM where the Maven runs and debugger is attached to. The fix would be to make maven Integration plugin specify debug parameters for the right process, not for Maven itself. Eugene,
Thank you very very much for following up on this. I had reviewed your previous advice and was able to achieve an error regarding class not prepared which confirmed your observation. I spent a little time to learn about class loading of .war's and JPDA but was stuck. I greatly appreciate your advice and will find the time to follow up. Again many thanks! Andrew In a large multimodule project it is not practical to set <forkMode>never</forkMode>. The ability to debug in the forked test VM is important to making the Maven integration a first class feature.
you also may pass arguments for the VM forked by the surefire this way:
<project> [...] <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <forkMode>once</forkMode> <argLine>-Xdebug -Xrunjdwp:transport=dt_socket,address=5005,server=y,suspend=y</argLine> </configuration> </plugin> </plugins> </build> [...] Now you are able to connect to the new VM with idea's remote debug I think that the last two posts are assuming I want to debug a test case launched via the maven surefire plugin. This is not the case, however, there is surefire plugin support that provides forking options to maven.
My interest was to be able to debug the application that was launched via the maven jetty-plugin. After reading more about the plugin, and unless I missed it, the plugin does not offer similar forking control within its lifecycle. So if I need to debug I have two options, run as I previously described which is ok for short interludes, or debug against a locally deployed version of the application in JBoss. Might as well close this ticket and I'll take my issue to the Jetty plugin people. I've since seen several other posts that mention the same issue. Thanks to all who commented as it did help me to understand what I was up against. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Critical
When debugging a test goal, Maven integration specifies debug parameters to a Maven process. Instead, it should specify debug parameters for the process that is run by Surefire.
