Up until recently, I was able to launch/open JNLP files in Firefox using Java web start.
Don\'t know what happened all of a sudden JNL
This can also be due to environment variable CATALINA_HOME in your system. In our organization there were several cases where JNLP applications just refused to start without logging anything and emptying CATALINA_HOME solved the issue.
I had the environment variable set in the command prompt and it didn't appear in GUI. I'm not sure if setx command or register removal commands did the trick. Restart seems to be necessary after removing the variable.
I wanted to share the root cause for my issue. I was using High DPI in Windows and this caused JNLP to not launch. I had to turn off High DPI for this to work. Hope this helps.
Although this question is bit old, the issue was caused by corrupted ClearType registry setting and resolved by fixing it, as described in this ClearType, install4j and case of Java bug post.
ClearType, install4j and case of Java bug Java
Do you know what ClearType (font-smoothing technology in Windows) has in common with Java (programming language and one of the recommended frameworks)?
Nothing except that they were working together hard at making me miserable for few months. I had some Java software that I couldn’t install. I mean really couldn’t – not even figure out reason or reproduce it on another PC.
Recently I was approved for Woopra beta (site analytics service) and it uses desktop client written in Java… I couldn’t install. That got me really mad. :)
Story All of the software in question was similar :
setup based on install4j; setup crashing with bunch of errors. I was blaming install4j during early (hundred or so) attempts to solve issue. Later I slowly understood that if it was that bugged for that long time – solution would have been created and googled.
Tracing After shifting focus from install4j I decided to push Java framework. I was trying stable versions earlier so decided to go for non-stable 1.6 Update 10 Release Candidate.
This actually fixed error messages but not crashes. I had also noticed that there was new error log created in directory with setup files. Previously I had only seen logs in Windows temporary directory.
New error log was saying following :
Could not display the GUI. This application needs access to an X Server. If you have access there is probably an X library missing. ******************************************************************* You can also run this application in console mode without access to an X server by passing the argument -c Very weird to look for X-Server on non-Linux PC, isn’t it? So I decided to try that “-c” argument. And was actually able to install in console mode.
Happy ending? Nope. Now installed app was crashing. But it really got me thinking. If console works but graphical interface doesn’t – there must be problem with latter.
One more error log (in application folder) was now saying (among other things) :
Caused by: java.lang.IllegalArgumentException: -60397977 incompatible with Text-specific LCD contrast key Which successfully googled me description of bug with Java unable to read non-standard ClearType registry setting.
Solution I immediately launched ClearType Tuner from Control Panel and found setting showing gibberish number. After correcting it to proper one all problems with Java were instantly gone.
cleartypetuner_screenshot Lessons learned Don’t be fast to blame software problems on single application. Even minor and totally unrelated settings can launch deadly chain reactions. Links Jave Runtime Environment http://www.java.com/en/download/index.jsp
ClearType Tuner http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx
Woopra http://www.woopra.com/
install4j http://www.ej-technologies.com/products/install4j/overview.html
Have a look at what happens if you run javaws.exe directly from the command line.
In my case, the problem was caused by starting my app from a shortcut on the public desktop (windows 7). As a result, as far as I can tell, the temporary files location was set to c:\users\public\etc. This resulted in the unable to write to cache detail. When I reset to defaults in the temporary files control applet, all worked fine.
Is this an application to which you have the code? Java 6u14 included a change to the way it handles jar security that for us caused very similar issues. If your jars are signed and work with Java 6u13 or below, you might consider either refactoring your code to work around this update or requiring Java 6u13 or below. Unfortunately I don't recall exactly what we did to resolve the issue - it was panic mode at the time.
Again, if you have the code you have tools to work with. You can put in System.out.println
statements in your startup routines - anything console output is displayed in the command window when you run the JNLP from the command line. Otherwise you might consider using a nice logger like log4j
to get a better idea of the point of failure.
You may also consider removing the application entirely and downloading it anew. Java Web Start has a Control Panel applet that allows you to see the URL your app is downloading from (could be the wrong one), uninstall the app, set security options, etc.