We Keep Coding

Apache Tomcat will not start on Mac

I cannot get Apache Tomcat to start. I followed the instructions for installing Tomcat on the Mac found at https://www.dev2qa.com/how-to-install-tomcat-in-macos/.
After I type the command to start Tomcat, the response from the command line is that Tomcat has started.
However, when I go to the browser, the default page is not showing up. I further checked to see if the port was being used by using the command
lsof -nP -i4TCP:8080 | grep LISTEN
which showed that no program is using the port. I also read the 'RUNNING.txt' that instructed me on setting the environmental variables, which I did. Any suggestions on why Tomcat is not starting up.
I'm using jdk 1.8.0_202 and Apache Tomcat 9.0.14 that is running of Mac OS High Sierra.

BatChmod
After downloading a fresh version of Tomcat, I use the BatChmod app to alter the file permissions. Tomcat will not launch properly without altering the permissions.
I do not know the command-line equivalent, but here is a screenshot of the settings I have used for years successfully.
Plea for help
If anyone can write the equivalent as a shell script for macOS, please post!
Even better, explain how to wrap such a script as an AppleScript for drag-and-drop execution in Finder.

The problem turned out to be a permissions problem. When I installed Tomcat, I put the folder in the '/Library/Tomcat' directory. Even though the Tomcat files were changed to be executable, the user and group ownership remained the same. To get Tomcat to run, I moved the directory to 'Users/MyUserName/Tomcat'. Once I did that, the default Tomcat page ran.

Running exe files with Hudson on Windows 8

I am attempting to have a Hudson job run a windows executable on a Windows 8 VM. When I attempt to run the exe file I get the error:
java.io.IOException: Cannot run program "C:\hudson\workspace\workspaceName\installer\bin\fileToExecute.exe": CreateProcess error=740, The requested operation requires elevation
Has anyone run into this and had it run automatically? I can't just have the exe file on the VM and set its permissions because a new copy gets downloaded at the start of each build.
Thanks in advance.

Disclaimer: I have not tried this with Windows 8.
First things first, even if you succeed to launch an .exe application from Hudson/Jenkins, it will be running under a different session, probably invisible to you. I've managed to achieve the workarounds for this with PsExec as detailed here:
Open Excel on Jenkins CI
With the above method, you will be able to launch an application and actually see it in the logged in session.
If your application does require elevated permissions for whatever reason, you've got to add -h switch to PsExec

Debugging a jnlp application with Eclipse

