We Keep Coding

Netbeans: debugging Java Servlet on Tomcat opens two debug consoles?

I have been developing a Java Servlet app over several years. I have recently started to have slight problems debugging the app with Netbeans. When I click "Debug Project" under the Debug-menu in Netbeans 11.1, the following happens:
Tomcat is started and the app is deployed.
A debugger console is opened that says "User program running".
The app is recompiled.
There seems to be an attempt to somehow redeploy/debug(?) the app again: a second debugger console is opened but this one says "Connection refused".
Historically only steps 1-2 have occurred. I have no idea why recently also steps 3-4 have started to occur. E.g. the only changes I have done to the project pom-file is that some dependencies have been updated to a newer version. The only other major changes have been that the underlying Java SDK is now for version 12 and Netbeans has been updated from 8.2 to 11.1.
The end result is sort of half-ok: I am able to debug (set breakpoints, view variables etc.) the app. But one annoyance is that hot redeploying does not seem to work anymore. Previously changing and saving a Java code file caused that one file to be recompiled and the updated app to be redeployed automatically. This does not happen anymore if I modify and save Java code; I have to compile and redeploy manually. And of course also the fact that the whole project is recompiled at the beginning of each debug session slows things down. I assume these problems must be related to how the extra steps 3-4 have started to occur, but have no idea what could trigger those.
I wonder if anyone has any ideas what might cause this?

Websphere class loading profile restart verus application restart

Can anyone tell me if Websphere does anything differently in terms of class loading when a profile is restarted as opposed to then an application within that profile is restarted?
I'm dealing with a large scale enterprise application compiled against Java 8 that has 250+ third party JAR files in its \WEB-INF\lib folder and am experiencing different behaviour on Websphere 9.0.0.2 (Build Number: cf021645.01 Build Date: 11/8/16) in that everything works fine with the application when I restart the profile but it breaks with what appear to be class loading related errors deep down in third party JAR code whenever the application itself is subsequently restarted.
I have looked at the class loader viewer, turned on verbose class loading and configured a diagnostic trace and everything appears to me to be being loaded correctly. I have two instances of the same application deployed in different profiles using the same version of Websphere and the behaviour is consistent between both, restart the profile and the application is all good but then restart the application and things go bad.
We have only recently started to deploy our application on WebSphere 9, prior to that we were deploying a version of it that was compiled against Java 6 to Websphere 7 without any issues. Some of the third party JARs being used are quite old as our dependency management (or lack thereof) is in need of some work but at this stage I am reluctant to commence what could turn out to be a significant task of updating libraries when the application works fine in one case but not another.
More info added:
Below is an example of the type of error I get following an application restart. In this particular instance I'm running some of our application code that reads a Word document from the file system and passes it to a third party PDF generation library so the execution goes from our local code into the PDF generation library then into the imageio. I don't always get the same error, it sometimes fails at a different point following another application restart (making it further down into the imageio code) but imageio always seems to lead to the problem.
Caused by: java.lang.NoClassDefFoundError: it/geosolutions/imageio/plugins/arcgrid/raster/AsciiGridRaster$AsciiGridRasterType
at it.geosolutions.imageio.plugins.arcgrid.spi.AsciiGridsImageReaderSpi.canDecodeInput(AsciiGridsImageReaderSpi.java:216)
at javax.imageio.ImageIO$CanDecodeInputFilter.filter(ImageIO.java:578)
at javax.imageio.spi.FilterIterator.advance(ServiceRegistry.java:832)
at javax.imageio.spi.FilterIterator.(ServiceRegistry.java:826)
at javax.imageio.spi.ServiceRegistry.getServiceProviders(ServiceRegistry.java:527)
at javax.imageio.ImageIO.getImageReaders(ImageIO.java:657)
at javax.imageio.ImageIO.read(ImageIO.java:1449)
at javax.imageio.ImageIO.read(ImageIO.java:1363)
From what I can see we don't appear to be using any shared libraries at all.
I did stumble upon this question on here during earlier investigations into my issue Not able to load javax.imageio.ImageIO class in WAS 8.5 and I can confirm we are already doing point 1 (explicitly calling ImageIO.scanForPlugins(), we do it as part of a servlet that executes on our application start up) and I have also configured point 2 (disable the class loader leak prevention in the server with a system property com.ibm.ws.runtime.component.disableMemoryLeakService=true) in attempts to diagnose my problem. I haven't tried point 3 though as it seemed to me to be a bit of a last resort.
With regard to imageio we have the following JARs being deployed as part of the 250+ within our application:
jai_codec
jai_imageio
jai_core
imageio-ext-arcgrid-1.1.10
imageio-ext-streams-1.1.10
imageio-ext-utilities-1.1.10
I'm unsure of the exact versions of the jai JARs but will endeavour to find out.
We also deploy a whole bunch of geotools JARs as well and sometimes it fails down in those following execution through imageio. All of these geotools JARs are version 2.4.0 which I know is quite old and I'm not sure how backward compatible they are running on Java 8 now. They worked fine for us on Websphere 7 Java 6 even though I think geotools 2.4.0 was aligned with Java 1.4. Again I'm reluctant to start updating libraries when the application works fine in one case but not another.

