Hey Paul, Within pax exam there are several processes which gets started. One which you need to debug is Karaf one. All steps you mentioned seems to be correct.
Debugging of option creation is not subject of debugConfiguration. This code is executed by maven (surefire) or IDE you run. In order to debug calculation of runtime configurations you need to debug process which does that, namely junit executor. General guide - @Configuration method is called before managed process is launched thus can't be subject of standard Karaf debugging. Keep in mind that surefire debugging might be tricky, but IntelliJ should be rather smooth. Just remember to swap debugger ports. In terms of exam debug configuration - pax allows you to specify port but also "hold" flag to wait for debugger to be attached: See: org.ops4j.pax.exam.karaf.options.KarafDistributionOption#debugConfiguration(java.lang.String, boolean) If you will set second argument to true runtime won't be started until you attach your debugger. Sometimes it is necessary to catch events associated with bundles which are starting early. >From what I observed IntelliJ can also skip breakpoints which have signature mismatches. Make sure you have all versions in sync. Kind regards, Łukasz -- Code-House http://code-house.org On 11.06.2019 12:07, Paul Fraser wrote: > Hi Again, > > Is it possible in an itest to debug into the inner karaf runtime? > > To try and debug into the "listBundleCommand" test in the Karaf Itest > example I tried > > 1. Set breakpoint on "String httpPort = ..." in the "public Option[] > config()" method in the itest code. > 2. Set breakpoint at first line in "listBundleCommand" test. > 3. Set a remote configuration in Intellij with port 5005. > 4. start karaf with bin/karaf debug. > 5. console displays "Listening for transport dt at address: 5005 > 6. Karaf starts up with branding and prompt. > 7. Shift-F9 in intellij starts a debug session. > 8. Debug console displays "Connected to the target VM, address: > 'localhost:5005", transport: 'socket' > 9. Run test (debug) > 10. Debugger stops at breakpoint '1' above. > 11. Does not stop at breakpoint '2' above. > 12. "listBundleCommand" test runs to completion and output as expected. > > If it can be done, what am I missing? > > Paul Fraser > > > > > > > > >
