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. 🙄
Related
When triggering Maven lifecycle entries in IntelliJ IDEA (clean+install for example), the IDE launches the associated Java with plexus-classworlds-<version>.jar from the associated Maven installation.
Sometimes (mostly) the Java launch takes up to 2 minutes before the Maven action starts.
Any thoughts what could cause this? I'd like to use this integrated feature instead of Maven command line calls (which work "normal" regarding no delay).
Network related Java problems might be, I'm inside Intranet, Firewall, custom proxy.
There is no status or logmessage regarding the Java launch except for the time indicator in the run window.
Problem - well - "solved" by adding java as an exlusion for the av scanner (avira).
I am having trouble with an installation of Wildfly 9. Before now, everything has been fine and running smoothly. I've since made one small change to standalone.xml (turned up logging level to TRACE for one of the deployed packages, that's it).
Wildfly is running as a service.
Here's what's happening:
Made change to standalone.xml
Restarted the service
Noticed that none of my jars are deploying even though the deployment scanner is on
Create .dodeploy files to deploy the jars
Every single one fails
Change to standalone.xml is reverted, despite clearing the cache
So, I then try to deploy just ojdbc7.jar. This is the error message I am getting:
"{\"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available.\" => {
\"Services that were unable to start:\" => [\"jboss.deployment.unit.\\\"ojdbc7.jar\\\".PARSE\"],
\"Services that may be the cause:\" => [
\"jboss.jdbc-driver.ojdbc7_jar\",
\"jboss.remoting.remotingConnectorInfoService.http-remoting-connector\"
]}}"
At first, I thought I may have something else listening on port 8080. I checked, and I definitely don't. I don't really know what else this problem could be.
I am also at a complete loss to explain how my standalone.xml change is not being picked up. It seems like it's cached somewhere and I just don't know where. I have cleared the cache and it just keeps coming back.
Apologies if this seems a little vague - if anyone needs any clarification or more information I'll be happy to oblige.
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
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.
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.