Develop Reference

Running JNLP stucks on Verifying Application

We have a Java application, which is ran with JNLP file. It usually works fine, but we have one PC that is unable to run it, because during running JNLP progress bar stucks on Verifying Application step:
Verifying Application step
and it doesn't move forward.
We have already tried:
waiting for at least 15 minutes,
downloading JNLP again,
clearing java cache,
installing the lastest JRE,
Java console, but it is opened later, so it is not useful,
tried to enable logging and tracing in Java Control Panel, but logs didn't contain any errors or exceptions.
Is there any way to debug what is happening during JNLP verification? Are there any logs available?
EDIT: this is Windows machine with 1.8.0_291-b09 Java HotSpot(TM) 64-Bit Server VM installed.

We found it!
After turning on tracing and logging in Java Control Panel:
and running JNLP with verbose flag:
javaws -verbose file.jnlp
in
C:\User\user\AppData\LocalLow\Sun\Java\Deployment\log
we have found log with errors.
In this case it was:
security: Failing over to CRLs: java.net.SocketTimeoutException: Read timed out

how to enable remote debugging from window machine to Ubuntu machine via netbeans

I want to run remote debugging from Netbeans IDE, OS for remote PC is Ubuntu.
Ubuntu has got some firewall setup, how do I enable it to allow request(remote debugging) from Windows pc?
The application running in Ubuntu is not a web application

I changed the run script and added debug command to execute my jar in debug mode
java -Xdebug -Xrunjdwp:server=y,transport=dt_socket,address=,suspend=n appname
Configure Netbeans, using attach debugger mentioning remote host IP and port number (same port number used in debug script).
Then stopped firewall in Ubuntu (remote host), as it is ours by running the following command
systemctl stop firewalld
Started the application in debug mode
Clicked attach debugger and OK from Netbeans after setting breakpoint

Mirth Connect Administrator Won't Launch