I can't seem to be able to debug a JNLP application with Eclipse. The problem I'm getting is very similar to that described in this SO question, i.e., javaws appears to be starting the VM twice. The first time it starts fine with the remote debugging options and provided I use the suspend=y option I can even attach the Eclipse debugger to the VM, but as soon as it attaches the VM dies and javaws starts it again without the debugging options.
Here's how I'm launching the app:
javaws -J-Xdebug -J-Xnoagent -J-Djava.compiler=NONE -J-Xrunjdwp:transport=dt_socket,address=8989,server=y,suspend=y http://myserver/launch.jnlp
Since I have suspend=y, whilst it's waiting for a debugger to attach I can use ps -ef | grep java to see the java process with all the correct options running. Indeed, I can connect the Eclipse debugger to it, but as soon as I do that the process terminates and javaws starts a new java process. If I subsequently do another ps I can see a new (different PID) java process now without the debugging options. Attempting to connect to this process from Eclipse just gives "connection refused".
I'm using Java 6 on Mac OS X Lion 10.7.3 if that makes any difference.
The author of the SO question I mentioned above says he solved the problem apparently by accident so the cause of the problem is not apparent (or I'm too stupid to get it).
Any ideas?

Check if you have more then Java 7 update 67.
If you do I know that oracle has open bug for this.
some how from update 67 and above there is problem with this.
I had the same problem. I roll back to Java 7 update 60 and now its working fine.
I suggesting to remove all Java installation and then install

Need help running visualvm on Windows when under VMWare

I am doing some Java development on Windows 7 x64 running inside VMWare Fusion 3.x (OSX). I have installed JDK6 (update 26), set JAVA_HOME to the path (no trailing slash), and restarted my command prompt.
I can successfully launch the program. During startup it runs the calibration and then fails with this error:
"Could not create directory\VMWare-host\Shared Folders\ .nbprofiler" (no space after that slash but the markup was hiding the period)
I can click to continue, but when I'm in the program I cannot do CPU or Memory profiling. I throws up a similar error box:
"Error retrieving saved calibration data for target JVM: Could not create...(same as earlier)"
Once upon a time I had this working by passing the --userdir flag and -J-Dnbprofiler.home during startup, but that trick isn't working anymore.
(The complete command was:
jvisualvm --userdir c:\Users\myname -J-Dnbprofiler.home=c:\Users\myname
)
How can I force jvisualvm to save its calibration data on a "real" drive instead of the vmware network drive and get this working?

.nbprofiler directory is derived from user.home system property. I am not sure what you did to Windows installation, but your user.home points to directory\VMWare-host\Shared Folders. So one solution is to fix the Windows installation, so that Java recognize c:\Users\myname as your user home directory. If that fails for some reason you can use nbprofiler.home property to override it, as you correctly wrote. However you should point it to the nonexistent directory, so you should start VisualVM with the following commandline:
jvisualvm -J-Dnbprofiler.home=c:\Users\myname\nbprofiler --userdir c:\Users\myname\visualvm_userdir
One last note, even if the profiler part is not working, you should be able to use sampling in the 'Sampler' tab.

Try disable Sharing for the VM.
It works for me with Windows 7 x86 in Fusion with Sharing disabled (and Sharing is the mechanism providing the folder you cannot write to).

I found the following command works for me.
visualvm -J-Duser.home=%HOME%
Also, I needed to add -Duser.home=%HOME% to my app startup command.
I had defined nbprofile.home and userdir, but I was still getting an error when the Profiler was running against my app: Profiler Agent Error: Could not create directory\vmware-host\Shared Folders.nbprofiler.
I discovered that the Profiler was using user.home defined by my app rather than the one with visualvm. Both seem to be needed.

Getting 'shmemBase_attach failed: The system cannot find the file specified' when trying to attach to applet to debug

I'm using netbeans 6.1.
I've got the following in my java run time settings:
-agentlib:jdwp=transport=dt_shmem,address=jdbconn,server=y,suspend=n
and the following in the attach dialog in netbeans:
Debugger: JPDA Debugger
Connector: Shared Memory Attach (Attaches by shared memory to other VMs)
Transport: dt_shmem
Name: jdbconn
I got the above settings from the FaqDebuggingAppletRemotely page on the netbeans Wiki.
The applet is in an aspx page (the applet, whcih is signed, is a method of communicating via the client browser to a legacy platform, I'm a C# developer really). I've managed to get the security warning to display which gives me a chance to attach to the applet but whenever I try to attach I see:
Attaching to jdbconn
shmemBase_attach failed: The system cannot find the file specified
in the output window in netbeans.
Any help gratefully received!

I would bet anything (almost anything ... maybe a few dollars at least, or a cookie) that the JVM installation your applets are running on is NOT the same as the default JVM installation that is installed on your system.
To find the JVM installation that your browser and applets are using in Windows 7:
1) Close all applications that use the JVM (especially the browser).
2) Open the windows task manager (CTRL+ALT+DELETE->Task Manager), and click on the processes tab.
3) Make sure there are not any java*.exe processes running.
4) Open your browser and go to the applets page, and start the applet up again.
5) Now go back to the Task Manager->Processes tab and look for the java*.exe that is now running (it will most likely be "java.exe *32" literally, as in it will literally have an asteriks in the name of the process. If you don't see that one, then just use whichever one IS running).
6) Right click on that process, and in the context menu select "Open File Location". This should bring you to the "bin" folder location of the installed JVM that your browser is using to run your applets! Are you surprised that it is not the same as what you thought it would be?
To find the task on linux or other systems:
I've only ever had this problem on Windows, but here's how you do it anyhow.
Open a shell, and type the following
ps -e | grep java
And make a note of the pid(s).
Now that you know which JVM your applets are using:
We need to open the Java Console for that partivular installation (as opposed to the default installation we tried to modify before).
To open the Console of the JVM installation that your applets are using, and set the runtime parameters:
1)Open a command prompt (shell or whatever) in the bin folder of the JVM installation. (In windows 7, from the explorer, you can shift+right-click on the bin folder, and select "Open Command Prompt Here").
2) Run the following command to open the console:
javaws -viewer
This also ends up opening the "Java Cache Viewer" window, which we do not need. Close that window, but keep the "Java Control Panel" window open.
3) You can now go to the Java tab, click on view, and modify the runtime parameters just as you did before:
-agentlib:jdwp=transport=dt_shmem,address=jdbconn,server=y,suspend=n
4) Click "OK", and then click "Apply" in the main java console window to apply and save all the changes you made.
5) WAIT! There is one last thing that I suggest you do; clear out the java WebStart cache to make sure your applets download fresh using the new parameters:
javaws -uninstall
Be sure and run this in the bin directory of the JVM installation that your applets are using, since this might not be the same bin directory that is pointed to by your Path (or PATH) system environment variable.
Now start up your applet from your browser, and create another shared memory connection inside your NetBeans IDE! Setup break points in the correct source code you are debugging ("source" tab in NetBeans), and start using your applet. You should now see that Netbeans is breaking on your break points!
At least, I hope so...

When you debug with the shared memory option (transport=dt_shmem), you're using Windows internal shared memory objects to communicate between the debugger and the jvm.
This means that if you're:
a. Not debugging from the same physical machine as your jvm, or
b. Not working on a Windows OS,
You can not debug in this mode.
I'm not sure what would happen if you ran a Window on a VM on a Linux station...Might work and might not.
If both of the above are fine, it would require a deeper investigation to find out the problem, but in the mean time, you could attach with a plain socket.
In the Java run time parameters specify:
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8000,suspend=y
This tells your jvm to run in debug mode, load the jdwp library, wait for connection to attach in port 8000, and suspend execution until such a connection arrives.
In your IDE set the remote debugger accordingly. I don't know Netbeans, but it would be something like Connector = socket connector, address=8000.
When you start your web page, the applet will freeze loading until you connect, and of course you can't connect until it has reached the listening stage.
Good luck!