jnlp

It is years since I have worked in Java (that's my excuse). I am trying to launch a Java Swing UI as an Applet (previously done via Web Start). I have modified the jnlp file to reflect the changes that I know are necessary for an applet (e.g. using applet-desc instead of application-desc). Inside the <resources> tag in the jnlp file we set system properties like this: <property name="java.security.auth.login.config" value="$$context/app/auth.conf"/> In the init method of the main class we try to read some of these system properties and always get "null" as the value. Does anyone have any ideas

I am trying to remote debug a Java applet, but I cannot seem to get the -agentlib:jdwp JVM argument to work. I have tried specifying it in the Java control panel for the particular JRE used, and I have tried setting it via the JNLP file used to launch the applet. What is the correct way to set JVM parameters for applet launch? In particular, to debug remotely. 11101101b Looking at a similar SO question , I found the following answer... Sometimes to debug some security related stuff the browser plugin environment is just too different from appletviewer. Here's what you can do to effectively

Since May 9, after a windows 10 update, on IE11 11.0.40, JNLP files wont launch from IE, but in a computer with IE version 11.0.34 it work perfectly. Any ideas? Thanks in advance The problem is solved in Java 8 u162. Now you can have Java RE x86 and x64 installed and jnlp will open as it should in Internet Explorer. We are using sitelist / Enterprise Mode to redirect jnlp urls from Edge to Internet Explorer. I had a problem opening a jnlp file, no matter what, trying to associate it with the Java Web Service exe javaws.exe, but it just would not associate and would not be run. I read

My JNLP still works fine after our switch from Java 6 to Java 7, but it now throws a whole series of errors like this: Missing Application-Name: manifest attribute for: http://blah.com/app.jar Missing Permissions manifest attribute for: http://blah.com/app.jar Missing Codebase manifest attribute for: http://blah.com/app.jar It repeats several times for our main jar and a couple times for one of our library jars. However, it does not occur at all for the bulk of our library jars. JaNeLa lists some optimization opportunities (by changing some defaults), but none of those appear to be related,

I'm trying to run this Java application (jar) via Java Web Start and am having an incredibly difficult time. Here's my current JNLP source: <?xml version="1.0" encoding="utf-8"?> <jnlp spec="1.0+" codebase="http://localhost:8080/" href="Test.jnlp"> <information> <title>Jnlp Testing</title> <vendor>YONG MOOK KIM</vendor> <homepage href="http://localhost:8080/" /> <description>Testing Testing</description> </information> <security> <all-permissions/> </security> <resources> <j2se version="1.6+" /> <jar href="TestJnlp.jar" /> <jar href="lib/appframework-1.0.3.jar"/> <jar href="lib/junit-4.7.jar"/

I have a jnlp file for deploying my javafx 2.0 application, however, how do I make sure that the users have the correct javafx runtime (32 or 64 bit depending on the jvm present on the machine) and if not, download it and run the application. Assuming that the user does not have a javafx runtime currently installed, the problems that I'm facing mostly with a 64 bit machine with either 32-bit, 64-bit or both JRE's are: 1) The Javafx swing deployment guide mentions to use the <jfx:javafx-runtime version /> tag to download the appropriate jfx runtime, but JRE below 1.7 doesn't understand this tag

On Mac OS X 10.9 signed Java Web Start applications are blocked by default with the message: "application.jnlp" can't be opened because it is from an unidentified developer. I know it's possible to weaken the security checks to allow any application to run, but that requires a manual intervention of the end user. Is it possible to "sign" a Java Web Start application such that it is recognized as originating from an identified developer? Thank you Apple does appear to support signing of webstart -- but not directly. You have to bundle it in an archive. See the note at the bottom of this page: