Develop Reference

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

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:

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. 🙄

How do I tell a remote debugger to actually suspend at some point?

I'm using IntelliJ Idea debugger and I have some 3rd party app with its sources (shouldn't matter, but it's hyperic). I need to see when some methods are being executed and trace the execution process. I've successfully connected to the app using remote application debug but can't figure what to do next. O_o
It is possible to suspend the app, but how to attach sources and tell it when exactly to suspend (method call/line of code/etc)?
EDIT: Alternatively I could use eclipse (doesn't matter what to use if it's working).
EDIT2: It's not one of my projects/modules/whatever.

Open the source code in an editor and set a break point.
The debugger should be smart enough to figure out what you want to achieve.
[EDIT] Create a small project which contains the sources and all the JARs. That should compile without error and allow you set breakpoints.
In Eclipse, you can attach sources to JARs. That way, you can set breakpoints.

To debug the remote application you need it's sources in your eclipse (whatever IDE) project. And then just set breakpoints and launch remote debugger with appropriate port.

Is it possible that the source code is out of sync with the code being executed? I've had this happen before so that the breakpoint I set was actually on a non-executable line (whitespace, comment) according to the remote machine's version of code.
The only other time I've seen something like that was when the remote machine was running several JVMs and I accidentally connected to the wrong port (and thus the wrong JVM).
When you are debugging the red dot that represents the breakpoint should change slightly, what does it look like while you are debugging? For example, if the line is non-executable I think there will be an X on top of the dot.

Running a program in Debug mode is incredible slow

Since recently it's much slower running a program in Debug mode in Eclipse Galileo.
I'm not aware of any changes.
Do you know what could be the cause? Running it normally is not a problem.

Another "debugging break" is the use of method entry/exit breakpoints.
Did you try to remove all breakpoint definitions once?
Sometimes i think Eclipse is getting out of synch with some of its internal/displayed state. Perhaps you should try to setup a new (not copy) of your workspace. This sometimes helps me to recover from spurious features.
This is how you can remove all breakPoints
Eclipse -> Run -> Remove All Breakpoints - for removing all Breakpoints for all Time
Eclipse -> Run -> Skip All Breakpoints - for temporary remove breakpoints

I faced this issue lot of time. Solution is simple, Remove all breakpoints.
(Run >> Remove All Breakpoints)

I was just running a program in Eclipse debug mode that was almost instant without debugging but when I ran it in debug mode, it was really slow. I went through and deleted a ton of random useless breakpoints I wasn't using and then the program sped up A LOT (200x or so).

Disable 'Show method result after a step operation'.

I have found that i often forget that i have a bunch of expressions added to the expressions panel that are no longer needed that are none the less being evaluated (or are failing to evaluate) and this slows stuff down a good deal. Make sure that you keep those expressions cleared out when not needed.

Close eclipse... clear %temp% folder, temp folder... disable breakpoints... in most cases this will definitely solve the problem.

What kind of JVM are you attaching to? I found in my experience, that in debug mode IBM JDK is slow like hell.
For all JVMs, check if you have conditional breakpoints with expensive condition. Try disable breakpoints. You may have exception breakpoints or expressions. Try disable or remove them.

In my case, Eclipse was trying to build files, which I was doing manually.
Going to Window -> Preferences -> Run/Debug -> Launching, and then disabling "Build (if required) before Launching" underneath General Options solved the slowness.

Clearing temp files on Windows fixed it for me
"C:\\Documents and Settings\\{user}\\Local Settings\\Temp"

Normally Java Virtual Machine turns off Just in time compiler (JIT) when running in debug mode. On IBM WebSphere, the IBM JDK is heavy de-optimized and will be very slow.
By the way debugging also make impossible to recompile and optimize the code.
Relay on logging for complex debugging: it will save your days on production, where you cannot debug for sure.

With all the learning over the years working with eclipse, here are couple of suggestions
keep your open projects to minimal what you actually need
keep it lean and thin - uninstall the plugins/features which you don't use (mylnn, validations etc).
No matter what you do, the eclipse tend to get slower over the time. The ultimate solution to get a responsive IDE is to recycle your existing workspace (create new workspace and bring in the projects which you need).

Before you run your application in debug mode press on (disable all breakpoints) and you wont experience slow loading or any problems. After your application has started just enable the breakpoints and then you can debug your code.

I faced this issue recently after upgrading my macOS version.
I wasn't able to fix the slow debugger with all the above solutions, I ended up installing a newer version of eclipse, and everything works prefect after that.

It happened to me once and the problem was, I had the folder with ALL my projects source code in the Source Look-up. This way, not only the debugger got really slow (because it probably crawled all my files) but also I could not do a lot of things such as inline execution.
The takeaway: check your Source Look-up. When debugging right-click in any thread from the Debug view, choose Edit Source Look-up and see what what you can/should remove from there. In my case, it was a spurious folder, other times you may have too many projects, folders, JARs etc. and may remove some.

Recently i was having extreme slow performance debug, both in eclipse and visual studio code (vs code)
In my case, the problem was with lombok configuration in JPA entities.
I changed the #Data anottation to #Getters and #Setters.
Looks like hashCode() and equals() implementantion of lombok was in conflict with JPA.

I've had the same problem. The work around i'm using is to just set a single break point and run to it. After that I don't try to step over or continue i just restart the test and move my break point to the next line I want to view. I am using JUnit with Mockito in Intellij. I'm guessing it has something to do with the byte code manipulation not matching the actual code in intellij. (In intellij, there is an implementation internal to intellij for running JUnit tests. Mockito may not play will with it)

RAD won't deploy class files to running websphere server (local development0

