Download Java Jre-7u51-windows-x64 Fixed
Gracia Ziegenbein
As additional measure, I used the java.com tool to uninstall any previous and unsecure JRE version (using Google Chrome). After double checking IE 11, I can see the Java Addons enabled and versioned to 7u51:
We see the same problem with Java 7u51, IE11 and Windows 8.1. As detailed at -us/ie/forum/ie11-iewindows8_1/windows-81-ie11-java-7u51-combination-doesnt-work/24af818d-7196-4dd5-96f5-9c0c65223744 and -dev/2014-January/010048.html and in a bug report submitted to Oracle on 17 January 2014 we find that all is OK until you agree to Java making changes to your system after installation. Once you allow the post-installation permission, Java is disabled. Other than constantly fighting off permission requests, the only workarounds we've found are to use a different environment: browser (use Firefox or Chrome), OS (use Windows 7) or Java version (use a Java 8 build).
btw applet is working at least on the oracle test java page : just uninstall all JAVA from PC then reinstall latest version and disable then enable "Java(tm) Plug-In 2 SSV Helper and Java(tm) Plug-In SSV Helper " @ manage add-ons. before testing java on web. and it works ..
but basically I added this "-Djava.net.preferIPv4Stack=true" to my vm args (set in the Java Control Panel, under Java tab / View) and that solved the issues I was facing... seems like a hack but I guess the latest JRE does not handle IPv6 type requests properly
Even though I installed the latest Java (65) via a java auto-update prompt, tried a verify java version and java failed to run, shut down all IE instances, failed to run verify again, shut down all running programs, failed to run verify again, rebooted, failed to run verify again, re-installed 65 again (shutting down the browser manually as it downloaded), and finally verify ran. What a pain.
As before, this problem didn't happen on Windows 7, but there I noticed that the SSLv3 changes now prevent you from running a local applet in Internet Explorer unless you remove that line from the java.security file. But this problem doesn't happen on Windows 8, so it is not clear what is actually happening.
Unfortunately, "Desktop mode" is not the default mode in Windows 8.1. After installing java and wasting 2hours trying to get java working with IE11, I went back to oracles site...paid a bit more attention to that warning!! switched to Desktop mode, and reinstalled java... hey presto it worked.
Since I already had the latest version of java I decided to go directly to install sysmgr-etup.3-0-win.exe, and received an error that I needed jre 7 to run setup. I uninstalled java 8 and installed jre-7u80-windows-x64.exe. Executed the sysmgr-etup.3-0-win.exe and it ran smoothly.
Afterwards I re-tried the connection to the OnCommand System Manager 3.0 and still the 500 error still occurred. I decided upgrade the NetApp OnCommand System Manager to 3.1.3, and still got the same error. I checked the java version of my previous workstation and found that it had jre-7u51. I downloaded it from the oracle java archives:
I already talked about the Polybase feature related to the content in a podcast early 2016, but this time an install and setup walkthrough, plus a warning for all the people bravely installing oracles newest version of java.
Simply include the java recipe wherever you would like Java installed, such as a run list (recipe[java]) or a cookbook (include_recipe 'java'). By default, OpenJDK 6 is installed. The install_flavor attribute is used to determine which JDK to install (OpenJDK, Oracle, IBM, or Windows), and jdk_version specifies which version to install (currently 6 and 7 are supported for all JDK types, 8 for Oracle only).
Include the default recipe in a run list or recipe to get java. By default
the openjdk flavor of Java is installed, but this can be changed by
using the install_flavor attribute. By default on Windows platform
systems, the install_flavor is windows.
NOTE: In most cases, including just the default recipe will be sufficient.
It's possible to include the install_type recipes directly, as long as
the necessary attributes (such as java_home) are set.
On platforms such as SmartOS that require the acceptance of a license
agreement during package installation, set
node['java']['accept_license_agreement'] to true in order to indicate
that you accept the license.
As of 26 March 2012 you can no longer directly download the JDK from
Oracle's website without using a special cookie. This cookbook uses
that cookie to download the oracle recipe on your behalf, however the
java::oracle recipe forces you to set either override the
node['java']['oracle']['accept_oracle_download_terms'] to true or
set up a private repository accessible by HTTP.
For both RHEL and Debian families, this recipe pulls the binary
distribution from the Oracle website, and installs it in the default
JAVA_HOME for each distribution. For Debian, this is
/usr/lib/jvm/default-java. For RHEl, this is /usr/lib/jvm/java.
After putting the binaries in place, the java::oracle recipe updates
/usr/bin/java to point to the installed JDK using the
update-alternatives script. This is all handled in the java_ark
LWRP.
The java::ibm recipe is used to install the IBM version of Java.
Note that IBM requires you to create an account and log in to
download the binary installer for your platform. You must accept the
license agreement with IBM to use their version of Java. In this
cookbook, you indicate this by setting
node['java']['ibm']['accept_ibm_download_terms'] to true. You must
also host the binary on your own HTTP server to have an automated
installation. The node['java']['ibm']['url'] attribute must be set
to a valid https/http URL; the URL is checked for validity in the recipe.
This cookbook contains the java_ark LWRP. Generally speaking this
LWRP is deprecated in favor of ark from the
ark cookbook, but it is
still used in this cookbook for handling the Oracle JDK installation.
It is acceptable to set the node['java']['jdk_version'] to a specific version if required for your software to run, eg software xyz requires Java 8 to run. Refrain from pinning to specific patches of the JDK to allow users to consume security updates.
df19127ead