I have an applet which was running 1/2 year ago. Now i needed to 'reactivate' it however for an unknown reason it is not working anymore. Here are the specs:
JNLP based NG Applet
Tomcat 7
JRE 1.7.0_25
Firefox 22 and Chrome 28
This is the error I get:
MissingFieldException[ The following required field is missing from the launch file: <jnlp>]
at com.sun.javaws.jnl.XMLFormat.parse(Unknown Source)
at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
at com.sun.javaws.jnl.LaunchDescFactory._buildDescriptor(Unknown Source)
at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
at sun.plugin2.applet.JNLP2Manager.initialize(Unknown Source)
at sun.plugin2.main.client.PluginMain.initManager(Unknown Source)
at sun.plugin2.main.client.PluginMain.access$200(Unknown Source)
at sun.plugin2.main.client.PluginMain$2.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Error while initializing manager: MissingFieldException[ The following required field is missing from the launch file: <jnlp>], bail out
What I tried/suspected so far:
Something oracle introduced with security update 7u17, 7u21 or 7u25. However I tried all JREs from 7u25 down to 7u0 it didn't help. Also tried 6u51 down to 6u22 which I am sure did work before.
Something Mozilla or Google introduced in their effort to increase the security of their browsers in combination with the java plugin. Tried various older browser versions - no success. However then I tried the IE10 and it is working ?!
Analyzed the JNLP file (also with JaNeLa) but since it did work before and works in IE10 it can't be the JNLP. It seems that the plugin doesn't even come to analyzing the JNLP.
Any ideas?
After nearly spending two days on that problem I figured it out, hopefully helping others with that. The explanation:
My applet runs in the context of a protected web application where a user needs to login with a form login first.
After doing so, a session cookie is created and sent back to the client/browser.
Since I switched from tomcat 6 to tomcat 7 the useHttpOnly policy for cookies is enabled by default which was disabled for all tomcat versions prior tomcat 7. The HttpOnly flag instructs browsers to prevent access to those cookies from JavaScript/Plugins (security reasons e.g. cross site scripting etc).
Now since the java plugin couldn't access the cookie it didn't sent it to the server when requesting the JNLP file.
the server returns the loginpage for all unauthorized request.
Last but not least the JNLP parser was looking for the <jnlp> structure and couldn't find any - so the above error was generated.
So how can that be prevented?
Disable the useHttpOnly flag in tomcat globally
Disable the useHttpOnly flag for a webapplication (which I did). To do that add a context.xml file in the META-INF of your webappication which contains the following line
<Context path="/" cookies="true" useHttpOnly="false"/>
Now why the IE10 seems to ignore the httponly flag is a open question i can live with ;-)
Related
After a fresh install of Repast Symphony 2.5.0 (Win 64bit) and JDK 9.0.1 on a Windows 10 system, when importing a JZombies_Demo example, the model cannot be launched with the default configuration.
The error says:
An internal error occurred during: "Launching JZombies_Demo Model".
org.codehaus.groovy.eclipse.core.builder.GroovyClasspathContainer.<init>(Lorg/eclipse/core/resources/IProject;)V
When I edit the default run configuration, in the Dependencies tab I see only the JRE System Library and nothing else. In the same tab, the Restore Default Entries is enabled - when I press it all the dependencies from Repast Symphony are added, and the previous error disappears. However, in this case when trying to launch another error is observed:
saf.core.runtime.Boot - null
java.lang.NullPointerException
at saf.core.runtime.Boot.init(Boot.java:79)
at saf.core.runtime.Boot.main(Boot.java:246)
at repast.simphony.runtime.RepastMain.main(RepastMain.java:43)
I also read about this problem on Repast Mailing List, and saw people talking about missing boot.properties file in the X\eclipse\plugins\repast.simphony.runtime_2.5.0 folder. However, the file is well in place there. So, I tried to link this to the previous error and saw that at (RepastMain.java:43) the pathInfo value was actually X\eclipse\plugins\repast.simphony.bin_and_src_2.5.0. Thus I tried to copy the boot.properties from the runtime directory to the bin_and_src - this removed the previous error, but brought a number of warnings related to UI initialization and an error:
repast.simphony.ui.RSUIPlugin - Fatal error starting Repast
java.lang.NoSuchMethodError: com.jgoodies.forms.layout.ColumnSpec.createGap(Lcom/jgoodies/forms/layout/ConstantSize;)Lcom/jgoodies/forms/layout/ColumnSpec;
at com.jgoodies.forms.layout.FormSpecs.<clinit>(FormSpecs.java:115)
at repast.simphony.ui.RunOptionsPanel.initComponents(RunOptionsPanel.java:114)
at repast.simphony.ui.RunOptionsPanel.<init>(RunOptionsPanel.java:39)
at repast.simphony.ui.RSGui.addRunOptionsView(RSGui.java:558)
at repast.simphony.ui.RSApplication.initGui(RSApplication.java:655)
at repast.simphony.ui.RSAppConfigurator.fillBars(RSAppConfigurator.java:52)
at saf.core.ui.GUICreatorDelegate.createDisplay(GUICreatorDelegate.java:160)
at saf.core.ui.GUICreator.createDisplay(GUICreator.java:12)
at repast.simphony.ui.RSUIPlugin$1.run(RSUIPlugin.java:102)
at java.desktop/java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.desktop/java.awt.EventQueue.access$500(Unknown Source)
at java.desktop/java.awt.EventQueue$3.run(Unknown Source)
at java.desktop/java.awt.EventQueue$3.run(Unknown Source)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
at java.desktop/java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.desktop/java.awt.EventDispatchThread.run(Unknown Source)
After seeing all that, enough frustration, and tries to reinstall the Repast and JDK the situation remained unchanged. Also need to note, that the same behavior is observed for other examples, and newly created Repast projects.
Would be very glad to hear your opinions on what can cause such Repast behavior.
It looks like this is an issue with Java 9 compatibility. Can you try a fresh install using the latest Java 8? In the meantime we'll follow up on what changes in Repast Simphony will be needed for Java 9 compatibility.
I am running my Java-FX application via webstart by tomcat server.
After signing and versioning of jars I having this problem when am accessing it through web browser.
I am using jnlp and version protocol to start the application through tomcat server.
ExitException[ 3]com.sun.deploy.net.FailedDownloadException: Unable to load resource:
(httP://127.0.0.1:8080/gyms/lib/commons-collections-3.2.1.jar?version-id=1.0.1, 1.0.1)
at sun.plugin2.applet.JNLP2Manager.downloadResources(Unknown Source)
at sun.plugin2.applet.JNLP2Manager.prepareLaunchFile(Unknown Source)
at sun.plugin2.applet.JNLP2Manager.loadJarFiles(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
It seems you are using a jnlp-file with a line like this:
<jar href="commons-collections-3.2.1.jar" version="1.0.1" />
So you are using the version-based download protocol. This will result in the server looking for a file called commons-collections-3.2.1__V1.0.1.jar which apparently is not there.
Bottom line: do not specify two conflicting version-numbers in your jnlp. Decide wether you want to use versioned download and omit the version-number in the href-attribute or use simple download and omit the version-attribute.
Problem is solved because I am using Java 1.7.51 update and also i am usin third api which is not supported in java 8 which is also installed in my desktop.
The program(x86) should not have any version of java greater than java 7 as the application is taking java/bin from x86 only.
that is why that failed download exception is coming at run time.
Having a problem running AMTU on a windows 7 Pro Machine.
It runs fine when it opens but it crashes after running a few days.
Here is the Crash Report.
2013-09-14 09:48:19,482 [pool-3-thread-3] com.amazon.merchants.services.RetrieverService - Unable to retrieve unacknowledged report information - MWS Request ID unknown
2013-09-14 09:48:19,482 [pool-3-thread-3] com.amazon.merchants.services.RetrieverService - MWS responded with an error: Internal Error
com.amazonaws.mws.MarketplaceWebServiceException: Internal Error
at com.amazonaws.mws.MarketplaceWebServiceClient.processErrors(MarketplaceWebServiceClient.java:2342)
at com.amazonaws.mws.MarketplaceWebServiceClient.invoke(MarketplaceWebServiceClient.java:2231)
at com.amazonaws.mws.MarketplaceWebServiceClient.invoke(MarketplaceWebServiceClient.java:2011)
at com.amazonaws.mws.MarketplaceWebServiceClient.getReportList(MarketplaceWebServiceClient.java:1206)
at com.amazon.merchants.services.RetrieverService.processReportCheck(RetrieverService.java:94)
at com.amazon.merchants.services.RetrieverService.run(RetrieverService.java:46)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(Unknown Source)
at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I also cannot start the Windows Service called AMTU. Get the following Error:
The AMTU service on local computer has started and then stopped
I am suspecting its a Java version issue.
In the AMTU documentation it says "requires Java version 1.6.0 or later (listed as JDK/JRE - 6)" and links to http://www.oracle.com/technetwork/java/archive-139210.html. The link has many download links, but nothing listed "JDK/JRE - 6".
AMTU documentation: https://d28hcfptedr5ia.cloudfront.net/ug/AMTU_2.2_UserGuide.pdf
Any Ideas?
Thanks in advance.
The way I read this crash report, AMTU got an unexpected result from the MWS servers:
MWS responded with an error: Internal Error
It seems the error handling in AMTU is not good enough to gracefully handle a HTTP status 500, and there is not a lot you can do about this. You could put a HTTP proxy in between and catch a HTTP 500 on the line before it gets to the AMTU, replacing it with something that AMTU handles more gracefully (e.g. an empty XML result or a time out). It would be preferrable though that Amazon doesn't send those errors back, after all, a 500 is an error on their side of things.
I seriously doubt the Java version has anything to do with this, but just in case: You can still download JRE6 even though it is end-of-life:
Java 6 downloads
Please note that the true name of JRE6 is "Java SE runtime environment" and JDK6 is called "Java SE development kit". At the time of writing, the most current version is "update 45". You may need to uninstall Java 7 to make sure the AMTU actually uses the version you want it to. Please also note that since AMTU is a 32bit process, you will need the 32bit JRE even if it is run on a 64bit windows.
I have an applet that has a logout"button. The button ends the session by calling a CGI script and then kills Java VM by calling System.exit(). The problem is when a user tries to log in again in the same browser window - the applet fails to load with ClassNotFoundException:
load: class lucent/fm/parts/BlankPage.class not found.
java.lang.ClassNotFoundException: lucent.fm.parts.BlankPage.class
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: open HTTP connection failed:http://example.com/html/lucent/fm/parts/BlankPage/class.class
at sun.plugin2.applet.Applet2ClassLoader.getBytes(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader.access$000(Unknown Source)
at sun.plugin2.applet.Applet2ClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
... 7 more
Exception: java.lang.ClassNotFoundException: lucent.fm.parts.BlankPage.class
It appears only on Internet Explorer, not in Firefox. Java Plugin is:
Java Plug-in 1.6.0_20
Using JRE version 1.6.0_20-b02 Java HotSpot(TM) Client VM
The direct scenario is the following:
1. Log in to the system (load the applet).
2. Log out (it closes the applet, but the browser window persists).
3. Click on the address bar and press Enter.
4. The applet fails to load and the ClassNotFoundException can be seen in Java Console.
5. Refresh the page - the server redirects to the login page; after logging in, the applet again does not load and throws the exception.
Looking at the Apache access log proved that in the step 4 that the browser (or plugin) tries to load jar files and gets a HTTP error. It is OK because the session has expired. The strange thing happens in the 5th point - there is no request for jars! It seems that the browser or plugin remembers failed attempts and does not even try to load jar files. It only tries to load a raw .class file, which is not present on the server.
Is my conclusion correct? How can I deal with such an error? Is it possible to force Java plugin to load jar files?
I checked that enabling caching in Java Control Panel does not help. Setting the codebase_lookup parameter to "false" is not helpful, too. It only prevents from trying to load the "class" file directly.
Thanks in advance for any suggestions.
I have an applet that has a "logout" button. The button ends the session by calling a CGI script and then kills Java VM by calling System.exit().
An applet calling System.exit(anyNumber) is crudely equivalent to a guest burning down the house of their host. Applets (even trusted applets) should never try to end the VM. The VM will be ended by the browser when all applets in a page that share the VM have finished their destroy() methods and a subsequent period of time as chosen by the browser.
BTW - I recall one version of Mozilla/FF where calling System.exit(int) not just ended the VM, but also crashed the browser!
If your html with applets is not static (cgi, php, etc), then after logging out, you can try to force different URL pointing to the jar file (i.e. instead of "my.jar" use "my.jar?random=1235232").
Also, you can try to play with cache HTTP headers.
Another potential workaround will be to reconfigure apache to serve the jars always - even when session has been closed (if that's acceptable).
After upgrading to the latest java version (Java 6 update 13) a webstart application that was being used in production environments for many years, stopped installing with the following error:
java.lang.Exception: cache failed forhttp://localhost:8080/ReactorStudio/studio/installer.jnlp
at com.sun.javaws.Launcher.updateFinalLaunchDesc(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
The application jnlp is downloaded correctly and all the associated jar files. The application also contains a reference to an installer jnlp file that extracts a few files to the local disk the first the application is being run.
Any ideas on what is the problem, or how I could bypass this?
We had a similar issue when upgrading to the latest JRE. Our issue seemed to be related to this bug that should be fixed in 6u14. Perhaps your issue is also related.
The only workaround we found was to clear the webstart cache and launch the application again. In our experience this seems to be the solution to most webstart issues.
Try to remove href="..." from the "jnlp" tag of the "launch.jnlp" file.