Environment: WinXP.
RAD: Version: 7.5.3 (Eclipse 3.4.2)
Websphere 6.1
I have two web projects on my local RAD environment and 4 or 5 sub jar projects. When I change classes in debug and regular start mode, the files don't get copied to the server for runtime.
So, normally I have to restart the server completely or add/remove the project all together.
I may make a change to Servlet.java
When I do "publish", the ear/application seems to restart, but my changes are not there. So I normally restart the server. This is a productivity killer.
Additional settings:
* Publish automatically turned off.
* Minimize resources. Use workspace.
What can I do to make sure that the classes get copied over.
My theories:
I have parent_first/application for the class loader/war settings. Is that an issue?
Maybe I should remove the ear and add it back to websphere
I did a clean on the server?

Delete your application from the server.
Restart the server
Go to the admin console and ensure the application is not listed in the list of applications, if it is then delete it.
Restart the server
Deploy/publish again.

Unfortunatelly, RAD with WebSphere are very unstable environment.
From my experience, debug mode is causing a lot of problems. It's mainly what you describe, changes not being seen after republish, additionally very quick memory depletion. I'm using debug mode as last report.
In normal mode everything should (read: in most cases) work correctly. You add/change some classes and make 'republish'. Sometimes it's necessary to do clean on project before republishing it.
But when the Websphere is running longer together with RAD, I observe that often something get stuck. You have there clean option on the server, with is expected to clean the cache (which included also compiled classes). You should also observe memory usage. If it's nearing the limits of JVM (memory leaks are heavy) Websphere stops to function correctly, and you must restart it.
However, I sometimes get serious issues where the clean isn't helping, and then it's necessary to remove all applications, stop the websphere (close all projects and open then again) and then start Websphere and add all applications, restarting RAD in the meanwhile. But it's not everyday, maybe every month or so...
If you are really unlucky, RAD can break your workspace, which will force you to delete all project, delete project files (or do a fresh checkout) and import everything once again, or even start a new workspace (happens also with 'normal' Eclipse, ~1-2 years).

You are using the latest RAD so do I... here is my guide for solving this issue:
Enable the error log to see if you get intuitive info on internal RAD errors, in 7.5 it is available on "Show views"
If your changes are not deployed Clean project
If your changes are not deployed yet Rebuild project
If your changes are not deployed yet Redeploy project
If your changes are not deployed yet Clean server
If your changes are not deployed yet Restart server
Or:
- Use ant or maven to make deployments straighforward and ignore the pain due to websphere and eclipse having internal bugs (which you may see in the error log if it is fully enabled).
Regards.

Are your JSPs copied correctly? That is, when you make a change in one JSP, can you see change immediately upon browser refresh? If this works, then I see no reason why classes aren't also published. JSP auto refresh should work in normal and debug modes.
Now, is "build automatically" enabled? If no, your classes won't get compiled and transferred. Parent_first/application for class loading shouldn't be an issue.
Is the local app. server running in development mode? If not, it should be.
While developing, use debug mode. Hot deploy will assure changes to your methods are seen immediately. Changes in classes won't be seen (i.e. adding a method will require application restart).
Is your app. server using global security? I have it turned off and auto redeploy works without problems.
Class reloading has always been a problem while developing Java EE applications. Try do erase that ear file from your WAS and redeploy it again.
If all else fails, try JRebel.

How to move only the current file with Eclipse and/or Ant?

I am working on a small team of web application developers. We edit JSPs in Eclipse on our own machines and then move them over to a shared application server to test the changes. I have an Ant script that will take ALL the JSPs on my machine and move them over to the application server, but will only overwrite JSPs if the ones on my machine are "newer". This works well most of the time, but not all of the time. Our update method doesn't preserve file change day/times, so it is possible that an Update on my machine will set the file day/time to now instead of when the file was actually last changed. If someone else worked on that file 1 hour ago (but hasn't committed the changes yet), then the older file on my PC will actually have a newer date. So when I run the Ant script it will overwrite their changes with an older file.
What I am looking for is an easy way to just move the file I am currently working on. Is there a way to specify the "current" file in an Ant script? Or an easy way to move the current file within Eclipse? Perhaps a good plugin to do this kind of stuff? I could go out to Windows Explorer to separately move the file, but I would much prefer to be able to do it from within Eclipse.

Add a target to your ant build file to copy a single jsp using a command line property definition as #matt b described.
Create a new external tool launch profile and use the "String Substitution Preferences" to pass in the reference to the active file in the editor (resource_name).
See Eclipse Help | Java Development User Guide | Reference | Preferences | Run/Debug | Launching | String Substitution

How would Ant know what file was "current"? It has no way of knowing.
You could pass the name of the file into your Ant script (by taking advantage of the fact that any arguments you pass into Ant with -D are automatically parameters in your script)...
ant -Dfile=myfile.jsp update
and have your script look something like...
<copy file=${myfile} todir="blah"/>
...but it would probably be a pain to constantly type in the name of the file on the commandline.
Honestly, the type of problem you've described are inevitable when you have multiple developers sharing an environment. I think that a better approach for you and your team long-term is to have each developer work/test on a local application server instance, before the code is promoted. This removes all headaches, bottlenecks, and scheduling trouble in sharing an app server with other people.

You should really use source control any time you have multiple people working on the same thing (well, you should use it any time regardless, but that's a different conversation). This way, when conflicts like this occur, the tool will know and make someone perform the merge so that no one's changes get lost. Then, the test server can run on a clean checkout from source, and each developer can also test the full application locally, because everyone's changes will be instantly available to them through the source repository.

I suggest you to use source control. I prefer Subversion. You can use CruiseControl to make the build automatically whenever someone commits new code.

The antrunner4e plugin is exactly what you are looking for -- see http://sourceforge.net/projects/antrunner4e/