NetBeans, Can't Set Breakpoint, "outside of any class"-CodePudding

I'm working on a NetBeans project with multiple sub-modules. The application runs on WildFly. Both are new to me, but I was able to create a local WildFly server that seems to run the application. I can also then attach the debugger, by process ID or port. But this is where I'm stuck. Any attempt to set a breakpoint results in "Not able to submit breakpoint LineBreakpoint SomeModuleClass.java : 123, reason: The breakpoint is set outside of any class."

I've tried this with the NetBeans WildFly server, starting WildFly independently of NetBeans but still locally, and on a hosted development instance -- all with no luck. Yes, it's being set on an executable line. But weirdly, another team member has been able to attach and set breakpoints using (as far as I can tell) an identical setup. [Update: turns out my peer is running NB on Windows on her host laptop whereas I'm on Ubuntu in a VM. I'd expect application differences but not with basic functionality.]

I've tried opening up submodule projects and setting breakpoints through them, changing the "Main Project", clean builds, reloads, reboots... nothing. I've also searched SO and Google for similar issues but have found no solutions. Seems like it must be in my NetBeans configuration since my peer doesn't see this with the same code or same external server. Could there be some build setting that is losing some class path info?

Does anyone have any ideas about what's going on here?

[NetBeans 13, Open JDK 11, WildFly 21, Ubuntu 20.04]

[Update:] As I said "Any attempt to set a breakpoint..." Such as any line in this class's method:

public class DateUtils {
    public static long convertMillisecondsToHours(long millis) {
        if (millis > 0) {
            return TimeUnit.MILLISECONDS.toHours(millis);
        } else {
            return millis;
        }   
    }
}

Here's how I'm starting the server and debugger:

Starting the server:

Starting the debugger:

Configuring the debugger (note break points are set and happy):

Debugger is launched and break points are broken:

CodePudding user response：

I was finally able to fix the situation, though I'm not entirely sure which of the many steps I took were the critical ones. I'm documenting the highlights here in case it may help someone in the future.

8080: already in use

As suggested by @DavidConrad I created two simplified projects. The first was just a simple Java app, and debugging worked fine. The second was an attempt at a simple web app, and that's where I ran into trouble. The IDE Log (View/IDE Log) was most helpful here. Consistently, if I tried to debug the project directly (i.e. right-click project, Debug), it would start WildFly successfully, Start the debugger, and then claim WildFly couldn't start because 8080 was already in use. So it seemed like NetBeans could start the server but then not see that the server was started.

9990: server rejected authentication

I found that NetBeans wasn't able to open the 9990 port (management-http) to WildFly due to a SaslException: DIGEST-MD5: Server rejected authentication. Ultimately this seemed to be caused by a lack of permissions on /opt/wildfly/standalone/tmp/auth, which seemed to be used to temporarily hold MD5 hashes.

So, I believe the core issue was that NetBeans wasn't able to connect to WildFly's management port 9990. And that this stemmed from permission issues with my installation.

There were some additional hurdles as well.

Once I was able to set some breakpoints, I also ran into a similar issue where for one class the breakpoints would fail with source file does not belong into the preferred root source. This is a known defect (see here) due to class overshadowing.

I also wrestled a bit with the JVM. I saw errors where basic elements of Java were unknown. I'm using Open JVM 11, which installs in /usr/lib/jvm, but NetBeans seems to expect it under /usr directly. This was resolved easily enough by adding a new Java platform, and then ensuring that NetBeans used the new one by default and that all of the projects were pointing to the new one.

And then there was that day I lost before realizing a config script had DOS line endings.