1 person found this helpful
Can't you use the Java Control Panel, as described in the first part of the document you linked? Obviously, this has the disadvantage of disabling the later version for any other apps that might require it.
I spent a lot of time investigating how JNLP selects its Java version, and could not find a solution. In my case, I have clients on different versions, and wanted to be able to create shortcuts that would force use of a particular Java version for a particular EAS instance.
First I tried this, specifying the appropriate JRE bin directory:
But it didn't work - even if I explicitly called the 1.6 version of javaws.exe, Java itself would be invoked as 1.7.
I went as far as modifying the .jnlp file on the server; according to the JNLP File Syntax it should be possible to specify the Java version used, but nothing I specified (and I really tried) with the version tag would force the use of e.g. 1.6 if 1.7 was also installed.
Either the JNLP documentation is misleading / wrong or I have misunderstood it. I'm not the only person to have tried it, either: Essbase Users: EAS JRE's - 1.5 and 1.6
I still use shortcuts to launch the Console, just because I find it easier than opening a browser - but it's no help in controlling Java version.
If anyone knows a better solution I would love to hear it.
1 person found this helpful
Actually, just to add...
The method that support document suggests changes the version of javaws.exe (the JNLP launcher) that gets used. My experience is that that isn't enough to change the version of Java that gets used. E.g. if both 6 and 7 are installed and enabled, changing the registry so that the 6 JNLP launcher is used still results in Java 7 being invoked.
The splash screen shows Java 6, but if you look at the properties of the launched javaw.exe process in the task manager, it's actually Java 7. Only disabling 7 in the Java control panel actually stops Java 7 being used.
Either I'm doing something wrong or the method described in that support doc doesn't (always?) work.
Tx to you responce,
We can not change the panel as' users are not adminstrator their PC. And all applications will not necessarily work with a lower version.
PCs are blocked at my client.
Using shortcut is a solution that can be used for some users only.
But we have more than 10,000 users around the world that we know.
We must find a solution that can patch directly on the server.
You speak of documentation JNLP? you have a link?
For WebAnlysis, there is a setting on the server indications to the registry key that WA will look like JAVA default.
I would like find a solution to change the launch JNLP EAS console so that impact all users.
Another question, where you can find the file easconsole.jnlp?
I can not find anything on the server.
1 person found this helpful
I honestly can't remember - I may just have created a copy of easconsole.jnlp (since it can be downloaded) and then pointed my browser to it. But in any case, that approach did not work for me (if you try and it succeed, please post back). The documentation for JNLP is linked in my first reply. It's generic JNLP documentation, not specific to EAS.
The only thing that worked for me to disable Java 7 was changing the settings in the Java Control Panel - or modifying deployment.properties in the user's AppData directory, which is effectively the same thing.
If you have not configured the file types in your system to open the JNLP, then i think it will ask you what to be done with the file. To save it / open it then you can save the file
You can then have different batch scripts to set env of that particular version and open the jnlp with javaw.exe. I think it should work
I would not find a solution related to the job but on the Essbase server.
Searching, I could find the location of the JNLP file (thank you to my colleagues who know JAVA well).
On the Essbase server in the directory the EAR file: eas.ear
<HOME_ESSBASE> / Products / Essbase / eas / server / AppServer / InstallableApps / Common / eas.ear
This is the version 18.104.22.168 Essbase for me.
in this directory are:
/ products / Essbase / eas / server / AppServer / InstallableApps / Common> ll
-rw-rw ---- 1 epm11 epm11 72200236 Apr 23 3:16 p.m. eas.ear
-rw-rw ---- 1 260 May epm11 epm11 November 2010 eas.ear.properties
-rwxr-x --- 1 epm11 epm11 May 1464 November 2010 easkeystore
-rwxr-x --- 1 757 May epm11 epm11 November 2010 eastruststore
If you upload the file on your pc eas.ear:Open the file eas.ear with 7Zip : you can see all the file *.warIf you open the easconsole.war you find the easconsole.jnlp.The contain of this file is an xml file :
<?xml version="1.0" encoding="utf-8"?>
<!-- JNLP File for EAS Console Application -->
<!-- Created By: Sree Menon -->
<title>Oracle Essbase Administration Services</title>
<description>Oracle Essbase Administrative Console </description>
<property name="EAS_HOME" value="$$codebase"/>
<property name="USE_FOXTROT_BY_DEFAULT" value="NO"/>
<property name="DEFAULT_COMMAND_MANAGER" value="com.essbase.eas.framework.client.defs.command.UICommandManager"/>
<property name="eas_country" value="COUNTRY_NULL"/>
<property name="eas_language" value="LANGUAGE_NULL"/>
<jar href="eas_client.jar" main="true" />if you replaced as shown in doc ORACLE JNLP: http://docs.oracle.com/javase/6/docs/technotes/guides/javaws/developersguide/syntax.html<j2se version="1.4+"to<j2se version="1.6.0_45"on the eas.ear and you donwload.When you start again all the services TOMCAT on the Essabse serveur, the EAS console launch always with the bad version of java and your PC windows .....
I test all so <j2se version="1.6" or <j2se version="1.6*" ... but nothing better.
Why this does not work?
The problem is that the EAS console the 22.214.171.124 version does not work with version 1.7 Java : you can not edit OTL .
My users are blocked.
I would need help.
Thanks for the update, Olivier. Very interesting.
Why this does not work?
That's the million dollar question, isn't it? The JNLP documentation suggests that you should be able to control version in the .jnlp file, but it is disregarded. Java seems to think it knows better than you which version should be used (this is a guess, but perhaps because of security problems in earlier versions?).
I think you have followed the same path I did - and been equally unsuccessful. It's very frustrating.
This is definitely a hack, but even if your users can't access the Java Control Panel, could they run a script that modifies the file "deployment.properties" before launching the console?
It seems that the Java Control Panel is saving the settings in that file (it will be sitting somewhere under Users\UserName\AppData\). You could script temporarily disabling the incompatible versions by editing that file.
I would guess that it would be possible even in a locked-down corporate environment, because it's under the user's own user directory. But it would require a lot of care to eliminate any risk of accidentally corrupting the file, and you'd probably need to restore the original settings afterward. I've blogged about this problem and posted a basic script (strictly experimental and definitely not for production use!) here: Running Web-Launched EAS with the Right Java Version | Cube Coder
It really feels like there should be an easier method...
I actually changed the JNLP respecting the rules.
But I think the dévelloppement EAS console is very wrong.
Whatever happens it always takes the highest version of the workplace: even up to 1.7.
So I decided to open a SR to Oracle Support BUT ..
I was told that 126.96.36.199 is no longer supported.
I just asked for help in understanding ...
I was told that no longer support the need to use version 1.5 recommended for EAS.
I have 1.5 on my workstation but it is always the last version used I indicated that it is not logical???
But we have no means of ORACLE on the subject.
We'll have to get by alone., As often with the support.
I still said that it is not logical to take the latest version of java for imcompatible superière application with version 1.5? right?
I'm looking at all *. Eas.ear jar contained in the file containing the easconsole.JNLP.
I'm not a java expert but I think the answer is inside.
to be continued.