I have Mirth Connect Version 3.5.0.8232 installed on a VM with Window 7 Ultimate N and Java 1.8 build 131. I've been able to start Mirth Connect server successfully; however, I am not able to launch the Administrator tool. When I clicked on the administrator button, It opened the window saying starting application, but it closed it and the administrator window never open. So far, I restarted the service, rebooted the computer, reinstalled Mirth, cleared java cache (several times) successfully. The log file had no error. I was able to login via https//:localhost:8443; however, I tried launching the administrative tool by clicking on Admin and Launch Administrator on the upper right corner. It did not open the administrator tool, but it did download a file call webstart.jnlp. Double click on the file did not do anything. Does anyone have an idea what's going on here?
This is the log file:
INFO 2017-05-05 08:10:05,626 [Main Server Thread] com.mirth.connect.server.Mirth: Mirth Connect 3.5.0.8232 (Built on April 18, 2017) server successfully started.
INFO 2017-05-05 08:10:05,629 [Main Server Thread] com.mirth.connect.server.Mirth: This product was developed by Mirth Corporation (http://www.mirthcorp.com) and its contributors (c)2005-2017.
INFO 2017-05-05 08:10:05,629 [Main Server Thread] com.mirth.connect.server.Mirth: Running Java HotSpot(TM) 64-Bit Server VM 1.8.0_131 on Windows 7 (6.1, amd64), sqlserver, with charset windows-1252.
INFO 2017-05-05 08:10:05,633 [Main Server Thread] com.mirth.connect.server.Mirth: Web server running at http://xxx.xxx.xxx.xx:8080/ and https://xxx.xxx.xxx.xx:8443/

I uninstalled the latest version of java and mirth connect. I installed an earlier version of java. 1.8 update 60 since I had a copy already save on my local. I reinstalled the latest version of Mirth Connect. Everything appears to be working as expected.

In my case Java wanted to upgrade but that was happening behind the scene. Since I don't want to upgrade JRE that I have for certain reasons, what I did is saved webstart.jnlp and running it manually with javaws, i.e.:
javaws webstart.jnlp

Java wanted to update itself in the foreground but got stuck. Once I updated Java to the latest version it worked. Mirth 3.8.0.

64-bit RAD 8.0.4 console and debug mode problems while running WebSphere Application Server v6.1

I am running the 64-bit install of IBM Rational Application Developer (RAD) 8.0.4 on Windows 7. I have WebSphere Application Server (WAS) v6.1 running within it. To be honest, I'm not completely sure if the WAS server is 32- or 64-bit. My problems are:
Except for a few useless lines of logging at WAS startup, I get no logging in the RAD console at all. Not even when there's an exception thrown-- no strack trace, nothing. I cannot find the SystemOut.log file in the place that the WebSphere Properties dialog claims that it is. However, there is one in C:\Users\myUser\AppData\Local\VirtualStore\Program Files\IBM\SDP\runtimes\base_v61\profiles\was61profile1\logs\server1\SystemOut.log, but I do not know how to configure RAD/Eclipse to see it.
I do see an Access is Denied message as the first line of what I can see in the Console. But RAD is not clear about what or whom is being denied access, and in all other ways the server works just fine, except...
I cannot seem to get the WAS instance to run in Debug mode. If I "Restart in Debug...", RAD complies, but the server in the Servers panel of Eclipse does not show "Degugging, Synchronized"-- it simply shows "Started, Synchronized"-- just like it would if started normally. The Debug panel in Eclipse shows the server there, and claims that the debugger is listening on Port 8001. But the application will not stop on any breakpoints.
My colleagues are running identical Windows 7 machines, but have the 32-bit RAD 8.0.4, and don't seem to have this problem. I'm not ready to concede and re-install RAD down to 32-bit, nor do I have the time. There's got to be some other solution.

Work with the admin console and turn on the debug flag.
Start the server from the command line (not from within RAD) and the server would start in the debug mode.
Now try and debug a remote application (like you would any remote application within Eclipse) to attach RAD to this application Server.
Try and see if it works this way.
I would also try and see if the server is running in a debug mode (by looking for a netstat on the port 7777 which is the default debugging port)
HTH

I was able to resolve the logging by giving the LOCAL_MACHINE/Users group more permission on the file-system tree where RAD is installed (C:\Program Files\IBM\SDP\). I have found that when I run RAD "as administrator" in Windows 7, the logging problem I had went away.
Perhaps I should have done more granular analysis to figure out precisely which directory at a lower level might've needed different/more permissions, rather than changing it for all of the RAD install tree; but this works for me at the moment.
UPDATE 11.22.2013
I think the ultimate culprit was Windows 7 UAC. Apparently, applications installed within the default "Program Files" or "Program Files (x86)" directories receive extra security constraints when UAC is fully enabled. Running the server in Debug and the Console logging seem to need permission to modify things that Windows 7 feels like shouldn't be modified without elevated privileges. By either NOT installing RAD in the default Program Files or Program Files (x86) directories, OR completely disabling UAC, the problem is resolved. Disabling UAC could be considered risky, so the solution for me was to reinstall RAD outside of the default Program Files locations.

Tomcat 6.0.18 service will not start on a windows server

I installed Tomcat 6.0.18 on a windows server 2003 box and it will not start as a service.
I'm running it with jdk 1.6.0_07.
It runs when I start it with tomcat6.exe.
I got a vague error in the System Event Log on Windows.
The Apache Tomcat 6 service terminated with service-specific error 0 (0x0).

I'll bite it :-)
Tomcat Service on windows is dependent on the MS C Runtime library msvcr71.dll. As long as it is in the path, the service will start just fine.
Just to prevent your other windows to be forced to use this version of the runtime library, you might want to copy the DLL to just the tomcat bin path instead of windows\system32.

From gobaco.wordpress.com
Tomcat 6 couldn’t find a file called msvcr71.dll.
I just copied it over from
c:\windows\microsoft.net\framework\v1.1.4322
to
c:\windows\system32
and was able to start tomcat.
I thought this was very strange, so I wanted to post it on SO in case anyone else runs into this problem. If someone wants to post the same answer I'll accept it.

i follow the above guide but still the same, error 0,
my process monitor log at http://www.sendspace.com/file/t0tahr

I solved the same problem enabling the default java virtual machine in the configuration app.
Assuming you have installed tomcat using:
service install tomcat-6.0.35
execute:
tomcat6w //ES/tomcat-6.0.35
a window pops up, select the java tab and click on "Use default" checkbox.
The service install script (I immagine) selected C:\Program Files(x86)\Java\jre\bin\client\jvm.dll instead.
Environment:
Windows Server standard SP2 64-bin
Java 1.6.0_23-b05 (Java hotspot 64-bit server vm 19.0-b09 mixed mode)
Apache tomcat 6.35 (you guessed this didn't you?)

I copied the msvcr71.dll from the java home directory to the bin directory of the apache-tomcat install, and the service started after that.

Even though it's an older post, I thought I'd share the knowledge about the very same issue I had, but the workaround was different.
The Apache Tomcat 7 service terminated with service-specific error 0 (0x0).
As there was no more information regarding the problem I went back to the Tomcat Control Panel and had a look at the Java path, which was pointed to an earlier installation of Java Virtual Machine:
C:\Program Files\Java\jre6\bin\client\jvm.dll, which no longer existed, so I had to change the JRE version to jre7.
Having done that, the service started up and all running now.
Hope it'll help some of you out there.