Domino nvapplet.jar Security Exception

I have a long standing domino application that uses embedded views to display data. This application has been moved from a server 2003, 32 bit, domino 8.5 environment to a new server 2008 R2 64 bit domino 8.5.3 FP6 environment.
I have everything up and working as before with the exception of embedded views. They are giving a SecurityException "Missing required Permissions manifest attribute in main jar: http://*.com/domjava/nvapplet.jar".
I have confirmed that the actionbar.jar, editor.jar, nvapplet.jar, and outline.jar are the current version on the server. I have even replaced them with the version from the IBM download (http://www-01.ibm.com/support/docview.wss?uid=swg21662233).
I can get this to work by displaying the view as HTML instead of Java Applet, but I don't understand what the issue is with the java version?

There were major security changes to Java in relation to applets. You can download the latest applets here.
http://www-01.ibm.com/support/docview.wss?uid=swg21662233
You may need to clear your browser cache if it still persists after that.
[update] The question now mentions that you installed Fixpack 6, installed the Jars then uninstalled Fixpack 6.
When you uninstall a fix pack, it reverts the files it touches back to what they were before the fix pack was installed. Although I have no details on it, it is quite likely that the updated security applets were also added to fix pack 6 (as it's the last fix pack for R8.5.3).
So during the uninstall the applets look the same as FP6 and it reverts them.
To solve this, after the revert you would need to drop in the updated applets again.
If the issue still persists at this point, you need to open the Java Console on your browser and update your question with the logs it generates (as it pertains to the error).

Turns out this situation may have been a little unique, but I will post it here for future reference in case anyone else runs into this. The server was a fresh build of windows and domino all the way up to 8.5.3 FP6. The FP6 installer date stamps the jars in question with the install date of the system. So in my case I had people come to the site, download the jar with a file date newer than 1/17/2014, which is the date of the files IBM put in the fix mentioned above. Those files are a simple flat copy so they always maintain the 1/17/2014 date. Anyway, any user that came and picked up the newer date files 3/1/2014 for example would keep those files or rev date in their local java machine cache and ignore the 1/17/2014 file I had replaced them with, thus they continued to show the problem. Only by manually clearing their cache from the java were they able to pick up the 1/17/2014 file and no longer have the issue.

Actually from what I was told via IBM FP 6, does not include the fixed .jars. That was my main problem assuming it did.

Debugger not stopping at breakpoints: Websphere in Eclipse

I've recently had my app moved from Websphere Application Server 6.1 to WAS 7.5, due to end-of-life for 6.1. Consequently, I needed to update my debugging server. I found this to be an opportune time to move my application from an IBM RAD IDE to Eclipse (already had Indigo installed). Or so I thought.
Anyway, the powers that be, here, have recommended taking my debugger all the way to WAS 8.5, since I'm only using it to debug.
But the issue that I'm encountering is that I cannot get the debugger to stop on my breakpoints. I've got approx. 10 breakpoints in my opening page, all in JSP/Java code.
I'm running Java 1.6.0_32 and Java SE Runtime Environment build 1.6.0_32-b05. I really don't know how to check which JDK I've got loaded. I've seen recommendations to "go back" to JDK 1.5, but I can't be certain that's not what I'm running.
And to cover a few other bases, I have JUST started my system for the day, opened the IDE, started the server in debug (says "Debugging, Synchronized"), put focus on the opening page of the application and clicked "Debug on server". The front page opens without stopping at any of the breakpoints.
Does anyone have ideas or suggestions?

If you use eclipse's debugger and running the application outside eclipse environment , we have to configure it as remote java application.
Also check if the code deployed in server is in sync with the one present in workspace.

anything wrong of the ecplise's site.
Run->Skip all breakpoints

Well, I had recently faced this problem, where the code did not use to stop at breakpoints while I was in debugging mode and was sure that the particular piece of code is executing. In order to solve the problem, I did a clean-build-republish but it did not work, recreated the profile and readded the server with new profile, still did not work then finally re-installed RAD and web-sphere but It still did not work. Then I found the below article
https://www-304.ibm.com/support/docview.wss?uid=swg21240896
and realized it could be a problem due to some other OS process interfering with debug process/port so I performed a system restore. After restore when I deployed the application, debugger started working properly.

I'd like to say I found the answer to this, but I never did. I ended up dropping RAD and moving to debugging on Jetty. My local testing isn't EXACTLY as it would be on the test server, but it works. Not sure if this should be flagged as "answered" or not.
UPDATE: I have left this project but before I did, the entire development platform was moved to IDEA and debugging was no longer an issue. I don't know if I should find a way to mark this question as inactive or closed or whatever so that it's not just sitting out here getting views and responses when it's no longer an issue for me.

Mirth Running Old JAR File Code

This is really driving me crazy. No matter what I do, it seems that Mirth (1.8.2) is running an older version of my JAR file; I know because of various signs, like:
I can't call any functions
Information logged is not showing up in the logs
Changed log messages are not changed in the log files
Files that were once created and written to in code, but no longer touched by code, are still being created and written
I've tried everything I can think of to make this work. It was working at one point, but now it seems like it's no longer being updated. My process to integrate my changes into Mirth are:
Run an ant script to build the JAR file
Copy the JAR file to \lib\custom
Restart the Mirth service (via Mirth administrator)
I've tried restarting (Mirth service via Services, Java, computer) -- to no avail. I know my JAR file is correct, because I've decompiled it (to make sure it has the latest code) and hashed it (to compare to the hash of the ant-built JAR) -- it is correct and the code is there; it's just not being run.
I'm at wit's end; this occurs infrequently but completely blocks me from developing.
Edit: I also know that my code is correct, because when I run unit tests, it generates the right files and calls the right functions and logs the right information. Only Mirth seems to "not get it."
And my classes are very simple; simple one-argument constructors and a few public methods that return various data. Nothing complex, no nested classes/JARs/dependencies.
Edit: I even deleted my custom JAR file and restarted Mirth, and it's still running my code. Awesome :/ I've added a bounty for this question. I suspect the JAR is cached somewhere (even though they deny it on the Mirth forums) and that cache needs to be cleaned out somehow (although why restarting the Mirth service and my PC doesn't do it is beyond me).
I've also killed all instances of Java (and rebooted my computer), so that makes it highly unlikely that the JVM is caching the JAR somewhere.
I tried reinstalling Mirth. For some reason, it had my custom channel when I booted the administrator for the first time; and infuriatingly, it's still running the old JAR, even though I've updated it with the new one in lib\custom.

I ended up solving this with a combination of actions:
Uninstalling Mirth and Java, and then reinstalling.
I also removed all Java installations except one (one JDK and one JRE).
I stopped Mirth when you copying my JAR. Stop Mirth, copy, and restart; don't try to copy on a live installation. It may or may not pick up your updated JAR depending on if it's loaded into a JVM or not.
This combination of steps seemed to work. Prior to this, I had 3-4 JREs installed (and two JDKs) and I was copying (successfully, according to Windows 7) the JARs while Mirth was running. It's working now!

Mirth is a J2EE application running on a plain old JVM; you have options for debugging it.
You could follow the instructions here for running Mirth Connect via Eclipse. You could then see the JVM classpath, you could set breakpoints and use the debugger.
Mirth is based on the Mule ESB. Mule has its own way of class-loading. You could research it.
If Mirth is really using an old version of your JAR, maybe it's got a cached version around somewhere. Or maybe you made some configuration changes you've forgotten about - perhaps you added a new directory for jars. (Not sure how you do that.)
Mule pays attention to an environment variable named MULE_LIB; maybe that's relevant.
It looks like Mirth Connect 1.8 and Mirth Connect 2.0 have different places for jars (lib/custom and custom-lib, respectively). Which version are you using?