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

Failed to connect to EJB on JBoss AS 7

Been helped through this uphill battle by some very smart Java and JBoss experts, and I appreciate it. I finally got the EJBs to deploy on the new JBoss AS 7 without error. Yah! Now, however, I need to know the next step in addressing those beans from my application. I have read a lot and found conflicting examples, unfortunately. My code is thus:
DodsrUserSessionEJB o = ( DodsrUserSessionEJB) ctx.lookup("/dodsr/"+ejbName+"/remote");
This works on JBoss 6. What should the new one look like to work on AS 7?
Perhaps I spoke too soon. There are still 94 errors in the log file, many of which have the name "beans" in them, like remoting3-jboss-beans.xml. Even though the log says that my EAR file was deployed could some or any of these error prevent me from connecting to them?

Web application deployment under embedded Tomcat 7.0.32

We have been using tomcat 7.0.19 successfully in embedded mode. However recently due to some fixes in our area of concern we decided to move to tomcat 7.0.32. Most things work as expected with same code and newer version, however the war deployment for some reason has'nt worked well. I have a couple of servlets registered with my tomcat. Facing below 2 issues,
Has something changed from 7.0.19 to 7.0.32 from embedded tomcat behavior. To detail this out let me explain the behavior difference, with 7.0.19, i could deploy my application and when i hit the "host:port/contextpath" it loaded the applications start page (i.e. welcome page, this page is UI centric and does not need a server intervention, so none of my servlets get called). However with 7.0.32 the same url results in my servlet being called.
So to debug the problem, i commented most of my code so that i have a vanilla tomcat implementation, just the very basic stuff, i.e. setting the engine name, default host, setting host properties, adding a connector (nio, with default properties) and deploying a war. No servlets and other things, just to check if the very basic stuff works. To my surprise when i ran this code it still failed with the same problem within my servlet, how did that happen, now that my code is commented it does not register any servlets, still where does it find it from? Does embedded tomcat store some old references, which are not getting cleaned on subsequent runs? I tried changing the port, but that too didn't help.
I am hitting the wall here, not able to understand this wierd behavior, if i figure out #2, only then can i make some progress on #1.
Thanks in advance,
Vikram

Figured out what the problems were.
In reverse order,
2 - This actually was a weird behavior with the vanilla embedded tomcat code too invoking the servlets which never were registered in the first place. The problem here was with eclipse, for some reason it picked up the old reference of my class. The moment i ran the same code from outside of eclipse i.e. via command prompt, things were back to normal.
1 - This problem was related to web deployment, in my code i was additionally setting my classloader into WebappLoader and eventually adding my application jars into it. This for whatever reasons worked fine with 7.0.19, however did not with 7.0.32, the moment i externalized all my jars to be loaded during application startup via classpath this problem too was resolved.
Thanks,
Vicky

JBoss application deployment error persists even after using a fresh JBoss distribution on Ubuntu

I am facing a very weird problem. This is one of those errors that just doesn't make sense. Please read till the end before jumping to conclusions.
When I deploy our web application (.ear file) containing web services written in Apache CXF on JBoss without making any changes to the web.xml file, everything seems to work fine.
When I make some changes to the web.xml file and rebuild the ear and redeploy the application, JBoss is unable to deploy my application because of some class loader conflicts. This is completely alright because I am expecting JBoss to throw these errors.
After I stop the JBoss server instance and revert the changes made in Step 2 to the web.xml and rebuild my .ear file and redeploy the application in JBoss, the same errors that were thrown in Step 2 are thrown again. How is this possible considering that I reverted all the changes I had made to the web.xml in Step 2 and restarted JBoss with a fresh .ear file to use?
I even tried downloading a fresh copy of JBoss and rebuilding and redeploying the application on the fresh copy. The same errors that were displayed in Step 2 are displayed in the application even though the web.xml no longer contains the changes that were made in step 2.
The only way I am able to get rid of the errors is by taking a fresh checkout of my code base and building my application and deploying a fresh version of my application in a fresh JBoss server. This doesn't make sense because changing the web.xml doesn't implicitly change other files or classes in the application as far as my knowledge goes.
I am clueless about how to solve this problem. The only change I make is to the web.xml file and I don't touch any other classes or files. Why do the errors persist permanently?

This time before you start your JBoss server, delete tmp and work folders under the server profile directory. That should take care of 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.